Open Stack

On 06/29/2017 10:59 AM, sfinucan at redhat.com wrote:

> Thus far, we've no clear conclusions on directions to go, so I've took a stab
> below. Henning, Sahid, Chris: does the above/below make sense, and is there
> anything we need to further clarify?

The above is close enough. :)

> # Problem 1
>
>  From the above, there are 3-4 work items:
>
> - Add a 'emulator_pin_set' or 'cpu_emulator_threads_mask' configuration option
>
>    - If using a mask, rename 'vcpu_pin_set' to 'pin_set' (or, better,
>      'usable_cpus')
>
> - Add a 'emulator_overcommit_ratio', which will do for emulator threads what
>    the other ratios do for vCPUs and memory

If we were going to support "emulator_overcommit_ratio", then we wouldn't 
necessarily need an explicit mask/set as a config option. If someone wants to 
run with 'hw:emulator_thread_policy=isolate' and we're below the overcommit 
ratio then we run it, otherwise nova could try to allocate a new pCPU to add to 
the emulator_pin_set internally tracked by nova.  This would allow for the 
number of pCPUs in emulator_pin_set to vary depending on the number of instances 
with 'hw:emulator_thread_policy=isolate'on the compute node, which should allow 
for optimal packing.

> - Deprecate 'hw:emulator_thread_policy'???

I'm not sure we need to deprecate it, it would instead signify whether the 
emulator threads should be isolated from the vCPU threads.  If set to "isolate" 
then they would run on the emulator_pin_set identified above (potentially 
sharing them with emulator threads from other instances) rather than each 
instance getting a whole pCPU for its emulator threads.

> # Problem 2
>
> No clear conclusions yet?

I don't see any particular difficulty in supporting both RT and non-RT instances 
on the same host with one nova-compute process.  It might even be valid for a 
high-performance VM to make use of 'hw:emulator_thread_policy=isolate' without 
enabling RT.  (Which is why I've been careful not to imply RT in the description 
above.)

Chris