From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSvf2-0003Qd-GB for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:56:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSvey-0003Oz-RU for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:56:36 -0500 Received: from [199.232.76.173] (port=48933 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSvey-0003Ou-O0 for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:56:32 -0500 Received: from mx20.gnu.org ([199.232.41.8]:16089) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSvew-0002wN-Cf for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:56:32 -0500 Received: from mail-gx0-f223.google.com ([209.85.217.223]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSveq-0000jg-3H for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:56:24 -0500 Received: by gxk23 with SMTP id 23so21836496gxk.2 for ; Thu, 07 Jan 2010 08:56:20 -0800 (PST) Message-ID: <4B461233.2020808@codemonkey.ws> Date: Thu, 07 Jan 2010 10:56:19 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver References: <1262711318.10698.104.camel@aglitke> <4B45F9CA.7050903@codemonkey.ws> <20100107154918.GB19168@redhat.com> <1262881658.2767.12.camel@aglitke> <4B460E55.9090800@redhat.com> In-Reply-To: <4B460E55.9090800@redhat.com> 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: Avi Kivity Cc: Luiz Capitulino , qemu-devel , Adam Litke On 01/07/2010 10:39 AM, Avi Kivity wrote: > On 01/07/2010 06:27 PM, Adam Litke wrote: >> >>> I think 'info-balloon' should be synchronous and without side-effects. >>> ie return the current stats that QEMU has. We could then add a separate >>> 'refresh-balloon' command + async event notification when that >>> completes. >>> The tool that is requiring the stats could thus refresh as often as it >>> likes. >> This would work well for the QMP case, but what about for a traditional >> monitor? We could include a sequence number or timestamp in the memory >> stats results so the user could tell that they were updated. This >> doesn't seem very user friendly though > > A user would have an easier time logging into the guest and using its > native tools. Yeah, without objections, I like having info-balloon attempt to refresh stats, timeout after 10s, and return the last reported stats. I think it also satisfies danpb's criteria of not wasting cpu cycles polling. Regards, Anthony Liguori