On 01/18/2013 12:29 PM, Luiz Capitulino wrote: > Signed-off-by: Luiz Capitulino <lcapitul...@redhat.com> > --- > 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/ > + 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? 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)? > + > + - 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/ > + > +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? It might be worth showing which command line arguments set up this particular QOM path. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
