[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.