From owner-freebsd-current@FreeBSD.ORG Tue Jul 12 23:09:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98AF516A41C; Tue, 12 Jul 2005 23:09:38 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40FD143D5E; Tue, 12 Jul 2005 23:09:37 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j6CN9aKV058541; Tue, 12 Jul 2005 16:09:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j6CN9Zbo058540; Tue, 12 Jul 2005 16:09:35 -0700 (PDT) (envelope-from rizzo) Date: Tue, 12 Jul 2005 16:09:35 -0700 From: Luigi Rizzo To: Scott Long Message-ID: <20050712160935.A58434@xorpc.icir.org> References: <20050705053114.A96381@xorpc.icir.org> <35386.1120575587@phk.freebsd.dk> <20050705103353.A8185@xorpc.icir.org> <20050708110742.A6284@xorpc.icir.org> <20050708203537.H34251@fledge.watson.org> <20050708155827.A10658@xorpc.icir.org> <42D419C2.6040606@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <42D419C2.6040606@samsco.org>; from scottl@samsco.org on Tue, Jul 12, 2005 at 01:28:02PM -0600 Cc: s223560@studenti.ing.unipi.it, Robert Watson , current@freebsd.org Subject: Re: location of bioq lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2005 23:09:38 -0000 The approach you suggest in the second part sounds interesting, except that i have no idea where i should intercept the calls in the block layer. Any suggestion ? Re. the first part, i don't fully follow your reasoning probably because i have in mind a different setting - one where the driver has already offloaded to the scheduler (through its API) all operations on the bioq, and where the only usage of the lock is on an exceptional situation -- a scheduler switch -- where you can probably tolerate some small delays. The variant lock methods are also not much a of an issue - if a bioq uses a supported method then it is allowed to use the pluggable interface, otherwise it just uses whatever the default is. cheers luigi On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote: ... > > Ah, now I understand. The downside to exporting the lock is that > it opens the possibility of a layer outside of the driver holding > the lock long enough to do undesirable things like delay interrupt > processing. Also, allowing an outside layer to peek at the bioq > contents breaks the assumption that most drivers have that they own > the queue and can handle it as they see fit. It's often times > desirable to look at the head of the bioq but not dequeue the > bio object until you know for sure that it'll be delivered to the > hardware. Also, what about in-flight bio's? It's up to the driver > to decide whether to complete or requeue bio's that might have been > defered due to lack of resources or a transient errors. How will > the action of re-ordering the queue from an outside layer handle > this? And finally, if you do export a lock from the driver, you > cannot assume that it'll be a sleep mutex. You'll need to handle > the possibility of a spinlock, sx lock, semaphore, etc. > > An alternate approach that I would suggest is to have the disk scheduler > freeze the block layer from delivering any new bio's while waiting for > all of the outstanding bio's to complete, then flip the scheduler > algorithm and allow i/o delivery to resume. That way there is no > need to play with driver locks, no need to rummage around in resources > that are private to the driver, and no need to worry about in-flight > bio's. It also removes the need to touch every driver with an API > change. > > Scott