Variations on fair I/O schedulers

Posted Dec 5, 2008 0:45 UTC (Fri) by ras (subscriber, #33059)
Parent article: Variations on fair I/O schedulers

I recall Ingo arguing against a plugin architecture for the CPU scheduler, and saying something along the lines of "The disk scheduler people probably regret making theirs pluggable". I don't remember his exact words and nor can I find where he said it, so this is a para-phrase.

Maybe they do. But this demonstrates the sort of innovation that can happen once you expose a stable API. At the very least I imagine much of the infighting we see around the CPU scheduler would have gone away if Ingo had seen fit to loosen his control of the CPU scheduler by doing the same thing.

Variations on fair I/O schedulers

Posted Dec 5, 2008 1:16 UTC (Fri) by alankila (guest, #47141) [Link] (1 responses)

There is a good reason to make IO schedulers pluggable: different media may need different scheduling. The canonical example is the flash vs. disk. It makes no sense to calculate optimal write order, or delay IO for flash.

In principle, I personally prefer one relatively well working piece of code over plenty of choice. There is also the argument that code can be written against a particular scheduling model. In a way, the situation is the opposite of what you said: the current unchangeable scheduler creates a stable API for *userland*, which is where the clients of scheduler are.

An example: When the 2.6 kernel arrived, it changed the way yield() operations on threads work, causing some applications to slow down drastically. Imagine if you had had choice of 3 different schedulers, and need to run app A which wants yield() behavior of one scheduler, and app B that wants the yield() of another. It could mean that you might not be able to use these two apps at the same time.

Variations on fair I/O schedulers

Posted Dec 6, 2008 20:42 UTC (Sat) by giraffedata (guest, #1954) [Link]

In principle, I personally prefer one relatively well working piece of code over plenty of choice.

If those were the candidates, I would agree. But in reality, there's a perfectly viable third candidate: plenty of choice, in which one option is something that works relatively well for everyone.

Variations on fair I/O schedulers

Posted Dec 5, 2008 10:08 UTC (Fri) by njs (subscriber, #40338) [Link]

Err, but there's been, like, astonishingly huge amounts of CPU scheduler innovation in Linux? Hacking the source is not really harder than implementing a stable API, you just lose other conveniences like choosing which scheduler at run time.

And in-fighting wouldn't be reduced; it would just shift to fighting over which scheduler got to be the Default, instead of which got to be the One And Only. If anything that would just make things worse, because you'd make it easier for the competing camps to co-exist over a long period and get Bitter, instead of pushing them to come to a resolution one way or another and combine efforts.