From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtICM-0007Zx-HS for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:29:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtICL-0001KY-9b for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:29:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtICL-0001JW-2E for qemu-devel@nongnu.org; Thu, 10 Jan 2013 08:29:33 -0500 Message-ID: <50EEC231.4070902@redhat.com> Date: Thu, 10 Jan 2013 14:29:21 +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> <50EEB0FB.80909@redhat.com> <6592CE68-7813-432D-9B76-B6379CAFC2D4@dlhnet.de> In-Reply-To: <6592CE68-7813-432D-9B76-B6379CAFC2D4@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:58, Peter Lieven ha scritto: > > Am 10.01.2013 um 13:15 schrieb Paolo Bonzini : > >> 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. >> > > seems to be working as well. > > are you happy with: > > block: fix initialization in bdrv_io_limits_enable() Sure. Paolo