[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070622162142.GA603@alinoe.com>
Date: Fri, 22 Jun 2007 18:21:42 +0200
From: Carlo Wood <carlo@...noe.com>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Jeff Garzik <jeff@...zik.org>, linux-kernel@...r.kernel.org
Subject: Re: 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@...noe.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists