From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtH3E-0004O3-LU for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:16:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtH3C-000779-Ul for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:16:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57963) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtH3C-000771-LT for qemu-devel@nongnu.org; Thu, 10 Jan 2013 07:16:02 -0500 Message-ID: <50EEB0FB.80909@redhat.com> Date: Thu, 10 Jan 2013 13:15:55 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <50EE8810.7080507@dlhnet.de> <8738y9l3ka.fsf@blackfin.pond.sub.org> <50EE9E1B.2010805@redhat.com> <87txqpgsq7.fsf@blackfin.pond.sub.org> <50EEAF7D.8070901@redhat.com> <28A74F64-8654-4FA1-A700-2C420CFCD2A1@dlhnet.de> In-Reply-To: <28A74F64-8654-4FA1-A700-2C420CFCD2A1@dlhnet.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: init bs->io_base correctly to avoid locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: kwolf@redhat.com, Markus Armbruster , "qemu-devel@nongnu.org" Il 10/01/2013 13:12, Peter Lieven ha scritto: >> > >> > But perhaps we do not need to start a slice at all when iolimits are >> > set. That is, do >> > >> > bs->slice_start = bs->slice_end = bs->slice_time = 0; >> > >> > or perhaps even nothing at all since bdrv_io_limits_disable should have >> > written those exact values. > Or it was set when the BlockDriverState was initialized. > > I am not familiar enough with the io limits code to decide if not starting a slice > is also correct. I haven't tested it, but if it works, I think it is better. Think of it this way: it doesn't matter whether the first I/O operation comes immediately after limits are set, or 10 seconds later. In the latter case, bdrv_exceed_io_limits will _already_ start a new slice. It is better to be consistent and always delay the start of the slice. Paolo