At 07/21/2011 12:39 PM, Daniel Veillard Write: > On Thu, Jul 21, 2011 at 10:12:14AM +0800, Wen Congyang wrote: >> --- >> docs/formatdomain.html.in | 19 +++++++++++++++++++ >> 1 files changed, 19 insertions(+), 0 deletions(-) >> >> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in >> index a54ee6a..47edd35 100644 >> --- a/docs/formatdomain.html.in >> +++ b/docs/formatdomain.html.in >> @@ -307,6 +307,8 @@ >> <vcpupin vcpu="2" cpuset="2,3"/> >> <vcpupin vcpu="3" cpuset="0,4"/> >> <shares>2048</shares> >> + <period>1000000</period> >> + <quota>-1</quota> >> </cputune> >> <numatune> >> <memory mode="strict" nodeset="1-4,^3"/> >> @@ -400,6 +402,23 @@ >> 2048 will get twice as much CPU time as a VM configured with value 1024. >> <span class="since">Since 0.9.0</span> >> </dd> >> + <dt><code>period</code></dt> >> + <dd> >> + The optional <code>period</code> element specifies the enforcement >> + interval(unit: microseconds). Within <code>period</code>, each vcpu of >> + the domain will not be allowed to consume more than <code>quota</code> >> + worth of runtime. The value should be in range [1000, 1000000]. >> + <span class="since">Since 0.9.4</span> >> + </dd> >> + <dt><code>quota</code></dt> >> + <dd> >> + The optional <code>quota</code> element specifies the maximum allowed >> + bandwidth(unit: microseconds). A domain with <code>quota</code> as any >> + negative value indicates that the domain has infinite bandwidth, which >> + means that it is not bandwidth controlled. The value should be in range >> + [1000, 18446744073709551] or less than 0. >> + <span class="since">Since 0.9.4</span> >> + </dd> >> <dt><code>numatune</code></dt> >> <dd> >> The optional <code>numatune</code> element provides details of > > I think we need to expand this a bit: > - first state that 0 means no value for both tunable > - then express that the implementation is based on CFS for QEmu/KVM > and what the use case really are. It seems to me that it's not > really for fine grained ressource control but rather to keep the > limits of CPU usage consistent. > - also an small explanation of how well those tunable may or may not > work in case of migration seems important I added the first two, and I do not know the relationship between cpu bandwidth and migration. If someone knows it, we can add it later. > > ACK > > and don't forget the commit message :-) I addressed your comment, added commit message for each patch and pushed this patch set. Thanks Wen Congyang > > thanks > > Daniel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list