[lkml]   [2001]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [resent PATCH] Re: very slow parallel read performance
    On Sun, 26 Aug 2001, Marc A. Lehmann wrote:
    > On Sun, Aug 26, 2001 at 12:32:09AM -0300, Rik van Riel <> wrote:
    > > Reality check time indeed. If you propose that disabling
    > > readahead should improve read performance something fishy
    > > is going on ;)
    > Actually, I also believe that. If you have no memory to store
    > read-ahead data then your only chance is what I try to do: massively
    > parallelize reads so the elevator can optimize what's possible and do
    > no read-ahead whatsoever.

    Margo Selzer wrote a nice paper on letting an elevator
    algorithm take care of request sorting. Only at the point
    where several thousand requests were queued and latency
    to get something from disk grew to about 30 seconds did
    a disk system relying on just an elevator get anything
    close to decent throughput.

    This paper convinced me that doing just elevator sorting
    is never enough ;)

    > The problem is that read-ahead (seems to) go completely havoc when
    > read()'s are issued in many threads at the same time.

    In that case, probably the readahead windows are too large
    or the cache memory used for these readahead pages is too

    One thing you could do, in recent -ac kernels, is make the
    maximum readahead size smaller by lowering the value in


    IA64: a worthy successor to i860.

    Send all your spam to (spam digging piggy)

    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 12:58    [W:0.023 / U:20.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site