All of lore.kernel.org
 help / color / mirror / Atom feed
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.



  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 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.