All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@alinoe.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Jeff Garzik <jeff@garzik.org>, linux-kernel@vger.kernel.org
Subject: Re: SATA Harddisk speed drop of 100 MB/s
Date: Fri, 22 Jun 2007 18:21:42 +0200	[thread overview]
Message-ID: <20070622162142.GA603@alinoe.com> (raw)
In-Reply-To: <1182397012.2863.0.camel@laptopd505.fenrus.org>

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>

  reply	other threads:[~2007-06-22 16:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-20 22:48 SATA Harddisk speed drop of 100 MB/s Carlo Wood
2007-06-20 23:06 ` Jeff Garzik
2007-06-21  3:36   ` Arjan van de Ven
2007-06-22 16:21     ` Carlo Wood [this message]
2007-06-22 21:17       ` Henrique de Moraes Holschuh
2007-06-22 21:27         ` Carlo Wood
2007-06-23  1:31           ` Henrique de Moraes Holschuh
2007-06-23  2:59             ` Carlo Wood
2007-06-23 17:29               ` Andrew Morton
2007-06-23 22:21                 ` Jeff Garzik
2007-06-25 15:18               ` Lennart Sorensen
2007-06-25 16:04                 ` Carlo Wood
2007-06-22 21:44   ` SATA RAID5 " Carlo Wood
2007-06-23  3:54     ` Carlo Wood
2007-06-23  6:22       ` Tejun Heo
2007-06-22 21:48   ` Carlo Wood
2007-06-23  7:03     ` Jeff Garzik
2007-06-23  7:54       ` Tejun Heo
2007-06-23 12:53       ` Carlo Wood
2007-06-23 17:30         ` Bartlomiej Zolnierkiewicz
2007-06-23 22:43         ` Jeff Garzik
2007-06-24 11:58           ` Michael Tokarev
2007-06-24 12:59             ` Dr. David Alan Gilbert
2007-06-24 14:21               ` Justin Piszcz
2007-06-24 15:52                 ` Michael Tokarev
2007-06-24 16:59                   ` Justin Piszcz
2007-06-24 22:07                     ` Carlo Wood
2007-06-24 23:46                       ` Mark Lord
2007-06-25  0:23                       ` Patrick Mau
2007-06-24 15:48               ` Michael Tokarev
2007-07-05 22:12             ` Phillip Susi
2007-06-24  0:54       ` Eyal Lebedinsky
  -- strict thread matches above, loose matches on Subject: below --
2007-06-23  5:26 SATA Harddisk " Al Boldi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070622162142.GA603@alinoe.com \
    --to=carlo@alinoe.com \
    --cc=arjan@infradead.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.