From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Np8kh-0006lE-0l for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:22:15 -0500 Received: from [199.232.76.173] (port=42641 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Np8kg-0006kd-CW for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:22:14 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Np8kf-0007Bp-3L for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:22:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54954) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Np8ke-0007Bd-NW for qemu-devel@nongnu.org; Tue, 09 Mar 2010 18:22:12 -0500 Date: Tue, 9 Mar 2010 20:22:03 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event Message-ID: <20100309202203.37faa8fa@redhat.com> In-Reply-To: <4B96D4F1.80405@codemonkey.ws> References: <1268175216-3600-1-git-send-email-lcapitulino@redhat.com> <4B96D4F1.80405@codemonkey.ws> 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, 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.