Hello, Austin.

On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote:

quoted

Just to learn more, what sort of hypervisor support threads are we
talking about?  They would have to consume considerable amount of cpu
cycles for problems like this to be relevant and be dynamic in numbers
in a way which letting them competing against vcpus makes sense.  Do
IO helpers meet these criteria?

Depending on the configuration, yes they can.  VirtualBox has some rather
CPU intensive threads that aren't vCPU threads (their emulated APIC thread
immediately comes to mind), and so does QEMU depending on the emulated

And the number of those threads fluctuate widely and dynamically?

hardware configuration (it gets more noticeable when the disk images are
stored on a SAN and served through iSCSI, NBD, FCoE, or ATAoE, which is
pretty typical usage for large virtualization deployments).  I've seen cases
first hand where the vCPU's can make no reasonable progress because they are
constantly getting crowded out by other threads.

That alone doesn't require hierarchical resource distribution tho.
Setting nice levels reasonably is likely to alleviate most of the
problem.

The use of the term 'hypervisor support threads' for this is probably not
the best way of describing the contention, as it's almost always a full
system virtualization issue, and the contending threads are usually storage
back-end access threads.

I would argue that there are better ways to deal properly with this (Isolate
the non vCPU threads on separate physical CPU's from the hardware emulation
threads), but such methods require large systems to be practical at any
scale, and many people don't have the budget for such large systems, and
this way of doing things is much more flexible for small scale use cases
(for example, someone running one or two VM's on a laptop under QEMU or
VirtualBox).

I don't know.  "Someone running one or two VM's on a laptop under
QEMU" doesn't really sound like the use case which absolutely requires
hierarchical cpu cycle distribution.

Thanks.

-- 
tejun