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

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

 



At 07/15/2011 12:03 PM, Nikunj A. Dadhania Write:
> On Thu, 14 Jul 2011 16:14:01 +0900, Taku Izumi <izumi.taku@xxxxxxxxxxxxxx> wrote:
>> On Wed, 13 Jul 2011 16:55:28 +0800
>> Wen Congyang <wency@xxxxxxxxxxxxxx> wrote:
>>
>>> At 07/13/2011 04:50 PM, Nikunj A. Dadhania Write:
>>>> On Wed, 13 Jul 2011 14:26:23 +0800, Wen Congyang <wency@xxxxxxxxxxxxxx> 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.
>>
>>  I think nobody needs such a flexibility in the future and I like the
>>  simpler way.

Okay, I will update the patchset and implement the simple way.

> I had an offline discussion with folks(Adam and Ryan) here at
> IBM. Simulating a machine with different cpu speed does not seem like a
> compelling enough case to justify the added configuration complexity. An
> explicit qouta setting for each vcpu will require user to audit the
> cputune section to add/remove tunings just to change the vcpu count to
> the domain. We do not feel that this is the desired behaviour.
> 
> In our experience, user don't want to make these kinds of
> decisions. They would rather prefer libvirt to just do the right thing
> by default.
> 
> Adam pointed that in the future it is no problem to have the simple API
> and a more detailed API combined:
> 
> <cputune>
>   <period>
>   <quota>
>   <vcpu id=0>
>     <quota>...</quota>
>   </vcpu>
> </cputune>
> 
>>  But, the worst thing is the decision is prolonged. If IBM people can accept the current
>>  implementation, I also do.
>>
>>  Can you accept this, Nikunj ?
> Still not convinced.
> 
>>  If you can't, shall we decide by lot? ;)
> Not sure if this is the right approach. :-)
> 
> danpb/DV, what do you think?
> 
> Regards
> Nikunj
> 

--
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]