From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NSvYG-0003hi-NS
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:49:36 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NSvYC-0003en-6T
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:49:36 -0500
Received: from [199.232.76.173] (port=60285 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NSvYB-0003ei-PV
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:49:31 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39786)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1NSvYB-0000ng-7v
	for qemu-devel@nongnu.org; Thu, 07 Jan 2010 11:49:31 -0500
Message-ID: <4B460E55.9090800@redhat.com>
Date: Thu, 07 Jan 2010 18:39:49 +0200
From: Avi Kivity <avi@redhat.com>
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>
In-Reply-To: <1262881658.2767.12.camel@aglitke>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Adam Litke <agl@us.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Luiz Capitulino <lcapitulino@redhat.com>

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.

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