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

[mdroth]

On Thu, Dec 06, 2012 at 01:31:09PM -0200, Luiz Capitulino wrote:
> On Thu, 6 Dec 2012 13:24:11 +0000
> "Daniel P. Berrange" <address@hidden> wrote:
> 
> > On Tue, Dec 04, 2012 at 01:04:48PM -0200, Luiz Capitulino wrote:
> > > Signed-off-by: Luiz Capitulino <address@hidden>
> > > ---
> > >  docs/virtio-balloon-stats.txt | 73 
> > > +++++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 73 insertions(+)
> > >  create mode 100644 docs/virtio-balloon-stats.txt
> > > 
> > > diff --git a/docs/virtio-balloon-stats.txt b/docs/virtio-balloon-stats.txt
> > > new file mode 100644
> > > index 0000000..7e7ddc4
> > > --- /dev/null
> > > +++ b/docs/virtio-balloon-stats.txt
> > > @@ -0,0 +1,73 @@
> > > +virtio balloon memory statistics
> > > +================================
> > > +
> > > +The virtio balloon driver supports guest memory statistics reporting. 
> > > These
> > > +statistics are available to QEMU users as QOM (QEMU Obejct Model) device
> > > +properties via a polling mechanism.
> > > +
> > > +Basically, clients have to enable polling. Then they can query the 
> > > available
> > > +statistics.
> > > +
> > > +There are two control properties and six memory statistics from the 
> > > guest.
> > > +
> > > +The control properties are:
> > > +
> > > + o stats-polling-interval: a value greater than zero enables polling
> > > +   in the specified interval (in seconds). When value equals zero,
> > > +   polling is disabled. If polling is already enabled and a value
> > > +   greater than zero is written, the polling interval time is changed
> > > +
> > > + o stats-last-update: last stats update timestamp, in seconds
> > > +
> > > +The memory statistics are:
> > > +
> > > + o stat-swap-in
> > > + o stat-swap-out
> > > + o stat-major-faults
> > > + o stat-minor-faults
> > > + o stat-free-memory
> > > + o stat-total-memory
> > > +
> > > +All values are in bytes. A value of -1 means that the statistic isn't
> > > +available right now.
> > > +
> > > +Here are a few examples. The virtio-balloon device is assumed to be in 
> > > the
> > > +'/machine/peripheral-anon/device[1]' QOM path.
> > > +
> > > +Enable polling with 2 seconds interval:
> > > +
> > > +{ "execute": "qom-set",
> > > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > > +                  "property": "stats-polling-interval", "value": 2 } }
> > > +
> > > +{ "return": {} }
> > > +
> > > +Change polling to 10 seconds:
> > > +
> > > +{ "execute": "qom-set",
> > > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > > +                  "property": "stats-polling-interval", "value": 10 } }
> > > +
> > > +{ "return": {} }
> > > +
> > > +Get last update timestamp and free memory stat:
> > > +
> > > +{ "execute": "qom-get",
> > > +  "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > > +  "property": "stats-last-update" } }
> > > +
> > > +{ "return": 1354629634 }
> > > +
> > > +{ "execute": "qom-get",
> > > +  "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > > +  "property": "stat-free-memory" } }
> > > +
> > > +{ "return": 845115392 }
> > > +
> > > +Disable polling:
> > > +
> > > +{ "execute": "qom-set",
> > > +             "arguments": { "path": "/machine/peripheral-anon/device[1]",
> > > +                  "property": "stats-polling-interval", "value": 0 } }
> > > +
> > > +{ "return": {} }
> > 
> > 
> > What sort of performance implications are there for enabling polling of
> > virtio stats. Is it the kind of thing that it is reasonable to just
> > enable for all VMs on a 10 second interval, so we'll always have stats
> > available without having to have thought to enable them ahead of time ?
> 
> I can't think of any performance implications. Would be nice to get a
> second opinion from the CC'ed people though.

Pushing/popping/processing one vq entry every 10 seconds should be
virtually unnoticeable given that virtio-net/blk do this much more frequently
with much more processing overhead per entry on a relatively idle guest. So
performance-wise, I don't think it's an issue. As to whether or not it
*should* be enabled by default I'm not so sure, but if it actually simplifies
things on that end I'd say it's worth it if the alternatives are
cumbersome.

> 
> > eg, the use case I'm wondering is that someone comes along and just
> > runs   'virsh memstats $DOMAIN' and wants to see the latest data
> > right away. 
> > 
> > I'm not suggesting that libvirt would be actually asking QEMU for the
> > stats every 10 seconds. Only that libvirt tells QEMU to collect them.
> > Then libvirt can just ask for them whenver someone wants them.
> 
> Note that once you enable polling, the balloon driver will immediately make
> a request to the guest, that is, it won't wait the specified time interval to
> send the first request.
> 
> So, the first call to virsh memstats could start polling and also poll for it
> (although you do need to be prepared for the case where the guest doesn't
> respond).
> 
> Also, you could consider adding the time interval in libvirt's API and
> virsh memstats.
>