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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"