From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSwdD-0004We-Qg for qemu-devel@nongnu.org; Thu, 07 Jan 2010 12:58:47 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSwd9-0004S5-RC for qemu-devel@nongnu.org; Thu, 07 Jan 2010 12:58:47 -0500 Received: from [199.232.76.173] (port=50415 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSwd9-0004Rv-ES for qemu-devel@nongnu.org; Thu, 07 Jan 2010 12:58:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:25680) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSwd8-0006ka-6K for qemu-devel@nongnu.org; Thu, 07 Jan 2010 12:58:42 -0500 Date: Thu, 7 Jan 2010 15:58:30 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver Message-ID: <20100107155830.71fc3f76@doriath> In-Reply-To: <4B461233.2020808@codemonkey.ws> References: <1262711318.10698.104.camel@aglitke> <4B45F9CA.7050903@codemonkey.ws> <20100107154918.GB19168@redhat.com> <1262881658.2767.12.camel@aglitke> <4B460E55.9090800@redhat.com> <4B461233.2020808@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel , Avi Kivity , Adam Litke On Thu, 07 Jan 2010 10:56:19 -0600 Anthony Liguori wrote: > 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. I'm not sure I agree with that, running 'info balloon' in the Monitor is more convenient than logging specially if you're testing something related to balloon. > 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. I like Daniel's idea too. In practice 'refresh-balloon' is going to be Anthony's idea #1 for the QMP case, which seems the right way to do it with QMP. The only problem though is the user Monitor. Ideally handlers should not try to know if they are in QMP or not. I would be ok with that in this case, but if we get more asynchronous handlers doing this we will really need an better interface for that.