[libvirt] [PATCHv2 08/11] qemu: bulk stats: implement VCPU group
Francesco Romani
fromani at redhat.com
Wed Sep 3 09:11:32 UTC 2014
----- Original Message -----
> From: "Eric Blake" <eblake at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>, libvir-list at redhat.com
> Sent: Wednesday, September 3, 2014 1:00:53 AM
> Subject: Re: [libvirt] [PATCHv2 08/11] qemu: bulk stats: implement VCPU group
>
> On 09/02/2014 06:31 AM, Francesco Romani wrote:
> > This patch implements the VIR_DOMAIN_STATS_VCPU
> > group of statistics.
> >
> > Signed-off-by: Francesco Romani <fromani at redhat.com>
> > ---
> > include/libvirt/libvirt.h.in | 1 +
> > src/libvirt.c | 8 +++++
> > src/qemu/qemu_driver.c | 72
> > ++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 81 insertions(+)
> >
>
> > *
> > + * VIR_DOMAIN_STATS_VCPU: Return virtual CPU statistics.
> > + * The typed parameter keys are in this format:
> > + * "vcpu.current" - current number of online virtual CPUs
> > + * "vcpu.maximum" - maximum number of online virtual CPUs
> > + * "vcpu.<num>.state" - state of the virtual CPU <num>
>
> Is this an int mapping to some particular enum?
Yep: virVcpuState. Will document this.
> > + * "vcpu.<num>.time" - virtual cpu time spent by virtual CPU <num>
> > + * "vcpu.<num>.cpu" - physical CPU pinned to virtual CPU <num>
>
> Missing types.
>
> Should there be a parameter vcpu.count that says how many vcpu.<num>
> entries to expect? Or is that vcpu.current? Or do we have a situation
> where if cpus 0 and 2 are online but 1 and 3 are offline, then we have
> vcpu.0.x and vcpu2.x but not vcpu1.x?
Yes, the latter, due to VCPU hot(un)plugging
> A bit more documentation will help the user deciding which "array"
> entries to expect, and whether the "array" will be sparse if cpus are
> offline.
Will document that the array will be up to "vcpu.maximum" items, could
be sparse and the actual size will be of "vcpu.current" items.
> > +{
> > + size_t i;
> > + int ret = -1;
> > + char param_name[NAME_MAX];
>
> NAME_MAX (typically 256) is huge, compared to
> VIR_TYPED_PARAM_FIELD_LENGTH (80).
Will switch to VIR_TYPED_PARAM_FIELD_LENGTH here and everywhere I used
NAME_MAX.
Thanks,
--
Francesco Romani
RedHat Engineering Virtualization R & D
Phone: 8261328
IRC: fromani
More information about the libvir-list
mailing list