LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will.deacon@arm.com>,
	torvalds@linux-foundation.org, oleg@redhat.com,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Re: Behaviour of smp_mb__{before,after}_spin* and acquire/release
Date: Tue, 20 Jan 2015 13:35:45 -0800	[thread overview]
Message-ID: <20150120213545.GT9719@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150120093443.GA11596@twins.programming.kicks-ass.net>

On Tue, Jan 20, 2015 at 10:34:43AM +0100, Peter Zijlstra wrote:
> On Tue, Jan 13, 2015 at 04:33:54PM +0000, Will Deacon wrote:
> > Hi Paul,
> > 
> > I started dusting off a series I've been working to implement a relaxed
> > atomic API in Linux (i.e. things like atomic_read(v, ACQUIRE)) but I'm
> > having trouble making sense of the ordering semantics we have in mainline
> > today:
> 
> >   2. Does smp_mb__after_unlock_lock order smp_store_release against
> >      smp_load_acquire? Again, Documentation/memory-barriers.txt puts
> >      these operations into the RELEASE and ACQUIRE classes respectively,
> >      but since smp_mb__after_unlock_lock is a NOP everywhere other than
> >      PowerPC, I don't think this is enforced by the current code. 
> 
> Yeah, wasn't Paul going to talk to Ben about that? PPC is the only arch
> that has the weak ACQUIRE/RELEASE for its spinlocks.

I thought that you guys were going to propose something and we would see
what the reaction was.  ;-)

> >      Most
> >      architectures follow the pattern used by asm-generic/barrier.h:
> > 
> >        release: smp_mb(); STORE
> >        acquire: LOAD; smp_mb();
> > 
> >      which doesn't provide any release -> acquire ordering afaict.
> 
> Only when combined on the same address, if the LOAD observes the result
> of the STORE we can guarantee the rest of the ordering. And if you
> build a locking primitive with them (or circular lists or whatnot) you
> have that extra condition.
> 
> But yes, I see your argument that this implementation is weak like the
> PPC.

A more complete example would be as follows:

       STOREs followed by release: smp_mb(); STORE A
       acquire: LOAD A; smp_mb(); preceding LOADs

If the LOAD A gets the value from the STORE A, then the LOADs following
the acquire are guaranteed to see the STOREs preceding the release.

And yes, this really truly does work fine with weaker ordering.

							Thanx, Paul


  parent reply	other threads:[~2015-01-20 21:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 16:33 Will Deacon
2015-01-13 18:45 ` Oleg Nesterov
2015-01-14 11:31   ` Will Deacon
2015-01-20  3:40     ` Paul E. McKenney
2015-01-20 10:43       ` Will Deacon
2015-01-20  9:34 ` Peter Zijlstra
2015-01-20 10:38   ` Will Deacon
2015-01-20 21:35   ` Paul E. McKenney [this message]
2015-01-21 13:56     ` Will Deacon
2015-01-23 14:08     ` Will Deacon
2015-01-23 21:21       ` 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=20150120213545.GT9719@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    --subject='Re: Behaviour of smp_mb__{before,after}_spin* and acquire/release' \
    /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

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).