On 11/06/2009 12:50 AM, Adam Litke wrote:
[RFC] virtio: Report new guest memory statistics pertinent to memory ballooningWhen 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
