lkml.org 
[lkml]   [2004]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 14:02    [W:0.021 / U:30.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site