On Thu, 14 Jul 2011 16:14:01 +0900, Taku Izumi <izumi.t...@jp.fujitsu.com>
wrote:
> On Wed, 13 Jul 2011 16:55:28 +0800
> Wen Congyang <we...@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 <we...@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.
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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
