From: Asdo <asdo@shiftmail.org>
To: mark delfman <markdelfman@googlemail.com>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: MD write performance issue
Date: Fri, 16 Oct 2009 12:42:16 +0200 [thread overview]
Message-ID: <4AD84E08.7020807@shiftmail.org> (raw)
In-Reply-To: <66781b10910160145r59f3ea0cqc8632dbc3d92f833@mail.gmail.com>
mark delfman wrote:
> After further work we are sure that there is a significant write
> performance issue with either the Kernel+MD or...
Hm!
Pretty strange repeated ups and downs of the speed with increasing
kernel versions.
Have you checked:
that compile options are the same (preferably by taking 2.6.31 compile
options and porting them down)
disk schedulers are the same
the test was long enough to level jitters, like 2-3 minutes
Also: looking at "iostat -x 1" during the transfer could show something...
Apart from this, I confirm I noticed in my 2.6.31-rc? earlier tests,
that performances on xfs writes were very inconsistent :
These were my benchmarks (I wrote them on file at that time):
Stripe_cache_size was 1024, 13 devices raid-5:
bs=1M -> 206MB/s
bs=256K -> 229MB/s
retrying soon after, identical settings:
bs=1M -> 129MB/s
bs=256K -> 140MB/s
Transfer speed was hence very unreliable, depending on something that is
not clearly user visible... maybe dirty page cache? I thought that
depending on the exact amount of data being pushed out by the pdflush at
the first round, that would cause a sequence of read-modify-write stuff
which would cause further read-modify-write and further instability
later on. But I was doing that with raid-5 while you Mark are using
raid-0 right? My theory doesn't hold on raid-0.
next prev parent reply other threads:[~2009-10-16 10:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 8:45 MD write performance issue mark delfman
2009-10-16 10:42 ` Asdo [this message]
2009-10-16 15:46 ` mark delfman
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=4AD84E08.7020807@shiftmail.org \
--to=asdo@shiftmail.org \
--cc=linux-raid@vger.kernel.org \
--cc=markdelfman@googlemail.com \
/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;
as well as URLs for NNTP newsgroup(s).