Re: [libvirt] [PATCH 1/6] virNodeGetCpuTime: Expose new API
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(a)googlemail.com> wrote:
> 2011/4/1 Eric Blake <eblake(a)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
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|