lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: SATA Harddisk speed drop of 100 MB/s
    On Wed, Jun 20, 2007 at 08:36:52PM -0700, Arjan van de Ven wrote:
    > also do a
    >
    > echo 60 > /proc/sys/vm/dirty_ratio
    >
    > first to see if that helps

    That makes no difference.

    It took a while before I replied - because I first want to do a bisect
    to find a version closer to the problem.

    So far I found out that it's RAID only.

    I have four disks:

    Three times a western digital Raptor 10k rpm:

    ATA device, with non-removable media
    Model Number: WDC WD740ADFD-00NLR1
    Firmware Revision: 20.07P20

    And one Seagate Barracuda 7200 rpm:

    ATA device, with non-removable media
    Model Number: ST3320620AS
    Firmware Revision: 3.AAE

    The Raptors are in RAID5.

    hdparm -tT gives me always > 4 GB/s cached reads, for example:

    Timing cached reads: 8166 MB in 2.00 seconds = 4086.82 MB/sec

    and the buffered disk reads do not significantly vary when
    reading the devices directly (/dev/sda, /dev/sdb, /dev/sdc for
    the Raptors and /dev/sdd for the Barracuda):

    /dev/sda etc: Around 67 MB/sec
    /dev/sdd : Around 75 MB/sec (so much for 10k rpm ...)

    These numbers are weird in itself (the 67 should have been 75,
    and the 75 should have been 54) - but at least they are constant.

    What DOES *signficantly* change as function of kernel revision
    is the buffered disk read with hdparm -tT /dev/md2

    The normal speed I get is > 160, often 165 MB/sec. But with
    kernel revisions over a certain version that drops to around
    67 MB/sec - and at one point I even observed a drop in speed
    every time I repeated the measurement until the speed was
    around 30 MB/s !

    At the moment I am (still) doing the bisect; I had some problems
    compiling a pristine 2.6.18 and some problems with the config
    (that differs significantly between 2.6.18 and 2.6.22) as well
    as the problem that the kernel simply didn't compile for a large
    range of revisions needed for the bisect (I needed to export
    current_is_keventd with this patch:

    diff --git a/kernel/workqueue.c b/kernel/workqueue.c
    index c525731..012e11b 100644
    --- a/kernel/workqueue.c
    +++ b/kernel/workqueue.c
    @@ -654,6 +654,7 @@ int current_is_keventd(void)
    return ret;

    }
    +EXPORT_SYMBOL_GPL(current_is_keventd);

    /* Take the work from this (downed) CPU. */
    static void take_over_work(struct workqueue_struct *wq, unsigned int cpu)
    )

    I'll report back when I'm done with the bisect :)

    --
    Carlo Wood <carlo@alinoe.com>
    -
    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: 2007-06-22 18:25    [W:0.025 / U:0.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site