From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42470 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnTGH-0008NM-D4 for qemu-devel@nongnu.org; Mon, 23 Aug 2010 05:24:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnTGF-00050c-Qd for qemu-devel@nongnu.org; Mon, 23 Aug 2010 05:24:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24620) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnTGF-00050P-IX for qemu-devel@nongnu.org; Mon, 23 Aug 2010 05:24:11 -0400 Date: Mon, 23 Aug 2010 10:24:01 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH V2] balloon: Don't try fetching info if machine is stopped Message-ID: <20100823092401.GB28382@redhat.com> References: <8450ea8e785c9049f0b3edddc01650a8c4b9ffe7.1282265244.git.amit.shah@redhat.com> <4C719C7E.6030606@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C719C7E.6030606@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Amit Shah , Paolo Bonzini , Juan Quintela , qemu list , agl@us.ibm.com On Sun, Aug 22, 2010 at 04:54:06PM -0500, Anthony Liguori wrote: > On 08/19/2010 07:48 PM, Amit Shah wrote: > >If the machine is stopped and 'info balloon' is invoked, the monitor > >process just hangs waiting for info from the guest. Return the most > >recent balloon data in that case. > > > >See https://bugzilla.redhat.com/show_bug.cgi?id=623903 > > > >Reported-by: > >Signed-off-by: Amit Shah > > > > !vm_running is just a special case of an unresponsive guest. Even if > the guest was running, if it was oops'd and the administrator didn't > know, you would have the same issue. > > I'd suggest using a timeout based on rt_clock. If the stats request > times out, print an appropriate message to the user. By all means add a timeout to cope with a unresponsive guest, but in this case where we can be sure the guest can't respond there's no point waiting on a timeout. On a tangent, a future todo item I mentioned to some people at the summit, is that I'd like to see the interaction with the balloon driver change/enhanced. It is currently hard/impossible to use this in an efficient manner. We should never have overloaded the existing balloon command with guest memstats refresh + data, because it has made 'query balloon' a significantly slower command than it was, in particular you can no longer rely on it being a 'fast' response, or even responding at all. This is bad when all you care about is the balloon actual level, and not the guest memstats. I'd like to see something along the lines of: - 'query balloon' to return the balloon + memstats values that are *currently* known to QEMU. Probably need a new name to avoid changing semantics of the existing command - 'balloon changed' event to indicate when the balloon actual level has changed (so we never need to poll on 'query balloon') - 'update memstats' to request an guest kernel mem stats update - 'memstats updated' event (or update memstats async reply) to indicate when the guest kernel has refreshed the mem stats. Primarily I'd like to avoid having to invoke anything at all to get the main balloon driver actual memory level. Being able to fetch the memstats without also triggering an update is fairly useful too though. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|