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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]