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

[Taku Izumi]

On Wed, 13 Jul 2011 16:55:28 +0800
Wen Congyang <wency at cn.fujitsu.com> wrote:

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

 I think nobody needs such a flexibility in the future and I like the simpler way.
 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 ?
 If you can't, shall we decide by lot? ;)

-- 
Best regards,
Taku Izumi <izumi.taku at jp.fujitsu.com>