[lkml]   [2001]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Unresponiveness of 2.4.16
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:13    [W:0.094 / U:1.724 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site