Date: Thu, 18 Oct 2007 00:02:19 -0200 From: "Bruno Tavares" <brunotm@gmail.com> To: "Ulf Lilleengen" <lulf@stud.ntnu.no>, freebsd-hackers@freebsd.org, s223560@studenti.ing.unipi.it, luigi@freebsd.org Subject: Re: Pluggable Disk Scheduler Project Message-ID: <787586d00710171902o59c82171y1e972ff51c2174b6@mail.gmail.com> In-Reply-To: <20071017143954.GU99087@gandalf.sssup.it> 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> <20071017143954.GU99087@gandalf.sssup.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/17/07, Fabio Checconi <fabio@freebsd.org> wrote: > > 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... > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?787586d00710171902o59c82171y1e972ff51c2174b6>