All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: Robert Kierski <rkierski@cray.com>
Cc: Phil Turmel <philip@turmel.org>,
	Dallas Clement <dallas.a.clement@gmail.com>,
	"linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: RAID 5,6 sequential writing seems slower in newer kernels
Date: Fri, 4 Dec 2015 10:51:55 -0800	[thread overview]
Message-ID: <20151204185155.GA3590@kernel.org> (raw)
In-Reply-To: <F7761B9B1D11B64BBB666019E9378117FDE157@CFWEX01.americas.cray.com>

On Fri, Dec 04, 2015 at 01:40:02PM +0000, Robert Kierski wrote:
> It turns out the problem I'm experiencing is related to thread count.  When I run XDD with a reasonable queuedepth parameter (32), I get horrible performance.  When I run it with a small queuedepth (1-4), I get expected performance.
> 
> Here are the command lines:
> 
> Horrible Performance:
> xdd -id commandline -dio -maxall -targets 1 /dev/md0 -queuedepth 32  -blocksize 1048576 -timelimit 10 -reqsize 1 -mbytes 5000 -passes 20 -verbose -op write -seek sequential
> 
> GOOD Performance:
> xdd -id commandline -dio -maxall -targets 1 /dev/md0 -queuedepth 1 -blocksize 1048576 -timelimit 10 -reqsize 1 -mbytes 5000 -passes 20 -verbose -op write -seek sequential
> 
> BEST Performance:
> xdd -id commandline -dio -maxall -targets 1 /dev/md0 -queuedepth 3 -blocksize 1048576 -timelimit 10 -reqsize 1 -mbytes 5000 -passes 20 -verbose -op write -seek sequential
> 
> BAD Performance
> xdd -id commandline -dio -maxall -targets 1 /dev/md1 -queuedepth 5 -blocksize 1048576 -timelimit 10 -reqsize 1 -mbytes 5000 -passes 20 -verbose -op write -seek sequential

the performance issue only happens for directIO write, right? did you check
buffered write? The directIO case doesn't delay write, so will create more
read-modify-write. you can check with below debug code.


diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 45933c1..d480cc3 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5278,10 +5278,10 @@ static void make_request(struct mddev *mddev, struct bio * bi)
 			}
 			set_bit(STRIPE_HANDLE, &sh->state);
 			clear_bit(STRIPE_DELAYED, &sh->state);
-			if ((!sh->batch_head || sh == sh->batch_head) &&
-			    (bi->bi_rw & REQ_SYNC) &&
-			    !test_and_set_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
-				atomic_inc(&conf->preread_active_stripes);
+//			if ((!sh->batch_head || sh == sh->batch_head) &&
+//			    (bi->bi_rw & REQ_SYNC) &&
+//			    !test_and_set_bit(STRIPE_PREREAD_ACTIVE, &sh->state))
+//				atomic_inc(&conf->preread_active_stripes);
 			release_stripe_plug(mddev, sh);
 		} else {
 			/* cannot get stripe for read-ahead, just give-up */

  parent reply	other threads:[~2015-12-04 18:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 23:02 RAID 5,6 sequential writing seems slower in newer kernels Dallas Clement
2015-12-02  1:07 ` keld
2015-12-02 14:18   ` Robert Kierski
2015-12-02 14:45     ` Phil Turmel
2015-12-02 15:28       ` Robert Kierski
2015-12-02 15:37         ` Phil Turmel
2015-12-02 15:44           ` Robert Kierski
2015-12-02 15:51             ` Phil Turmel
2015-12-02 19:50               ` Dallas Clement
2015-12-03  0:12                 ` Dallas Clement
2015-12-03  2:18                   ` Phil Turmel
2015-12-03  2:24                     ` Dallas Clement
2015-12-03  2:33                       ` Dallas Clement
2015-12-03  2:38                         ` Phil Turmel
2015-12-03  2:51                           ` Dallas Clement
2015-12-03  4:30                             ` Phil Turmel
2015-12-03  4:49                               ` Dallas Clement
2015-12-03 13:43                               ` Robert Kierski
2015-12-03 14:37                                 ` Phil Turmel
2015-12-03  2:34                       ` Phil Turmel
2015-12-03 14:19                 ` Robert Kierski
2015-12-03 14:39                   ` Dallas Clement
2015-12-03 15:04                   ` Phil Turmel
2015-12-03 22:21                     ` Weedy
2015-12-04 13:40                     ` Robert Kierski
2015-12-04 16:08                       ` Dallas Clement
2015-12-07 14:29                         ` Robert Kierski
2015-12-08 19:38                           ` Dallas Clement
2015-12-08 21:24                             ` Robert Kierski
2015-12-04 18:51                       ` Shaohua Li [this message]
2015-12-05  1:38                         ` Dallas Clement
2015-12-07 14:18                         ` Robert Kierski
2015-12-02 15:37       ` Robert Kierski
2015-12-02  5:22 ` Roman Mamedov
2015-12-02 14:15 ` Robert Kierski

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=20151204185155.GA3590@kernel.org \
    --to=shli@kernel.org \
    --cc=dallas.a.clement@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=philip@turmel.org \
    --cc=rkierski@cray.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.