From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lrumu-00065N-Fl
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:59:28 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lrump-000632-Af
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:59:27 -0400
Received: from [199.232.76.173] (port=38545 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lrumo-00062k-LR
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:59:23 -0400
Received: from yx-out-1718.google.com ([74.125.44.152]:28284)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Lrumn-0003aV-S3
	for qemu-devel@nongnu.org; Thu, 09 Apr 2009 09:59:22 -0400
Received: by yx-out-1718.google.com with SMTP id 34so377527yxf.82
	for <qemu-devel@nongnu.org>; Thu, 09 Apr 2009 06:59:20 -0700 (PDT)
Message-ID: <49DDFF35.50808@codemonkey.ws>
Date: Thu, 09 Apr 2009 08:59:17 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor
	'wait' command
References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com>	
	<1239200204-4934-2-git-send-email-aliguori@us.ibm.com>	
	<20090408143335.GS18076@redhat.com>	<49DCBCBE.6010102@redhat.com>	
	<49DCE266.9080809@us.ibm.com>
	<20090408190611.GC10947@shareable.org>	
	<49DCFC90.8070805@codemonkey.ws>	
	<1239222488.21926.39.camel@slate.austin.ibm.com>	
	<49DD13CA.5050209@codemonkey.ws>
	<1239226294.21926.45.camel@slate.austin.ibm.com>
In-Reply-To: <1239226294.21926.45.camel@slate.austin.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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: Hollis Blanchard <hollisb@us.ibm.com>
Cc: libvir-list@redhat.com, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>

Hollis Blanchard wrote:
> On Wed, 2009-04-08 at 16:14 -0500, Anthony Liguori wrote:
>   
>> It has to be some finite amount.   You're right, it's arbitrary, but so 
>> is every other memory limitation we have in QEMU.  You could make it 
>> user configurable but that's just punting the problem.
>>
>> You have to do some level of buffering.  It's unavoidable.  If you 
>> aren't buffering at the event level, you buffer at the socket level, etc.
>>     
>
> If the socket will buffer it, why do you *also* want to buffer in qemu
> (adding code and complexity)?
>   

If you fill the socket buffer, you have two choices.  You can sleep, 
which is unacceptable in QEMU since we're single threaded, or you can 
drop data.  If you drop data in something like the monitor, it will lead 
to corruption which is unrecoverable for a management tool.

You have to push that information higher up the stack so that the thing 
pushing data can make more intelligent decisions about what to drop.  In 
this case, we're dropping anything older than 10 minutes.  We'll 
probably need an max-number of events too but right now, it's based on time.

Regards,

Anthony Liguori