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, djbw@fb.com
Subject: Re: [patch 3/3] raid5: relieve lock contention in get_active_stripe()
Date: Wed, 28 Aug 2013 14:32:52 +1000	[thread overview]
Message-ID: <20130828143252.1d48b04b@notabene.brown> (raw)
In-Reply-To: <20130827085330.GA30133@kernel.org>

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

On Tue, 27 Aug 2013 16:53:30 +0800 Shaohua Li <shli@kernel.org> wrote:

> On Tue, Aug 27, 2013 at 01:17:52PM +1000, NeilBrown wrote:

> 
> > Then get_active_stripe wouldn't need to worry about device_lock at all and
> > would only need to get the hash lock for the particular sector.  That should
> > make it a lot simpler.
> 
> did you mean get_active_stripe() doesn't need device_lock for any code path?
> How could it be safe? device_lock still protects something like handle_list,
> delayed_list, which release_stripe() will use while a get_active_stripe can run
> concurrently.

Yes you will still need device_lock to protect list_del_init(&sh->lru),
as well as the hash lock.
Do you need device_lock anywhere else in there?

NeilBrown

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

  reply	other threads:[~2013-08-28  4:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12  2:24 [patch 0/3] raid5: relieve lock contention of get_active_stripe() Shaohua Li
2013-08-12  2:24 ` [patch 1/3] raid5: rename stripe_hash() Shaohua Li
2013-08-12  2:24 ` [patch 2/3] wait: add wait_event_cmd() Shaohua Li
2013-08-12  2:24 ` [patch 3/3] raid5: relieve lock contention in get_active_stripe() Shaohua Li
2013-08-27  3:17   ` NeilBrown
2013-08-27  8:53     ` Shaohua Li
2013-08-28  4:32       ` NeilBrown [this message]
2013-08-28  6:39         ` Shaohua Li
2013-09-03  6:08           ` NeilBrown
2013-09-03  7:02             ` Shaohua Li
2013-09-04  6:41               ` NeilBrown
2013-09-05  5:40                 ` Shaohua Li
2013-09-05  6:29                   ` NeilBrown
2013-09-05  9:18                     ` Shaohua Li
2013-09-09  4:33                       ` Shaohua Li
2013-09-10  1:13                         ` NeilBrown
2013-09-10  2:35                           ` Shaohua Li
2013-09-10  4:06                             ` NeilBrown
2013-09-10  4:24                               ` Shaohua Li
2013-09-10  5:20                                 ` NeilBrown
2013-09-10  6:59                                   ` Shaohua Li
2013-09-10  7:28                                     ` NeilBrown
2013-09-10  7:37                                       ` Shaohua Li
2013-09-11  1:34                                         ` NeilBrown
2013-09-12  1:55                                           ` Shaohua Li
2013-09-12  5:38                                             ` NeilBrown

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=20130828143252.1d48b04b@notabene.brown \
    --to=neilb@suse.de \
    --cc=djbw@fb.com \
    --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.