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