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

2011/4/4 Daniel P. Berrange <berrange(a)redhat.com&gt;: > 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&gt; wrote: >> >> > 2011/4/1 Eric Blake <eblake(a)redhat.com&gt;: >> > > 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