[lkml]   [2004]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Random file I/O regressions in 2.6
Ram Pai <> wrote:
> > The place which needs attention is handle_ra_miss(). But first I'd like to
> > reacquaint myself with the intent behind the lazy-readahead patch. Was
> > never happy with the complexity and special-cases which that introduced.
> lazy-readahead has no role to play here.

Sure. But lazy-readahead is bolted on the side and is generally not to my
liking. I'd like to find a solution to the sysbench problem which also
solves the thing which lazy-readahead addressed.

> The readahead window got closed
> because the i/o pattern was totally random. My guess is multiple threads
> are generating 16k i/o on the same fd. In such a case the i/os can get
> interleaved and the readahead window size goes for a toss(which is
> expected behavior)

I don't think it's that. The app is doing well-aligned 16k reads and
writes. If we get enough pagecache hits on the reads, readahead turns
itself off (fair enough) but fails to turn itself on again.

The readahead logic _should_ be able to adapt to the fixed-sized I/Os and
issue correct-sized reads immediately after each seek. I _think_ this will
fix the problem which lazy-readahead addressed, but as usual we don't have
a rigorous description of that problem :(

> Well if this is infact the case: the question is
> 1. does the i/o pattern really has some sequentiality to
> deserve a readahead?
> 2. or should we ensure that the interleaved case be somehow
> handled, by including the size parameter?
> I know Nick has implied option (2) but I think from the readahead's
> point of view it is (1),

Readahead has got too complex and is getting band-aidy. I'd prefer to tear
it down and rethink things.
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 14:02    [W:0.090 / U:0.188 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site