Date: Wed, 17 Oct 2007 14:19:07 +0200 From: Fabio Checconi <fabio@freebsd.org> To: Ulf Lilleengen <lulf@stud.ntnu.no> Cc: Karsten Behrmann <BearPerson@gmx.net>, freebsd-hackers@freebsd.org Subject: Re: Pluggable Disk Scheduler Project Message-ID: <20071017121907.GL99087@gandalf.sssup.it> In-Reply-To: <20071017110715.GA25075@stud.ntnu.no> References: <20071011022001.GC13480@gandalf.sssup.it> <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de> <20071017110715.GA25075@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 01:07:15PM +0200 > > On tir, okt 16, 2007 at 04:10:37 +0200, Karsten Behrmann wrote: > Over to a more general view of it's architecture: > > When I looked at this project for the first time, I was under the impression > that this would be best done in a GEOM class. > > However, I think the approach that was taken in the Hybrid project is better Ok. I think that such a solution requires a lot more effort on the design and coding sides, as it requires the modification of the drivers and can bring us problems with locking and with the queueing assumptions that may vary on a per-driver basis. Maybe I've not enough experience/knowledge of the driver subsystem, but I would not remove the queueing that is done now by the drivers (think of ata freezepoints,) but instead I'd like to try to grab the requests before they get to the driver (e.g., in/before their d_strategy call) and have some sort of pull mechanism when requests complete (still don't have any (serious) idea on that, I fear that the right place to do that, for locking issues and so on, can be driver dependent.) Any ideas on that? Which drivers can be good starting points to try to write down some code? > Also, I got my test-box up again today, and will be trying your patch as soon > as I've upgraded it to CURRENT Fabio. Thank you very much! Please consider that my primary concern with the patch was its interface, the algorithm is just an example (it should give an idea of the performance loss due to the mechanism overhead with async requests, and some improvement on greedy sync loads.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017121907.GL99087>