From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSvDH-0004Xf-6Q for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:27:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSvDC-0004OO-CV for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:27:54 -0500 Received: from [199.232.76.173] (port=50474 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSvDC-0004OD-9H for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:27:50 -0500 Received: from e37.co.us.ibm.com ([32.97.110.158]:51531) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSvDB-0001zK-PP for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:27:50 -0500 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o07GQMXi016098 for ; Thu, 7 Jan 2010 09:26:22 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o07GRdAc162044 for ; Thu, 7 Jan 2010 09:27:39 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o07GRdGf030685 for ; Thu, 7 Jan 2010 09:27:39 -0700 Subject: Re: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to the balloon driver From: Adam Litke In-Reply-To: <20100107154918.GB19168@redhat.com> References: <1262711318.10698.104.camel@aglitke> <4B45F9CA.7050903@codemonkey.ws> <20100107154918.GB19168@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Jan 2010 10:27:38 -0600 Message-ID: <1262881658.2767.12.camel@aglitke> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Luiz Capitulino , Avi Kivity , qemu-devel On Thu, 2010-01-07 at 15:49 +0000, Daniel P. Berrange wrote: > On Thu, Jan 07, 2010 at 09:12:10AM -0600, Anthony Liguori wrote: > > On 01/05/2010 11:08 AM, Adam Litke wrote: > > >This patch has been discussed (and ACKed) in the past, but has not yet > > >been committed due to the congestion surrounding the 0.12 release and > > >other conflicting changes. I would like to rekindle the discussion so > > >that I can make the necessary changes to get this merged. > > > > > >This patch is ported to 0.12.1 and has one issue that I am aware of: > > > > > >It still calls monitor_suspend() and monitor_resume() which I understand > > >is no longer allowed. Does anyone have any ideas on how to enable async > > >monitor commands? > > > > > >+static void request_stats(VirtIOBalloon *vb) > > >+{ > > >+ vb->stats_requested = 1; > > >+ reset_stats(vb); > > >+ monitor_suspend(cur_mon); > > > > > > > This bit is not going to work reliably anymore. Really, it never worked > > reliably but this is exacerbated with -qmp since a QMP session will > > never be the cur_mon. > > > > We have a couple of options: > > > > 1) Introduce a query-balloon command that returns immediately, and > > triggers a request for the guest to update the balloon stats. When the > > guest does update the balloon stats, trigger an asynchronous message. > > Asynchronous messages are ignored by the human monitor so they would > > never be displayed there which is unfortunate. > > > > 2) Make info balloon show the last valid stats and have it request new > > stats. Stats will always be delayed but it avoids async messages. > > > > 3) Make qemu request balloon stats regularly (maybe every 10 seconds) > > and display the latest stats with info balloon. This avoids the problem > > in #2 but it means that qemu determines the poll rate instead of a > > management tool. > > I don't like the idea of the anything which has hardcoded polling because > it just wastes CPU cycles for the 99% of the time when no one is going to > care about these stats. > > > 4) Make info-balloon a proper asynchronous command. We need new > > infrastructure to allow a qmp handler to take a callback that can be > > used to delay the completion of the command. This addresses all of the > > above problems but it introduces a new one. Command completion now > > depends on the guest. This potentially could trip up a naive management > > tool that doesn't realize that the info-balloon command may never complete. > > 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. -- Thanks, Adam