[libvirt] [PATCH RESEND RFC v4 1/6] Introduce the function virCgroupForVcpu

Adam Litke agl at us.ibm.com
Thu Jul 21 12:54:05 UTC 2011

Added Anthony to give him the opportunity to address the finer points of
this one especially with respect to the qemu IO thread(s).

This feature is really about capping the compute performance of a VM
such that we get consistent top end performance.  Yes, qemu has non-VCPU
threads that this patch set doesn't govern, but that's the point.  We
are not attempting to throttle IO or device emulation with this feature.
 It's true that an IO-intensive guest may consume more host resources
than a compute intensive guest, but they should still have equal top-end
CPU performance when viewed from the guest's perspective.

On 07/21/2011 05:09 AM, Daniel P. Berrange wrote:
> On Thu, Jul 21, 2011 at 10:08:03AM +0800, Wen Congyang wrote:
>> Introduce the function virCgroupForVcpu() to create sub directory for each vcpu.
> I'm far from convinced that this is a good idea. Setting policies on
> individual VCPUs is giving the host admin a misleading illusion of
> control over individual guest VCPUs. The problem is that QEMU has
> many non-VCPU threads which consume non-trivial CPU time. CPU time
> generated by a CPU in the guest, does not neccessarily map to a VCPU
> thread in the host, but could instead go to a I/O thread or a display
> thread, etc.
> IMHO we should only be doing controls at the whole VM level here.
> Daniel

Adam Litke
IBM Linux Technology Center

More information about the libvir-list mailing list