On 06/29/2017 10:59 AM, sfinu...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
