linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Asdo <asdo@shiftmail.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: MD write performance issue - found Catalyst patches
Date: Thu, 29 Oct 2009 09:08:53 +0100	[thread overview]
Message-ID: <4AE94D95.4060303@shiftmail.org> (raw)
In-Reply-To: <19177.14609.138378.581065@notabene.brown>

Neil Brown wrote:
> I've had a look at this and asked around and I'm afraid there doesn't
> seem to be an easy answer.
>
> The most likely difference between 'before' and 'after' those patches
> is that more pages are being written per call to generic_writepages in
> the 'before' case.  This would generally improve throughput,
> particularly with RAID5 which would get more full stripes.
>
> However that is largely a guess as the bugs which were fixed by the
> patch could interact in interesting ways with XFS (which decrements
> ->nr_to_write itself) and it isn't immediately clear to me that more
> pages would be written... 
>
> In any case, the 'after' code is clearly correct, so if throughput can
> really be increased, the change should be somewhere else.
>   
Thank you Neil for looking into this

How can "writing less pages" be more correct than "writing more pages"?
I can see the first as an optimization to the second, however if this 
reduces throughput then the optimization doesn't work...
Isn't it possible to "fix" it so to write more pages and still be 
semantically correct?


Thomas Fjellstrom wrote:
> I don't suppose this causes "bursty" writeout like I've been seeing lately? 
> For some reason writes go full speed for a short while and then just stop 
> for a short time, which averages out to 2-4x slower than what the array 
> should be capable of.
>   
I have definitely seen this bursty behaviour on 2.6.31.

It would be interesting to know what are the CPUs doing or waiting for 
in the pause times. But I am not a kernel expert :-( how could one check 
this?

Thank you

  parent reply	other threads:[~2009-10-29  8:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-18 10:00 MD write performance issue - found Catalyst patches mark delfman
2009-10-18 22:39 ` NeilBrown
2009-10-29  6:41 ` Neil Brown
2009-10-29  6:48   ` Thomas Fjellstrom
2009-10-29  7:32     ` Thomas Fjellstrom
2009-10-29  8:08   ` Asdo [this message]
2009-10-31 10:51     ` mark delfman
2009-11-03  4:58       ` Neil Brown
2009-11-03 12:11         ` mark delfman
2009-11-04 17:15           ` mark delfman
2009-11-04 17:25             ` Asdo
     [not found]               ` <66781b10911050904m407d14d6t7d3bec12578d6500@mail.gmail.com>
2009-11-05 19:09                 ` Asdo
2009-11-06  4:52                   ` Neil Brown
2009-11-06 10:28                     ` Asdo
2009-11-06 10:51                       ` Neil F Brown
2009-11-06 15:51                   ` mark delfman
2009-11-04 19:05             ` Steve Cousins
2009-11-04 22:08               ` 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=4AE94D95.4060303@shiftmail.org \
    --to=asdo@shiftmail.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).