Pluggable Disk Scheduler Project

[Ulf Lilleengen]

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