[libvirt] [PATCH 06/10] vcpubandwidth: introduce two new libvirt APIs

Wen Congyang wency at cn.fujitsu.com
Wed Jul 13 08:55:28 UTC 2011


At 07/13/2011 04:50 PM, Nikunj A. Dadhania Write:
> On Wed, 13 Jul 2011 14:26:23 +0800, Wen Congyang <wency at cn.fujitsu.com> wrote:
>> At 07/07/2011 10:32 AM, Taku Izumi Write:
>>>
>>>>>>>>> So why introduce VCPU level apis?
>>>>>>>>
>>>>>>>> Adam Litke said IBM's performance team nead to control cpu bandwidth for each
>>>>>>>> vcpu.
>>>>>>> Right, but we do not export that as a User API, that was my suggestion.
>>>>>>> We can internally control each vcpu's bandwidth, i.e. divide equally.
>>>>>>
>>>>>> Hmm, I heard that some server could run CPUs at different speed.
>>>>>> May be this patch can simulate this behavior. 
>>>>> That happens on my laptop as well, depending on the machine load CPU
>>>>> frequency is changed but it is done transparently.
>>>>
>>>> I means explicitly CPU speed configuring. ;)
>>>>
>>>>>
>>>>> I am not sure if we are trying to simulate that here.
>>>>
>>>> So why not leave the flexible interface here, and let users make
>>>> the decision?
>>>
>>>  In my mind, the flexibility is not always a good thing.
>>>  It is nothing but troublesome for the person who doesn't like
>>>  detailed setting. I don't know how many people want this flexibility.
>>
>> I think we should implement the flexibility. If we do not implement, and
>> we want it later, we can not reuse these codes(add new element, and reimplement).
> IMHO, at present we can use the current SetSchedulerParameters API and
> whenever we need flexibility an API as suggested in this series could be

If we need flexibilty, not only an API shoule be added. We should add new element
in the XML config file. It means that libvirt should support inflexibility and
flexibilty. It is very bad. If we want to support flexibility later, it is
better to support it now.

Thanks.
Wen Congyang

> added. 
> 
> Thanks
> Nikunj
> 




More information about the libvir-list mailing list