Date: Wed, 17 Oct 2007 13:07:15 +0200 From: Ulf Lilleengen <lulf@stud.ntnu.no> To: Karsten Behrmann <BearPerson@gmx.net> Cc: freebsd-hackers@freebsd.org, Fabio Checconi <fabio@freebsd.org> Subject: Re: Pluggable Disk Scheduler Project Message-ID: <20071017110715.GA25075@stud.ntnu.no> In-Reply-To: <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de> References: <20071011022001.GC13480@gandalf.sssup.it> <20071016161037.5ab1b74f@39-25.mops.rwth-aachen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On tir, okt 16, 2007 at 04:10:37 +0200, Karsten Behrmann wrote: > > Hi, > > is anybody working on the `Pluggable Disk Scheduler Project' from > > the ideas page? > I've been kicking the idea around in my head, but I'm probably newer to > everything involved than you are, so feel free to pick it up. If you want, > we can toss some ideas and code to each other, though I don't really > have anything on the latter. > > [...] > > After reading [1], [2] and its follow-ups the main problems that > > need to be addressed seem to be: > > > > o is working on disk scheduling worth at all? > Probably, one of the main applications would be to make the background > fsck a little more well-behaved. I agree, as I said before, the ability to give I/O priorities is probably one of the most important things. > > > o Where is the right place (in GEOM) for a disk scheduler? [...] > > > o How can anticipation be introduced into the GEOM framework? > I wouldn't focus on just anticipation, but also other types of > schedulers (I/O scheduling influenced by nice value?) > > > o What can be an interface for disk schedulers? > good question, but geom seems a good start ;) > > > o How to deal with devices that handle multiple request per time? > Bad news first: this is most disks out there, in a way ;) > SCSI has tagged queuing, ATA has native command queing or > whatever the ata people came up over their morning coffee today. > I'll mention a bit more about this further down. > > > o How to deal with metadata requests and other VFS issues? > Like any other disk request, though for priority-respecting > schedulers this may get rather interesting. > > [...] > > The main idea is to allow the scheduler to enqueue the requests > > having only one (other small fixed numbers can be better on some > > hardware) outstanding request and to pass new requests to its > > provider only after the service of the previous one ended. [...] > - servers where anticipatory performs better than elevator > - realtime environments that need a scheduler fitting their needs > - the background fsck, if someone implements a "priority" scheduler Apache is actally a good candidate according to the old antipacitory design document ( not sure of it's relevance today, but...) 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 because of the following reasons: - It makes it possible to use by _both_ GEOM classes and device drivers (Which might use some other scheduler type?). - Does not remove any configuratbility, since changing etc. can be done by user with sysctl. - Could make it possible for a GEOM class to decide for itself which scheduler it wants to use (most GEOM classes uses the standard bioq_disksort interface in disk_subr.c). - The ability to stack a GEOM class with a scheduler could easily be "emulated" by creating a GEOM class to utilize the disksched framework. All in all, I just think this approach gives more flexibility than putting it in a GEOM class that have to be added manually by a user. Just my thought on this. 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. -- Ulf Lilleengen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071017110715.GA25075>