Messages in this thread | | | Date | Mon, 3 May 2004 13:57:19 -0700 | From | Andrew Morton <> | Subject | Re: Random file I/O regressions in 2.6 |
| |
Ram Pai <linuxram@us.ibm.com> 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 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/
| |