lkml.org 
[lkml]   [2002]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BENCHMARK] 2.4.{18,19{-ck9},20rc1{-aa1}} with contest
On Sun, Nov 10, 2002 at 08:03:01PM -0800, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> >
> > the slowdown happens in this case:
> >
> > queue 5 6 7 8 9
> >
> > insert read 3
> >
> > queue 3 5 6 7 8 9
>
> read-latency will not do that.

So what will it do? Must do something very much like what I described or
it is a noop period. Please elaborate.

>
> > However I think even read-latency is more a workarond to a problem in
> > the I/O queue dimensions.
>
> The problem is the 2.4 algorithm. If a read is not mergeable or
> insertable it is placed at the tail of the queue. Which is the
> worst possible place it can be put because applications wait on
> reads, not on writes.

O_SYNC/-osync waits on writes too, so are you saying writes must go to
the head because of that? reads should be not too bad at the end too if
only the queue wasn't that oversized when the merging is at its maximum.
Fix the oversizing of the queue, then read-latency will matter much
less.

Andrea
-
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/

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