From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N83BL-0003so-D3 for qemu-devel@nongnu.org; Tue, 10 Nov 2009 21:43:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N83BG-0003rs-SE for qemu-devel@nongnu.org; Tue, 10 Nov 2009 21:43:39 -0500 Received: from [199.232.76.173] (port=44286 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N83BG-0003rm-NE for qemu-devel@nongnu.org; Tue, 10 Nov 2009 21:43:34 -0500 Received: from ozlabs.org ([203.10.76.45]:46949) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N83BG-0003JZ-4m for qemu-devel@nongnu.org; Tue, 10 Nov 2009 21:43:34 -0500 From: Rusty Russell Date: Wed, 11 Nov 2009 13:13:23 +1030 References: <1257782838.2835.5.camel@aglitke> <200911111032.14956.rusty@rustcorp.com.au> <4AFA005C.7020607@us.ibm.com> In-Reply-To: <4AFA005C.7020607@us.ibm.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200911111313.24226.rusty@rustcorp.com.au> Subject: [Qemu-devel] Re: virtio: Add memory statistics reporting to the balloon driver List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, agl@linux.vnet.ibm.com, qemu-devel@nongnu.org, Avi Kivity On Wed, 11 Nov 2009 10:37:56 am Anthony Liguori wrote: > Rusty Russell wrote: > > You register an outbuf at initialization time. The host hands it back when > > it wants you to refill it with stats. > > That's strangely backwards. Guest send a stat buffer that's filled out, > host acks it when it wants another. That doesn't seem bizarre to you? Yep! But that's a limitation of our brains, not the infrastructure ;) Think of the stats as an infinite stream of data. Read from it at your leisure. This is how, for example, console output works. > > But the universe is remarkably indifferent to what we want. Is it actually > > sufficient or are we going to regret our laziness? > > It's not laziness, it's consistency. How is actual different than free > memory or any other stat? Because it's a COLLECTION of stats. For example, swap in should be < swap out. Now, the current Linux implementation of all_vm_events() is non-atomic anyway, so maybe we can just document this as best-effort. I'm saying that if it *is* a problem, I think we need a vq. But it raises the question: what stats are generally useful cross-OS? Should we be supplying numbers like "unused" (free) "instantly discardable" (ie. clean), "discardable to disk" (ie. file-backed), "discardable to swap" (ie. swap-backed) and "unswappable" instead? (I just made those up, of course, but it seems like that would give a fair indication of real memory pressure in any OS). Thanks, Rusty.