qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] docs: document virtio-balloon stats


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 3/3] docs: document virtio-balloon stats
Date: Mon, 21 Jan 2013 09:56:08 -0200

On Fri, 18 Jan 2013 13:00:28 -0700
Eric Blake <address@hidden> wrote:

> On 01/18/2013 12:29 PM, Luiz Capitulino wrote:
> > Signed-off-by: Luiz Capitulino <address@hidden>
> > ---
> >  docs/virtio-balloon-stats.txt | 102 
> > ++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 102 insertions(+)
> >  create mode 100644 docs/virtio-balloon-stats.txt
> > 
> 
> > +
> > +  o A key named 'stats', containing all avaiable stats. If the guest
> 
> s/avaiable/available/

OK.

> > +    doesn't support a particular stat, its value will be -1. Currently,
> > +    the following stats are supported:
> > +
> > +      - stat-swap-in
> > +      - stat-swap-out
> > +      - stat-major-faults
> > +      - stat-minor-faults
> > +      - stat-free-memory
> > +      - stat-total-memory
> > +
> > +  o A key named last-update, which contains the last stats update
> > +    timestamp in seconds
> 
> Is it worth mentioning that this is a timestamp relative to the Unix
> epoch?  For that matter, does it even matter what the timestamp is
> relative to, or just that it increases when a new poll completes?

Yes, I think this field is only important to calculate the delta between
updates.

>  Is it
> worth mentioning that the timestamp is computed by the host (that is, a
> broken guest can't fake the timestamp, even if it can provide bogus data
> for all the stats)?

I can mention that.

> > +
> > + - As noted above, if a guest doesn't support a particular stat it
> > +   will always be -1. However, it's also possible that a guest couldn't
> > +   temporarily update one or even all stats. If this happens, just wait
> 
> s/couldn't temporarily/temporarily couldn't/

OK.

> > +
> > +Here are a few examples. The virtio-balloon device is assumed to be in the
> > +'/machine/peripheral-anon/device[1]' QOM path.
> 
> Is this QOM path stable, or can it change depending on target
> architecture and/or command-line arguments used to install the guest?

I think it can change.

> It might be worth showing which command line arguments set up this
> particular QOM path.

Will do.



reply via email to

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