> 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 priority. 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
signature.asc
Description: PGP signature
