Re: Unresponiveness of 2.4.16

[Andrew Morton <akpm@zip.com.au>]

Jens Axboe wrote:
> 
> I agree that the current i/o scheduler has really bad interactive
> performance -- at first sight your changes looks mostly like add-on
> hacks though.

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.  

-