From: Chris Snook <csnook@redhat.com>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: Bill Davidsen <davidsen@tmr.com>, linux-kernel@vger.kernel.org
Subject: Re: RAID-1 performance under 2.4 and 2.6
Date: Wed, 26 Mar 2008 12:51:41 -0400 [thread overview]
Message-ID: <47EA7F1D.9@redhat.com> (raw)
In-Reply-To: <20080326090527.42286e8e@galadriel.home>
Emmanuel Florac wrote:
> Le Tue, 25 Mar 2008 19:42:28 -0400 vous écriviez:
>
>> And this is what I was saying earlier, there is a trend to blame the
>> benchmark when in fact the same benchmark runs well on 2.4.
>
> As I mentioned, it looks like 2.4 actually buffers write data on RAID-1
> which is inherently bad (after all if I do RAID-1 it's for the sake of
> data integrity, and write caching just counters that).
> However, how bad dd may be, it reflects broadly my problem : on small
> systems using software RAID, IO is overall way better with 2.4 than
> 2.6, especially NFS thruput.
> Though I can substantially enhance 2.6 performance through tweaking
> (playing with read ahead, disk queue length etc), it still lags behind
> 2.4 with defaults settings by a clear margin (10% or more).
> This isn't true - fortunately - of larger systems with 12, 24, 48 disks
> drives, hardware RAID, Fibre Channel and al.
>
This sounds more like a VM issue than a RAID issue. I suspect the
interesting difference between your small systems and your large systems
is the amount of RAM, not the storage. On small systems, the penalty
for sizing caches incorrectly is much greater, so small systems tend to
suffer more if the default tunings are a little off.
If you do some VM tuning (particularly in /proc/sys/vm) and find that it
makes a large difference, please do report it. Most of the exciting VM
work is targeted to the high end, not the low end, so it's quite
possible that the heuristics which choose default VM parameters at boot
time are no longer as good for small systems as they once were.
-- Chris
next prev parent reply other threads:[~2008-03-26 16:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 18:43 RAID-1 performance under 2.4 and 2.6 Emmanuel Florac
2008-03-25 22:00 ` Chris Snook
2008-03-25 22:09 ` Emmanuel Florac
2008-03-25 22:47 ` Bill Davidsen
2008-03-25 23:13 ` Chris Snook
2008-03-25 23:42 ` Bill Davidsen
2008-03-26 8:05 ` Emmanuel Florac
2008-03-26 8:25 ` "J.A. Magallón"
2008-03-27 21:49 ` Bill Davidsen
2008-03-26 16:51 ` Chris Snook [this message]
2008-03-26 16:39 ` Chris Snook
2008-07-16 14:52 ` Pádraig Brady
2008-07-16 18:18 ` Chris Snook
2008-03-26 7:15 ` Bart Van Assche
2008-03-26 7:56 ` Emmanuel Florac
2008-03-27 21:53 ` Bill Davidsen
2008-03-28 7:44 ` Bart Van Assche
2008-03-28 12:04 ` Bill Davidsen
2008-03-25 22:37 ` Bill Davidsen
2008-03-26 8:42 ` Bart Van Assche
2008-03-26 11:07 ` Emmanuel Florac
2008-03-26 11:15 ` Bart Van Assche
2008-03-26 12:36 ` Emmanuel Florac
2008-03-26 13:22 ` Bart Van Assche
2008-03-27 22:03 ` Bill Davidsen
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=47EA7F1D.9@redhat.com \
--to=csnook@redhat.com \
--cc=davidsen@tmr.com \
--cc=eflorac@intellique.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox