From: Paul Bolle <pebolle@tiscali.nl>
To: Jens Axboe <axboe@kernel.dk>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Vivek Goyal <vgoyal@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] CFQ: use proper locking for cache of last hit cic
Date: Wed, 08 Jun 2011 20:18:44 +0200 [thread overview]
Message-ID: <1307557130.2783.5.camel@t41.thuisdomein> (raw)
In-Reply-To: <4DEC441C.9030009@kernel.dk>
On Mon, 2011-06-06 at 05:06 +0200, Jens Axboe wrote:
> On 2011-06-05 18:26, Paul Bolle wrote:
> > @@ -2704,8 +2706,13 @@ static void __cfq_exit_single_io_context(struct cfq_data *cfqd,
> > smp_wmb();
> > cic->key = cfqd_dead_key(cfqd);
> >
> > - if (ioc->last_cic == cic)
> > + spin_lock_irqsave(&ioc->lock, flags);
> > + rcu_read_lock();
> > + last_cic = rcu_dereference(ioc->last_cic);
> > + rcu_read_unlock();
> > + if (last_cic == cic)
> > rcu_assign_pointer(ioc->last_cic, NULL);
> > + spin_unlock_irqrestore(&ioc->lock, flags);
>
> We don't need the ioc->lock for checking the cache, it would in fact
> defeat the purpose of using RCU.
Just to show that I'm RCU-challenged, is that because:
1) my use of locking on ioc->lock defends for a race that is not
actually possible; or
2) the worst thing that could happen is that some new and correct value
of ioc->last_cic will be replaced with NULL, which is simply not a big
deal?
> But this hunk will clash with the
> merged part anyway.
Looking at Paul's feedback I do have a feeling that in your commit
(9b50902db5eb8a220160fb89e95aa11967998d12, "cfq-iosched: fix locking
around ioc->ioc_data assignment") the line:
if (rcu_dereference(ioc->ioc_data) == cic) {
could actually be replaced with:
if (rcu_access_pointer(ioc->ioc_data) == cic) {
Is that correct?
> [...]
> See Pauls comment on this part.
You seem to be offline right now. When you're back online, could you
please say whether or not you accept the two renaming patches that you
have rejected a few days ago (and for which I gave some follow up
arguments)? After that I'll send an update to this patch (and its commit
message) to reflect Paul's review and your review.
Paul Bolle
next prev parent reply other threads:[~2011-06-08 18:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-05 16:26 Paul Bolle
2011-06-05 16:59 ` Paul E. McKenney
2011-06-06 3:06 ` Jens Axboe
2011-06-08 18:18 ` Paul Bolle [this message]
2011-06-08 18:37 ` Paul E. McKenney
2011-06-08 18:42 ` Vivek Goyal
2011-06-08 19:32 ` Paul Bolle
2011-06-08 20:07 ` Vivek Goyal
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=1307557130.2783.5.camel@t41.thuisdomein \
--to=pebolle@tiscali.nl \
--cc=axboe@kernel.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=vgoyal@redhat.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
all inboxes | Powered by JetHome®