From: Peter Zijlstra <peterz@infradead.org>
To: Will Deacon <will.deacon@arm.com>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
Boqun Feng <boqun.feng@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
mpe@ellerman.id.au
Subject: Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation
Date: Wed, 7 Oct 2015 16:53:44 +0200 [thread overview]
Message-ID: <20151007145344.GJ3816@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20151007132317.GK16065@arm.com>
On Wed, Oct 07, 2015 at 02:23:17PM +0100, Will Deacon wrote:
> Hi Peter,
>
> Thanks for the headache ;)
Most welcome :-)
> > Does we want to go revert 12d560f4ea87 ("rcu,locking: Privatize
> > smp_mb__after_unlock_lock()") for that same reason?
>
> I don't think we want a straight revert. smp_mb__after_unlock_lock could
> largely die if PPC strengthened its locks, whereas smp_mb__release_acquire
> is needed by quite a few architectures.
Fair enough, lets wait for the benchmark results from the PPC people
doing that.
> > > Documentation/memory-barriers.txt is updated to describe more clearly
> > > the ACQUIRE and RELEASE ordering in this area and to show an example of
> > > the new barrier in action.
> >
> > The only nit I have is that if we revert the above it might be make
> > sense to more clearly call out the distinction between the two.
>
> Right. Where I think we'd like to get to is:
>
> - RELEASE -> ACQUIRE acts as a full barrier if they operate on the same
> variable and the ACQUIRE reads from the RELEASE
>
> - RELEASE -> ACQUIRE acts as a full barrier if they execute on the same
> CPU and are interleaved with an smp_mb__release_acquire barrier.
>
> - RELEASE -> ACQUIRE ordering is transitive
>
> [only the transitivity part is missing in this patch, because I lost
> track of that discussion]
>
> We could then use these same guarantees for UNLOCK -> LOCK in RCU,
> defining smp_mb__after_unlock_lock to be the same as
> smp_mb__release_acquire, but only applying to UNLOCK -> LOCK. That's a
> slight relaxation of how it's defined at the moment (and I guess would
> need some work on PPC?), but it keeps things consistent which is
> especially important as core locking primitives are ported over to the
> ACQUIRE/RELEASE primitives.
>
> Thoughts?
/me like, although I'm too tired to see how those 3 rules combine to
something weaker than the current after_unlock_lock thing for PPC.
next prev parent reply other threads:[~2015-10-07 14:53 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-07 10:59 [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon
2015-10-07 11:19 ` Peter Zijlstra
2015-10-07 13:23 ` Will Deacon
2015-10-07 14:53 ` Peter Zijlstra [this message]
2015-10-07 15:25 ` Paul E. McKenney
2015-10-08 3:50 ` Michael Ellerman
2015-10-08 11:16 ` Peter Zijlstra
2015-10-08 12:59 ` Will Deacon
2015-10-08 22:17 ` Paul E. McKenney
2015-10-09 9:51 ` Will Deacon
2015-10-09 11:25 ` Peter Zijlstra
2015-10-09 17:44 ` Paul E. McKenney
2015-10-09 17:44 ` Paul E. McKenney
2015-10-09 17:43 ` Paul E. McKenney
2015-10-09 18:33 ` Will Deacon
2015-10-12 23:30 ` Paul E. McKenney
2015-10-20 14:20 ` Boqun Feng
2015-10-08 21:44 ` Paul E. McKenney
2015-10-09 7:29 ` Peter Zijlstra
2015-10-09 8:31 ` Peter Zijlstra
2015-10-09 9:40 ` Will Deacon
2015-10-09 11:02 ` Peter Zijlstra
2015-10-09 12:41 ` Will Deacon
2015-10-09 11:12 ` Peter Zijlstra
2015-10-09 12:51 ` Will Deacon
2015-10-09 13:06 ` Peter Zijlstra
2015-10-09 11:13 ` Peter Zijlstra
2015-10-09 17:21 ` Paul E. McKenney
2015-10-19 1:17 ` Boqun Feng
2015-10-19 10:23 ` Peter Zijlstra
2015-10-20 7:35 ` Boqun Feng
2015-10-20 23:34 ` Paul E. McKenney
2015-10-21 8:24 ` Peter Zijlstra
2015-10-21 19:29 ` Paul E. McKenney
2015-10-21 19:36 ` Peter Zijlstra
2015-10-21 19:56 ` Paul E. McKenney
2015-10-21 16:04 ` David Laight
2015-10-21 16:04 ` David Laight
2015-10-21 16:04 ` David Laight
2015-10-21 19:34 ` Paul E. McKenney
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=20151007145344.GJ3816@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=boqun.feng@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulmck@linux.vnet.ibm.com \
--cc=will.deacon@arm.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.