Pluggable Disk Scheduler Project
BearPerson at gmx.net
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:
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
This point may not be immediately obvious to people coming from the
IO/filesystem field, but it is something we should keep in mind.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20071019/c421a90d/signature.pgp
More information about the freebsd-hackers