[Engine-devel] what does engine with cpuIdle?

Laszlo Hornyak lhornyak at redhat.com
Tue Sep 11 12:52:51 UTC 2012



----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Laszlo Hornyak" <lhornyak at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Omer Frenkel" <ofrenkel at redhat.com>
> Sent: Tuesday, September 11, 2012 2:34:13 PM
> Subject: Re: [Engine-devel] what does engine with cpuIdle?
> 
> On Tue, Sep 11, 2012 at 07:38:11AM -0400, Laszlo Hornyak wrote:
> > 
> > ----- Original Message -----
> > > From: "Dan Kenigsberg" <danken at redhat.com>
> > > To: "Omer Frenkel" <ofrenkel at redhat.com>
> > > Cc: "Laszlo Hornyak" <lhornyak at redhat.com>, "engine-devel"
> > > <engine-devel at ovirt.org>
> > > Sent: Tuesday, September 11, 2012 9:22:15 AM
> > > Subject: Re: [Engine-devel] what does engine with cpuIdle?
> > > 
> > > On Tue, Sep 11, 2012 at 01:55:01AM -0400, Omer Frenkel wrote:
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "Laszlo Hornyak" <lhornyak at redhat.com>
> > > > > To: "engine-devel" <engine-devel at ovirt.org>
> > > > > Sent: Monday, September 10, 2012 3:51:59 PM
> > > > > Subject: [Engine-devel] what does engine with cpuIdle?
> > > > > 
> > > > > hi,
> > > > > 
> > > > > I am trying to change a behavior in vdsm. When you pass 100%
> > > > > load
> > > > > on
> > > > > a VM, it will stop reporting further load and will keep
> > > > > telling
> > > > > 100%
> > > > > until the load drops under 100% again in it's cpuIdle
> > > > > information.
> > > > > This is totally correct if you have only single-cpu VM's, but
> > > > > it
> > > > > is
> > > > > false when you have multiple vcpu's, I think the cpuIdle
> > > > > information
> > > > > should not be on a 0-100 scale, but on a 0-100*vcpus scale.
> > > > > 
> > > > > So I submitted this patch to vdsm:
> > > > > http://gerrit.ovirt.org/#/c/7892/2
> > > > > and Dan pointed out that some functionality may depend on the
> > > > > value
> > > > > in the 0-100 interval. For me it seems it is ignored and the
> > > > > load
> > > > > is
> > > > > calculated only from sysCpu + userCpu. Does anyone build on
> > > > > the
> > > > > cpuIdle value?
> > > > > 
> > > > > Thanks,
> > > > > Laszlo
> > > > >
> > > > 
> > > > you are right, engine doesn't save cpuIdle for vm,
> > > > so it's not in use in the engine.
> > > 
> > > Laszlo, in this case, I think it would be best to drop this bogus
> > > piece
> > > of information.
> > 
> > Ok.
> > 
> > However, before I abandon this patch:
> 
> Why abandon? I've suggested you to keep it, just make it even
> simpler.

Ok, it is only burocracy, but the new patch will do something completely different than the original, so it does not seem to make sense to continue this patch. It is more simple to make another one.

> 
> > we have a requirement to report cpuSys and cpuUser separately.
> > Afaik
> > in libvirt cpuUser and cpuSys does not include the actual guest
> > time
> > (at least not with KVM), and in this way if we only report cpuSys
> > and
> > cpuUser, the sum does not give the actual load, only a relatively
> > little percentage of it.
> 
> I am not sure I understand what you are saying, but afaik, libvirt's
> relatively-new
> http://libvirt.org/html/libvirt-libvirt.html#virDomainGetCPUStats
> reports the cpu time spent by the entire qemu process - in guest and
> host modes.

It seems like sysCpu + userCpu < cpuTime, therefore something is missing. I will give it another try, maybe something wrong with my hosts.

> 
> > If we have the cpuIdle information in engine,
> > we can calculate the guest time. Therefore, should I - include the
> > guest time in cpuSys or cpuUser?
> > - add another exported field?
> > 
> > And in both case, we will still have to calculate from cpuIdle
> > because
> > libvirt does not tell the guest cpu time :-(
> 
> Now I'm completely at loss. Why should we calculate cpuIdle per VM?
> Haven't we agreed that it is useless?

Well, if libvirt exports the guest time in sysCpu, then we do not have to. But it seems it does not.

> 
> Dan.
> 



More information about the Engine-devel mailing list