Pluggable Disk Scheduler Project

Karsten Behrmann BearPerson at
Fri Oct 19 11:21:55 PDT 2007

> I wouldn't focus on just anticipation, but also other types of
> schedulers (I/O scheduling influenced by nice value?)

One note on this subject: it will be nice for things like bg-fsck,
but it also brings up a point that has been overlooked so far:
priority propagation.

As far as I am aware, there's plenty of locks that a process can
hold while waiting for I/O to complete (directories, snapshots,
probably some others I missed)
Now, normally when a high-priority thread needs a lock owned by
another process, it'll bump up that thread's priority and yield,
hopefully freeing the lock up quickly.
This is obviously not quite so easy for IO. I haven't quite
understood the code involved yet, as far as I can tell turnstiles
panic when the lock-owning thread is sleeping.

What we'll probably need to do is make priority propagation wake
up a waiting-for-io process, which then needs to dig up its IO
request (which may be anywhere in geom, but potentially held back
by the scheduler) and make sure it's [re]queued with higher
If we don't do this, we'll get funny effects with a bg-fsck blocking
some high-priority process indefinitely because it happens to be
waiting for IO and holding the snapshot lock, on an IO-busy system.
If we do this, we may get into significant fun with cutting into
geom to allow requeuing, or waste some cpu with polling from the
queuing geom.

This point may not be immediately obvious to people coming from the
IO/filesystem field, but it is something we should keep in mind.

So Far,
  Karsten Behrmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the freebsd-hackers mailing list