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. 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@xxxxxxxxxxxxxx> -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list