Hello, Austin. On Mon, Aug 24, 2015 at 11:47:02AM -0400, Austin S Hemmelgarn wrote: > >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 -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
