[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 August 26, 2001 04:49 am, ( Marc) (A.) (Lehmann ) wrote:
    > On Sun, Aug 26, 2001 at 03:38:34AM +0200, Daniel Phillips
    <> wrote:
    > > Let's test the idea that readahead is the problem. If it is, then
    > > readahead should make the lowlevel disk throughput match the highlevel
    > > throughput. Marc, could you please try it with this patch:
    > No, I rebooted the machine before your mail and sinc wehtis is a production
    > server.. ;)
    > Anyway, I compiled and bootet into linux-2.4.8-ac9. I jused ac8 on my
    > desktop machines and was not pleased with absolute performance but, unlike
    > the linus' series, I can listen to mp3's while working which was the
    > killer feature for me ;)

    Yes, this probably points at a bug in linus's tree. This needs more digging.
    You're streaming the mp3's over the net or from your disk?

    > anyway, AFAIU, one can tune raedahead dynamically under the ac9 series by
    > changing:
    > isldoom:/proc/sys/vm# cat max-readahead
    > 31
    > If this is equivalent to your patch, then fine.

    My patch would be equivalent to:

    echo 0 >/proc/sys/vm/max-readahead

    This was just to see if that makes the highlevel throughput match the
    lowlevel throughput, eliminating one variable from the equation. In -ac you
    have a much more convenient way of doing that.

    > if not I will test it at a later time. Now, a question: how does the
    > per-block-device read-ahead fit into this picture? Is it being ignored? I
    > fiddled with it (under 2.4.8pre4) but couldn't see any difference.

    It should not be being ignored. This needs to be looked into. In any event,
    the max-readahead proc setting is clearly good and needs to be in Linus's
    tree, otherwise changing the default MAX_READAHEAD requires a recompile.
    Worse, there is no way at all to specify the kernel's max-readahead for scsi
    disks - regardless of the fact that scsi disks do their own readahead, the
    kernel will do its own as well, with no way for the user to turn it off.

    > [...]
    > Now the interesting part. setting read-ahead to 31 again, I increased the
    > number of reader threads from one to 64 and got 3.8MB (@450 connections, I
    > had to restart the server).
    > So the ac9 kernel seems to work much better (than the linus' series),
    > although the number of connections was below the critical limit. I'll
    > check this when I get higher loads again.

    The reason for that is still unclear. I realize you're testing this under
    live load (you're a brave man) but let's try a bringing the -ac max-readahead
    patch across and try it in 2.4.9.

    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.026 / U:0.928 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site