From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np8nv-0001DD-Gd for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:25:35 -0500 Received: from [199.232.76.173] (port=36101 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np8nu-0001Ca-Rg for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:25:34 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np8nt-0007Xx-LD for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:25:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44151) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np8nt-0007Xr-7V for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:25:33 -0500 Date: Tue, 9 Mar 2010 20:25:23 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event Message-ID: <20100309202523.3887bbad@redhat.com> In-Reply-To: <20100309202203.37faa8fa@redhat.com> References: <1268175216-3600-1-git-send-email-lcapitulino@redhat.com> <4B96D4F1.80405@codemonkey.ws> <20100309202203.37faa8fa@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: kwolf@redhat.com, uril@redhat.com, qemu-devel@nongnu.org On Tue, 9 Mar 2010 20:22:03 -0300 Luiz Capitulino wrote: > On Tue, 09 Mar 2010 17:08:33 -0600 > Anthony Liguori wrote: > > > On 03/09/2010 04:53 PM, Luiz Capitulino wrote: > > > Hi, > > > > > > This series is based on a previous series submitted by Uri Lublin: > > > > > > http://lists.gnu.org/archive/html/qemu-devel/2009-03/msg00864.html > > > > > > Details on the patches, except for this question: does it make sense to have > > > a 'low' watermark for block devices? > > > > > > I think it doesn't, then the event (and the monitor accompanying command) > > > should be called BLOCK_HIGH_WATERMARK. But this makes the event very > > > unflexible, so I have called it BLOCK_WATERMARK and added parameters for the > > > high/low watermark type. > > > > > > > The alternative way to implement this is for a management tool to just > > poll the allocated disk size periodically. > > > > It's no more/less safe than generating an event on a "watermark" because > > the event is still racy with respect to a guest that's writing very > > quickly to the disk. > > The argument against polling is not only about possible races, but > it's something very inefficient to do as the condition you're polling > for may never happen but you're wasting cpu resources for it. Also note that this applies for other events and if this becomes the standard mode of operation, the end result is that we're delegating event generation for the management tools.