qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/3] qmp: Support for querying stats


From: Daniel P . Berrangé
Subject: Re: [PATCH v4 1/3] qmp: Support for querying stats
Date: Fri, 11 Mar 2022 13:12:02 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

On Fri, Mar 11, 2022 at 02:06:46PM +0100, Markus Armbruster wrote:
> Mark Kanda <mark.kanda@oracle.com> writes:
> 
> > Introduce QMP support for querying stats. Provide a framework for adding new
> > stats and support for the following commands:
> >
> > - query-stats
> > Returns a list of all stats per target type (only VM and vCPU to start), 
> > with
> > additional options for specifying stat names, vCPU qom paths, and providers.
> >
> > - query-stats-schemas
> > Returns a list of stats included in each target type, with an option for
> > specifying the provider.
> >
> > The framework provides a method to register callbacks for these QMP 
> > commands.
> >
> > The first use-case will be for fd-based KVM stats (in an upcoming patch).
> >
> > Examples (with fd-based KVM stats):
> >
> > - Query all VM stats:
> >
> > { "execute": "query-stats", "arguments" : { "target": "vm" } }
> >
> > { "return": {
> >   "vm": [
> >      { "provider": "kvm",
> >        "stats": [
> >           { "name": "max_mmu_page_hash_collisions", "value": 0 },
> >           { "name": "max_mmu_rmap_size", "value": 0 },
> >           { "name": "nx_lpage_splits", "value": 148 },
> >           ...
> >      { "provider": "xyz",
> >        "stats": [ ...
> >      ...
> > ] } }
> >
> > - Query all vCPU stats:
> >
> > { "execute": "query-stats", "arguments" : { "target": "vcpu" } }
> >
> > { "return": {
> >     "vcpus": [
> >       { "path": "/machine/unattached/device[0]"
> >         "providers": [
> >           { "provider": "kvm",
> >             "stats": [
> >               { "name": "guest_mode", "value": 0 },
> >               { "name": "directed_yield_successful", "value": 0 },
> >               { "name": "directed_yield_attempted", "value": 106 },
> >               ...
> >           { "provider": "xyz",
> >             "stats": [ ...
> >            ...
> >       { "path": "/machine/unattached/device[1]"
> >         "providers": [
> >           { "provider": "kvm",
> >             "stats": [...
> >           ...
> > } ] } }
> >
> > - Query 'exits' and 'l1d_flush' KVM stats, and 'somestat' from provider 
> > 'xyz'
> > for vCPUs '/machine/unattached/device[2]' and 
> > '/machine/unattached/device[4]':
> >
> > { "execute": "query-stats",
> >   "arguments": {
> >     "target": "vcpu",
> >     "vcpus": [ "/machine/unattached/device[2]",
> >                "/machine/unattached/device[4]" ],
> >     "filters": [
> >       { "provider": "kvm",
> >         "fields": [ "l1d_flush", "exits" ] },
> >       { "provider": "xyz",
> >         "fields": [ "somestat" ] } ] } }
> 
> Are the stats bulky enough to justfify the extra complexity of
> filtering?

I viewed it more as a mechanism to cope with a scenario where
some stats are expensive to query. If the mgmt app only want
to get one specific cheap stat, we don't want to trigger code
that does expensive queries of other stats as a side effect.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]