All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation
Date: Wed, 27 Jan 2016 15:00:11 -0800	[thread overview]
Message-ID: <20160127230011.GK4503@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160127183923.GD25545@arm.com>

On Wed, Jan 27, 2016 at 06:39:23PM +0000, Will Deacon wrote:
> On Wed, Jan 27, 2016 at 07:25:51PM +0100, Peter Zijlstra wrote:
> > On Wed, Jan 27, 2016 at 06:22:04PM +0000, Will Deacon wrote:
> > > As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> > > always cheaply ordered and can be used to construct UNLOCK -> LOCK
> > > definitions with similar guarantees, the grim reality is that this isn't
> > > even possible on x86 (thanks to Paul for bringing us crashing down to
> > > Earth).
> > > 
> > > This patch handles the issue by introducing a new barrier macro,
> > > smp_mb__after_release_acquire, that can be placed after an ACQUIRE that
> > > either reads from a RELEASE or is in program-order after a RELEASE. The
> > > barrier upgrades the RELEASE-ACQUIRE pair to a full memory barrier,
> > > implying global transitivity. At the moment, it doesn't have any users,
> > > so its existence serves mainly as a documentation aid and a potential
> > > stepping stone to the reintroduction of smp_mb__after_unlock_lock() used
> > > by RCU.
> > > 
> > > Documentation/memory-barriers.txt is updated to describe more clearly
> > > the ACQUIRE and RELEASE ordering in this area and to show some examples
> > > of the new barrier in action.
> > 
> > So the obvious question is: do we have a use-case?
> 
> We have a use-case for smp_mb__after_unlock_lock, so I think we should
> either strengthen our locking guarantees so that smp_mb__after_unlock_lock
> isn't needed or introduce smp_mb__after_release_acquire to close the gap.
> As it stands, we've got an inconsistency (despite it being hidden inside
> RCU).
> 
> The main advantage of this patch is a documentation aid, in my opinion
> (hell, we talk about smp_mb__after_unlock_lock already when reasoning
> about this stuff).

But wasn't there an x86 potential use case that required placing the
strengthening macro after the release and before the acquire?  Or is
this a case of old age striking again?

							Thanx, Paul

  reply	other threads:[~2016-01-27 23:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 18:22 [PATCH v3] barriers: introduce smp_mb__release_acquire and update documentation Will Deacon
2016-01-27 18:25 ` Peter Zijlstra
2016-01-27 18:39   ` Will Deacon
2016-01-27 23:00     ` Paul E. McKenney [this message]
2016-01-28 15:35       ` Will Deacon
2016-01-28  2:46 ` Boqun Feng
2016-01-28 10:01   ` Will Deacon

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=20160127230011.GK4503@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --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.