From owner-freebsd-current@FreeBSD.ORG Fri Jul 15 00:46:23 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 D8EA016A41C; Fri, 15 Jul 2005 00:46:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF9343D45; Fri, 15 Jul 2005 00:46:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6F0pPMN080515; Thu, 14 Jul 2005 18:51:25 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42D7075F.5070907@samsco.org> Date: Thu, 14 Jul 2005 18:46:23 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo 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> <20050712160935.A58434@xorpc.icir.org> <20050714155616.A56618@xorpc.icir.org> In-Reply-To: <20050714155616.A56618@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org 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: Fri, 15 Jul 2005 00:46:24 -0000 Luigi Rizzo wrote: > S > On Tue, Jul 12, 2005 at 04:09:35PM -0700, Luigi Rizzo wrote: > >>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 ? > > > So, rethinking about this oldish thread, you said: > > >>On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote: >>... > > ... > >>>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. > > > [please correct me if i am wrong] > > it seems a suitable place would be intercept dev_strategy(bp), > however i am not totally clear how i can reach the bioq > from there -- geom has a field > bp->bio_disk->d_queue, > but it does not seem to be universally used, e.g. > scsi_da uses > bp->bio_disk->d_drv1->softc->bio_queue > ata in 5.x uses > bp->bio_disk->d_drv1->queue > and so on. > > So if you intercept dev_strategy() you really need to stall I/O > until _all_ devices have drained their backlog, because you > cannot map the request to the individual bioq :( > > cheers > luigi How often are you going to be changing the scheduler at runtime? Is the scheduler meant to be aware of individual devices? Again, I'm not advocating that the upper layers be able to look at or manipulate the driver bioq's. Scott