[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] vmfixes-2.4.0-test9-B2

On Mon, 25 Sep 2000, Ingo Molnar wrote:
> >
> > And a new elevator was introduced some months ago to solve this.
> and these are still not solved in the vanilla kernel, as recent complaints
> on l-k prove.


People blame the elevator for bad IO performance. But the elevator is just
doing what it's told to do - and if it is told to do something bad, it
will do something bad.

The "something bad" is doing things like writing out 4 dicsontiguous
pages, waiting a while, and then writing out 4 more discontiguous pages.

There's nothing the elevator can do for that case - except just ignore the
write requests completely, and wait for more requests to come in. Which it
certainly could do, but that's really a policy question and should be
handled at a higher level. The elevator doesn't know if there is going to
be more writes.

In short, I bet that the problem is at least partly that bdflush is
broken, and doesn't do a good job of streaming writes. It's probably been
broken to get low latencies, and in order to avoid "choppy" behaviour. But
the elevator works _best_ with choppy behaviour, when there's a BIG stream
of requests at a time.

Blaming the elevator is unfair and unrealistic. Look at the performance
reports - there was a good test-case that showed that read-performance was
fine but that writes to different parts of the filesystem just suck. Which
is _exactly_ what you'd expect if the elevator was fine but the writes
were blocked up by higher levels.


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

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