lkml.org 
[lkml]   [2001]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [resent PATCH] Re: very slow parallel read performance
    On Sun, Aug 26, 2001 at 12:32:09AM -0300, Rik van Riel <riel@conectiva.com.br> 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.

    Of course, in general, read-ahead is a must. Using 256k socket buffer
    + 128k userspace bounce buffer is, effectively, a 384k read-ahead per
    connenction (the average connection speed is about 8k/s btw, so thats
    about one read every 16 seconds. 16 seconds is also about the time between
    sending out the response headers and the beginning of the data transfer,
    which is ok in my case). The problem is that read-ahead (seems to) go
    completely havoc when read()'s are issued in many threads at the same time.

    --
    -----==- |
    ----==-- _ |
    ---==---(_)__ __ ____ __ Marc Lehmann +--
    --==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
    -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
    The choice of a GNU generation |
    |
    -
    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 12:58    [W:0.021 / U:211.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site