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.
THE ELEVATOR IS PROBABLY NOT THE PROBLEM.
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.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
