From: Shaohua Li <shli@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: linux-raid@vger.kernel.org, neilb@suse.de, axboe@kernel.dk,
shli@fusionio.com
Subject: Re: [patch 5/9 v2] raid5: reduce chance release_stripe() taking device_lock
Date: Thu, 21 Jun 2012 09:34:36 +0800 [thread overview]
Message-ID: <20120621013436.GA9154@kernel.org> (raw)
In-Reply-To: <CABE8wwuX3KT4ryd2MN9V9+DUaMraAOnyOSW9GdDxoyidhQjgRg@mail.gmail.com>
On Wed, Jun 20, 2012 at 05:56:25PM -0700, Dan Williams wrote:
> On Mon, Jun 18, 2012 at 6:59 PM, Shaohua Li <shli@kernel.org> wrote:
> > release_stripe() is a place conf->device_lock is heavily contended. We take the
> > lock even stripe count isn't 1, which isn't required. On the on the other hand,
> > decreasing count first and taking lock if count is 0 can expose races:
> > 1. bewteen dec count and taking lock, another thread hits the stripe in cache,
> > so increase count. The stripe will be deleted from any list. In this case
> > stripe count isn't 0.
> > 2. between dec count and taking lock, another thread hits the stripe in cache
> > and release it. In this case the stripe is already in specific list. We do
> > list_move to adjust its position.
> > So both cases are fixable to me.
> >
>
> These "1" and "2" comments no longer apply right? atomic_dec_and_lock
> is equivalently safe to lock+dec_and_test.
Oh, I misunderstand atomic_dec_and_lock is dec and lock instead of lock and
dec, so there is no race. The other two deletion isn't required too. I'll
repost this patch.
Thanks,
Shaohua
next prev parent reply other threads:[~2012-06-21 1:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-19 1:59 [patch 0/9 v2] raid5: improve write performance for fast storage Shaohua Li
2012-06-19 1:59 ` [patch 1/9 v2] raid5: use wake_up_all for overlap waking Shaohua Li
2012-06-19 1:59 ` [patch 2/9 v2] raid5: add a per-stripe lock Shaohua Li
2012-06-19 1:59 ` [patch 3/9 v2] raid5: lockless access raid5 overrided bi_phys_segments Shaohua Li
2012-06-21 1:56 ` Dan Williams
2012-06-19 1:59 ` [patch 4/9 v2] raid5: remove some device_lock locking places Shaohua Li
2012-06-19 1:59 ` [patch 5/9 v2] raid5: reduce chance release_stripe() taking device_lock Shaohua Li
2012-06-21 0:56 ` Dan Williams
2012-06-21 1:34 ` Shaohua Li [this message]
2012-06-19 1:59 ` [patch 6/9 v2] md: personality can provide unplug private data Shaohua Li
2012-06-19 1:59 ` [patch 7/9 v2] raid5: make_request use batch stripe release Shaohua Li
2012-06-19 1:59 ` [patch 8/9 v2] raid5: raid5d handle stripe in batch way Shaohua Li
2012-06-19 1:59 ` [patch 9/9 v2] raid5: create multiple threads to handle stripes Shaohua Li
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=20120621013436.GA9154@kernel.org \
--to=shli@kernel.org \
--cc=axboe@kernel.dk \
--cc=dan.j.williams@intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
--cc=shli@fusionio.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 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).