All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Shaohua Li <shli@kernel.org>
Cc: linux-raid@vger.kernel.org
Subject: Re: [patch]raid5: get_active_stripe avoids device_lock
Date: Wed, 9 Apr 2014 15:24:25 +1000	[thread overview]
Message-ID: <20140409152425.4c00fb2e@notabene.brown> (raw)
In-Reply-To: <20140409032742.GA16051@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 3086 bytes --]

On Wed, 9 Apr 2014 11:27:42 +0800 Shaohua Li <shli@kernel.org> wrote:

> On Wed, Apr 09, 2014 at 12:17:29PM +1000, NeilBrown wrote:
> > On Tue, 8 Apr 2014 12:05:53 +0800 Shaohua Li <shli@kernel.org> wrote:
> > 
> > > 
> > > For sequential workload (or request size big workload), get_active_stripe can
> > > find cached stripe. In this case, we always hold device_lock, which exposes a
> > > lot of lock contention for such workload. If stripe count isn't 0, we don't
> > > need hold the lock actually, since we just increase its count. And this is the
> > > hot code path for such workload. Unfortunately we must delete the BUG_ON.
> > > 
> > > Signed-off-by: Shaohua Li <shli@fusionio.com>
> > > ---
> > >  drivers/md/raid5.c |    9 ++-------
> > >  1 file changed, 2 insertions(+), 7 deletions(-)
> > > 
> > > Index: linux/drivers/md/raid5.c
> > > ===================================================================
> > > --- linux.orig/drivers/md/raid5.c	2014-04-08 09:16:39.377536607 +0800
> > > +++ linux/drivers/md/raid5.c	2014-04-08 09:16:39.369536607 +0800
> > > @@ -679,14 +679,9 @@ get_active_stripe(struct r5conf *conf, s
> > >  				init_stripe(sh, sector, previous);
> > >  				atomic_inc(&sh->count);
> > >  			}
> > > -		} else {
> > > +		} else if (!atomic_add_unless(&sh->count, 1, 0)) {
> > 
> > Can I be really fussy and ask you to use "atomic_inc_not_zero" rather than
> > "atomic_add_unless" ??
> > I feel it makes the code a bit clearer.
> 
> Missed this API. Yes, it's better.
> 
> 
> Subject: raid5: get_active_stripe avoids device_lock
> 
> For sequential workload (or request size big workload), get_active_stripe can
> find cached stripe. In this case, we always hold device_lock, which exposes a
> lot of lock contention for such workload. If stripe count isn't 0, we don't
> need hold the lock actually, since we just increase its count. And this is the
> hot code path for such workload. Unfortunately we must delete the BUG_ON.
> 
> Signed-off-by: Shaohua Li <shli@fusionio.com>
> ---
>  drivers/md/raid5.c |    9 ++-------
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> Index: linux/drivers/md/raid5.c
> ===================================================================
> --- linux.orig/drivers/md/raid5.c	2014-04-09 11:07:01.165231305 +0800
> +++ linux/drivers/md/raid5.c	2014-04-09 11:07:26.492913067 +0800
> @@ -679,14 +679,9 @@ get_active_stripe(struct r5conf *conf, s
>  				init_stripe(sh, sector, previous);
>  				atomic_inc(&sh->count);
>  			}
> -		} else {
> +		} else if (!atomic_inc_not_zero(&sh->count)) {
>  			spin_lock(&conf->device_lock);
> -			if (atomic_read(&sh->count)) {
> -				BUG_ON(!list_empty(&sh->lru)
> -				    && !test_bit(STRIPE_EXPANDING, &sh->state)
> -				    && !test_bit(STRIPE_ON_UNPLUG_LIST, &sh->state)
> -					);
> -			} else {
> +			if (!atomic_read(&sh->count)) {
>  				if (!test_bit(STRIPE_HANDLE, &sh->state))
>  					atomic_inc(&conf->active_stripes);
>  				BUG_ON(list_empty(&sh->lru) &&


Applied, thanks.

NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

      reply	other threads:[~2014-04-09  5:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-08  4:05 [patch]raid5: get_active_stripe avoids device_lock Shaohua Li
2014-04-09  2:17 ` NeilBrown
2014-04-09  3:27   ` Shaohua Li
2014-04-09  5:24     ` NeilBrown [this message]

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=20140409152425.4c00fb2e@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=shli@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 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.