Good hacks, or bad ones?
It keeps things localised. It works. It's tunable. It's the best
IO scheduler presently available.
> Arjan's priority based scheme is more promising.
If the IO priority becomes an attribute of the calling process
then an approach like that has value. For writes, the priority
should be driven by VM pressure and it's probably simpler just
to stick the priority into struct buffer_head -> struct request.
For reads, the priority could just be scooped out of *current.
If we're not going to push the IO priority all the way down from
userspace then you may as well keep the logic inside the elevator
and just say reads-go-here and writes-go-there.
But this has potential to turn into a great designfest. Are
we going to leave 2.4 as-is? Please say no.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/