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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list