Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning

[Avi Kivity <avi@redhat.com>]

On 11/06/2009 12:50 AM, Adam Litke wrote:
>      [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning
>
>      When using ballooning to manage overcommitted memory on a host, a system for
>      guests to communicate their memory usage to the host can provide information
>      that will minimize the impact of ballooning on the guests.  The current method
>      employs a daemon running in each guest that communicates memory statistics to a
>      host daemon at a specified time interval.  The host daemon aggregates this
>      information and inflates and/or deflates balloons according to the level of
>      host memory pressure.  This approach is effective but overly complex since a
>      daemon must be installed inside each guest and coordinated to communicate with
>      the host.  A simpler approach is to collect memory statistics in the virtio
>      balloon driver and communicate them to the host via the device config space.
>
>      This patch implements the qemu side of the communication channel.  I will post
>      the kernel driver modifications in-reply to this message.
>
>      I'd like to pose a few questions concerning my implementation:
>
>       * Is there a better way to use feature codes than using one per variable?
>
>       * This patch causes the 'info balloon' monitor command to generate output like
>         the following:
>
>      	(qemu) info balloon
>      	balloon: actual=1024 MB
>      	balloon: pswapin=0 pages
>      	balloon: pswapout=0 pages
>      	balloon: panon=3928 KB
>      	balloon: pgmajfault=0
>      	balloon: pgminfault=247914
>      	balloon: memfree=987032 KB
>      	balloon: memtot=1020812 KB
>
>         Is this agreeable?
>    

It's important that these statistics be cross platform.  Can you (or 
someone knowledgeable in Windows) verify that all of these are 
meaningful there?  I'd expect it to be so with the possible exception of 
panon.

Can you explain how the host would use these?  I can see how major 
faults are interesting, but how is the minor faults statistic useful?

Normally I'd ask that the values be in machine readable form, but with 
the machine monitor protocol, that's not necessary.

-- 
error compiling committee.c: too many arguments to function