[libvirt] [PATCH 5/6] qemu: Implement hypervisor's period and quota tunable XML configuration and parsing

KAMEZAWA Hiroyuki kamezawa.hiroyu at jp.fujitsu.com
Thu May 17 06:33:21 UTC 2012


(2012/05/17 15:34), Wen Congyang wrote:

> At 05/17/2012 02:06 PM, KAMEZAWA Hiroyuki Wrote:
>> (2012/05/17 15:05), Wen Congyang wrote:
>>
>>> At 05/17/2012 01:42 PM, Hu Tao Wrote:
>>>> On Thu, May 17, 2012 at 01:25:48PM +0800, Wen Congyang wrote:
>>>>> At 05/17/2012 01:09 PM, KAMEZAWA Hiroyuki Wrote:
>>>>>> (2012/05/17 14:07), Wen Congyang wrote:
>>>>>>
>>>>>>> At 05/17/2012 12:46 PM, KAMEZAWA Hiroyuki Wrote:
>>>>>>>> (2012/05/17 12:54), Wen Congyang wrote:
>>>>>>
>>>>>>>>> So, if we donot limit the hypervisor, the behavior shoule not be
>>>>>>>>> changed. So we should limit the whole vm. If the hypervisor threads
>>>>>>>>> are limited, there is no need to limit the whole vm.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> need to tune hypervisor quota to limit vcpu-only quota ?
>>>>>>>> Sounds strange to me.
>>>>>>>
>>>>>>> No, current implemetion is:
>>>>>>> 1. limit vcpu and hypervisor: vm is not limited
>>>>>>> 2. limit vcpu only: vm is limited
>>>>>>> 3. limit hypervisor: vm is not limited
>>>>>>> 4. vcpu and hypervisor are not limited: vm is not limited.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> In 2.
>>>>>>
>>>>>>    vm               ----- quota_is_limited
>>>>>>     |- hypervisor   ----- quota is unlimited
>>>>>>     |- vcpu[0...x]  ----- quota is limited
>>>>>>
>>>>>> Hm...vm is limited. It seems user need to tune vm's quota...can user
>>>>>> makes vm's quota to be unlimited and limit *only* vpcus as Xen ?
>>>>>
>>>>> Without this patchset, the vm will be limited if the vcpu is limited.
>>>>> We cannot know whether the hypervisor is unlimited or the user does not
>>>>> set it. If the user does not set it, we should not change the behavior.
>>>>> So I donot find an easy way to limit only vcpus.
>>>>
>>>> Can we change the implementation like these:
>>>>
>>>> 1. 
>>>> <cputune>
>>>>   <vcpu>
>>>>     <period>period</period>
>>>>     <quota>quota</quota>
>>>>   </vcpu>
>>>> </cputune>
>>>>
>>>> Limit vcpus only, does not limit vm or hypervisor.
>>>>
>>>> 2.
>>>> <cputune>
>>>>   <hypervisor>
>>>>     <period>period</period>
>>>>     <quota>quota</quota>
>>>>   </hypervisor>
>>>> </cputune>
>>>>
>>>> Limit hypervisor only, does not limit vm or vcpus.
>>>>
>>>> 3.
>>>> <cputune>
>>>>   <period>period</period>
>>>>   <quota>quota</quota>
>>>> </cputune>
>>>>
>>>> Limit the whole vm, in this case vcpus and hypervisor are also limited.
>>>>
>>>> 4.
>>>> <cputune>
>>>>   <period>period</period>
>>>>   <quota>quota</quota>
>>>>   <vcpu>
>>>>     <period>period</period>
>>>>     <quota>quota</quota>
>>>>   </vcpu>
>>>>   <hypervisor>
>>>>     <period>period</period>
>>>>     <quota>quota</quota>
>>>>   </hypervisor>
>>>> </cputune>
>>>
>>> This is very complex, and the user should know how we implement it
>>> and the period/quota's limit. If the user gives a wrong value, the
>>> vm cannot start.
>>>
>>> We implement the limit like this:
>>>
>>>               vm
>>>                |
>>>  ----------------------------
>>>  |       ...         |       |
>>> vcpu0               vcpun   hypervisor
>>>
>>> If all is limited, the vm's quota should be greater than max(vcpu's quota, hypervisor's quota)
>>> and vm's period should be less than min(vcpu's period, hypervisor's period).
>>>
>>> So I donot like this idea.
>>>
>>  
>>
>> Hmm. my proposal is not so complicated as you say. And simpler than your way.
>>
>>   <quota target='all|vcpu'>   </quota> # all is default and limit the whole vm.
>>                                        # vcpu is just limit vcpus rather than whole vm.
>>   <period> .... </period>              # period is shared in all settings.
>>
>> Isn't it ?
> 
> Do you mean this:
> <cputune>
>   <vcpu>
>     <period>period</period>
>     <quota target='all|vcpu'>quota</quota>
>   </vcpu>
>   <hypervisor>
>     <period>period</period>
>     <quota>quota</quota>
>   </hypervisor>
> </cputune>
> 


No. hypervisor limiting is not necessary at all in my proposal.

Thanks,
-Kame







More information about the libvir-list mailing list