Date: Wed, 17 Oct 2007 16:39:54 +0200 From: Fabio Checconi <fabio@freebsd.org> To: Ulf Lilleengen <lulf@stud.ntnu.no> Cc: freebsd-hackers@freebsd.org, s223560@studenti.ing.unipi.it, luigi@freebsd.org Subject: Re: Pluggable Disk Scheduler Project Message-ID: <20071017143954.GU99087@gandalf.sssup.it> In-Reply-To: <20071017130934.GA26180@stud.ntnu.no> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Ulf Lilleengen <lulf@stud.ntnu.no> > 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...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017143954.GU99087>