Re: [libvirt] [PATCH RESEND RFC v4 6/6] doc: Add documentation for new cputune elements period and quota

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 @@ > &lt;vcpupin vcpu="2" cpuset="2,3"/&gt; > &lt;vcpupin vcpu="3" cpuset="0,4"/&gt; > &lt;shares&gt;2048&lt;/shares&gt; > + &lt;period&gt;1000000&lt;/period&gt; > + &lt;quota&gt;-1&lt;/quota&gt; > &lt;/cputune&gt; > &lt;numatune&gt; > &lt;memory mode="strict" nodeset="1-4,^3"/&gt; > @@ -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

ACK and don't forget the commit message :-)

thanks Daniel