From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 17 14:40:15 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C6E16A46B for ; Wed, 17 Oct 2007 14:40:15 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by mx1.freebsd.org (Postfix) with ESMTP id 6F93A13C478 for ; Wed, 17 Oct 2007 14:40:13 +0000 (UTC) (envelope-from fabio@freebsd.org) Received: from [10.30.3.4] (HELO granpasso.retis) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 35086095; Wed, 17 Oct 2007 16:28:31 +0200 Received: from granpasso.retis (localhost.retis [127.0.0.1]) by granpasso.retis (8.14.1/8.14.1) with ESMTP id l9HEdtjH085758; Wed, 17 Oct 2007 16:39:55 +0200 (CEST) (envelope-from fabio@freebsd.org) Received: (from fabio@localhost) by granpasso.retis (8.14.1/8.14.1/Submit) id l9HEdst2085757; Wed, 17 Oct 2007 16:39:54 +0200 (CEST) (envelope-from fabio@freebsd.org) X-Authentication-Warning: granpasso.retis: fabio set sender to fabio@freebsd.org using -f Date: Wed, 17 Oct 2007 16:39:54 +0200 From: Fabio Checconi To: Ulf Lilleengen Message-ID: <20071017143954.GU99087@gandalf.sssup.it> Mail-Followup-To: Ulf Lilleengen , freebsd-hackers@freebsd.org, s223560@studenti.ing.unipi.it, luigi@FreeBSD.org References: <20071011022001.GC13480@gandalf.sssup.it> <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de> <20071017110715.GA25075@stud.ntnu.no> <20071017121907.GL99087@gandalf.sssup.it> <20071017130934.GA26180@stud.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071017130934.GA26180@stud.ntnu.no> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org, s223560@studenti.ing.unipi.it, luigi@freebsd.org Subject: Re: Pluggable Disk Scheduler Project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2007 14:40:15 -0000 > From: Ulf Lilleengen > Date: Wed, Oct 17, 2007 03:09:35PM +0200 > > On ons, okt 17, 2007 at 02:19:07 +0200, Fabio Checconi wrote: > > Maybe I've not enough experience/knowledge of the driver subsystem, [...] > If you look at it, Hybrid is just a generalization of the existing > bioq_* API already defined. And this API is used by GEOM classes _before_ > device drivers get the requests AFAIK. > I looked at the Hybrid code, but I don't think that the bioq_* family of calls can be the right place to start, for the problems experienced during the Hybrid development with locking/anticipation and because you can have the same request passing through multiple bioqs during its path to the device (e.g., two stacked geoms using two different bioqs and then a device driver using bioq_* to organize its queue, or geoms using more than one bioq, like raid3; I think the complexity can become unmanageable.) One could even think to configure each single bioq in the system, but things can get very complex in this way. > For a simple example on a driver, the md-driver might be a good place to > look. Note that I have little experience and knowledge of the driver > subsystem myself. > I'll take a look, thanks. > Also note (from the Hybrid page): > * we could not provide support for non work-conserving schedulers, due to a [...] > > This certainly argues for having this in the GEOM layer, but perhaps it's > possible to change the assumtions done in some drivers? The locking issue > should perhaps be better planned though, and an audit of the driver disksort > code is necessary. > I need some more time to think about that :) > Also: > * as said, the ATA driver in 6.x/7.x moves the disksort one layer below the > one we are working at, so this particular work won't help on ATA-based 6.x > machines. > We should figure out how to address this, because the work done at that > layer is mostly a replica of the bioq_*() API. > > So, I see this can get a bit messy thinking of that the ATA drivers does > disksorts on its own, but perhaps it would be possible to fix this by letting > changing the general ATA driver to use it's own pluggable scheduler. > > Anyway, I shouldn't demand that you do this, especially since I don't have > any code or anything to show to, and because you decide what you want to do. I still cannot say if a GEOM scheduler is better than a scheduler put at a lower level, or if the bioq_* interface is better than any other alternative, so your suggestions are welcome. Moreover I'd really like to discuss/work together, or at least do things with some agreement on them. If I'll have the time to experiment with more than one solution I'll be happy to do that. > However, I'd hate to see the Hybrid effort go to waste :) I was hoping some > of the authors of the project would reply with their thoughts, so I CC'ed > them. Well, the work done on Hybrid had also interesting aspects from the algorithm side... but that's another story...