From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NSu8S-0008GV-AN
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:18:52 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NSu8N-0008EO-Ga
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:18:51 -0500
Received: from [199.232.76.173] (port=54767 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NSu8N-0008EG-Ci
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:18:47 -0500
Received: from mx1.redhat.com ([209.132.183.28]:60028)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NSu8M-0003p7-S1
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 10:18:47 -0500
Message-ID: <4B45FB52.402@redhat.com>
Date: Thu, 07 Jan 2010 17:18:42 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <1262711318.10698.104.camel@aglitke>
	<4B45F9CA.7050903@codemonkey.ws>
In-Reply-To: <4B45F9CA.7050903@codemonkey.ws>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [RFD] virtio: Add memory statistics reporting to
 the balloon driver
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Luiz Capitulino <lcapitulino@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Adam Litke <agl@us.ibm.com>

On 01/07/2010 05:12 PM, Anthony Liguori wrote:
>
> 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.
>
> 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'm on the fence between 3 and 4 myself.
>

Can I tip you over to #4?  #3 means we have no idea when the stats were 
generated.  With #4, we can't be sure, but it usually be close to when 
the command returns.

The command should include a timeout so a broken guest won't hang a 
management tool thread.

-- 
error compiling committee.c: too many arguments to function