Hi, Daniel, Matthias
Thank you for your comments.
On Mon, 4 Apr 2011 14:30:32 +0200
Matthias Bolte <matthias.bolte@xxxxxxxxxxxxxx> wrote:
> 2011/4/4 Daniel P. Berrange <berrange@xxxxxxxxxx>:
> > 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@xxxxxxxxxxxxxx> wrote:
> >>
> >> > 2011/4/1 Eric Blake <eblake@xxxxxxxxxx>:
> >> > > 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@xxxxxxxxxxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list