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

[Matthias Bolte]

2011/4/4 Daniel P. Berrange <berrange at 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 at googlemail.com> wrote:
>>
>> > 2011/4/1 Eric Blake <eblake at 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