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

Re: [libvirt] [PATCH 1/6] virNodeGetCpuTime: Expose new API



Hi, Daniel, Matthias
Thank you for your comments.

On Mon, 4 Apr 2011 14:30:32 +0200
Matthias Bolte <matthias bolte googlemail com> wrote:

> 2011/4/4 Daniel P. Berrange <berrange redhat com>:
> > On Mon, Apr 04, 2011 at 11:03:10AM +0900, Minoru Usui wrote:
> >> Hi, Matthias.
> >>
> >> On Fri, 1 Apr 2011 20:22:17 +0200
> >> Matthias Bolte <matthias bolte googlemail com> wrote:
> >>
> >> > 2011/4/1 Eric Blake <eblake redhat com>:
> >> > > On 03/31/2011 07:55 PM, Minoru Usui wrote:
> >> > >> virNodeGetCpuTime: Expose new API
> >> > >>
> >> > >>  include/libvirt/libvirt.h.in |   26 ++++++++++++++++++++++++++
> >> > >>  src/libvirt_public.syms      |    1 +
> >> > >>  2 files changed, 27 insertions(+), 0 deletions(-)
> >> > >
> >> > >>
> >> > >> +/**
> >> > >> + * virNodeCpuTime:
> >> > >> + *
> >> > >> + * a virNodeCpuTime is a structure filled by virNodeGetCpuTime() and providing
> >> > >> + * the information for the cpu time of Node.
> >> > >> + */
> >> > >> +
> >> > >> +typedef struct _virNodeCpuTime virNodeCpuTime;
> >> > >> +
> >> > >> +struct _virNodeCpuTime {
> >> > >> +    unsigned long long user;
> >> > >> +    unsigned long long system;
> >> > >> +    unsigned long long idle;
> >> > >> +    unsigned long long iowait;
> >> > >> +};
> >> > >
> >> > > Can we portably get all of this information on Windows?  If not, how do
> >> > > you express which values we don't know how to obtain?
> >> > >
> >> >
> >> > In the context of ESX I vote against this absolute CPU time values.
> >> > ESX provides this values relative to a 20 second timeslots with 1 hour
> >> > of history. This makes it nearly impossible to obtain the absolute CPU
> >> > time. The same problem already exists for the domain's virtual CPU
> >> > time.
> >> >
> >> > When you look at virt-top's usage of the domain's virtual CPU time,
> >> > you see that it actually doesn't really care about the absolute value,
> >> > but deduces the CPU utilization from it. I suggest that we find a
> >> > different representation for this information that is not by
> >> > definition impossible to implement for ESX.
> >> >
> >> > Matthias
> >>
> >> I didn't know ESX couldn't return absolute CPU time value.
> >> Thank you for your comment.
> >>
> >> We really want to get CPU utilization information of the node, not
> >> absolute CPU time values.
> >> But linux doesn't provide CPU utilization directly,
> >> so my patch returns absolute CPU time values,
> >> and CPU utilization is calculated by client which uses new API.
> >>
> >> To return CPU utilization by new API, I think there are two issues of implementing on linux.
> >>
> >>   a) How much interval does calculate CPU utilization?
> >>      To calculate CPU utilization on linux, we need to get absolute CPU time value of the node
> >>      from /proc/stat two times.
> >>      How much interval properly? 1sec? 1min? or others?
> >
> > The fact that there is the question of what is the right interval
> > demonstrates the inherant flaw in such an API design. Providing
> > the raw absolute time allows an app much more flexiblity in how
> > they work with the data, avoiding the need for such policies in
> > libvirt.
> >
> >>   b) Can new API wait its interval?
> >>      If we select simply implementation, new API waits its interval.
> >>      But API user don't want to wait every API calls, if its interval is long.
> >>      So I think libvirtd will be calculating CPU utilization in background every interval.
> >>      Is this approach OK?
> >
> > IMHO we don't really want libvirtd to be constantly polling & calculating
> > this data, at least not unless an application is currently asking for it.
> > I think we want this API to have the style that is like the current
> > virDomainMemoryStats  API. Then, we can define a set of parameters that
> > can be fetched, allowing each parameter to be optional
> >
> > eg
> >
> >  enum {
> >     VIR_NODE_CPU_TIME_KERNEL,
> >     VIR_NODE_CPU_TIME_USER,
> >     VIR_NODE_CPU_TIME_IDLE,
> >     VIR_NODE_CPU_TIME_IOWAIT,
> >     VIR_NODE_CPU_TIME_UTILIZATION,
> >  };
> >
> > For QEMU we'd provide the first 4 values, allowing apps maximum
> > flexibility in how they calculate utilization over different time
> > periods. For VMWare we'd provide only the last value.
> >
> > An app like virt-manager, can display UTILIZATION value directly if
> > that is present, otherwise it will be able to calculate data from
> > the other times as it does now for domains. So it would work with
> > both QEMU and VMWare, to the best of its abilities.
> >
> > Regards,
> > Daniel
> >
> 
> For ESX the driver doesn't even need to calculate a usage/utilization
> value, because the ESX server already does this on it's own and the
> driver can just ask for it. The usage value is in percent and 100%
> represents all CPUs on the server.
> 
> I like that approach.
> 
> Matthias

OK.
I'll change the user I/F to above one.

-- 
Minoru Usui <usui mxm nes nec co jp>


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