[lkml]   [2007]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 5/9] readahead: on-demand readahead logic
    On Fri, May 18, 2007 at 11:23:35PM -0700, Andrew Morton wrote:
    > That would have to be the best changelog I've ever seen ;) Thanks for
    > persisting with this.

    Thank you :)

    > > sysbench oltp (trans/sec): up to 8% gain
    > Have you given any thought to identifying workloads which may be worsened
    > by your changes? Attempt to deliberately expose any weak spots?

    Yeah. All possible downsides I can imagine are:

    - CPU overheads
    Only random reads will be hurt.
    That's 1% slow down for _sparse files_, and should be much smaller
    when real I/O is involved.

    - Behavior changes
    It do not enforce strict check sequentialness.
    - it is in general a good behavior for interleaved reads and
    clustered-and-intermixed-random/sequential workloads.
    - it might lead to more readahead misses
    E.g. a random read sequence of 0,1,4,12,28,60,92,124,156,188,220
    that is weird enough to start the readahead and hit all the
    lookahead pages.
    I highly doubt the possibility of such patterns happen in real
    world. But if ever it happens repeatedly for some user, he can
    work it around easily by tuning readahead_kb to some other value.

    So, it is only a possibility that some random workload may be
    worsened. But it's really hard to find one real world example.

    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: 2007-05-19 15:05    [W:0.020 / U:5.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site