From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N74TB-0005DZ-VY for qemu-devel@nongnu.org; Sun, 08 Nov 2009 04:54:01 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N74T7-00057b-4T for qemu-devel@nongnu.org; Sun, 08 Nov 2009 04:54:01 -0500 Received: from [199.232.76.173] (port=54714 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N74T6-00057P-WF for qemu-devel@nongnu.org; Sun, 08 Nov 2009 04:53:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:47183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N74T6-00012G-DM for qemu-devel@nongnu.org; Sun, 08 Nov 2009 04:53:56 -0500 Message-ID: <4AF6891D.3080308@redhat.com> Date: Sun, 08 Nov 2009 11:02:21 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning References: <1257461425.3121.22.camel@aglitke> In-Reply-To: <1257461425.3121.22.camel@aglitke> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Adam Litke Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org 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