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