public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead•org>
To: Will Deacon <will.deacon@arm•com>
Cc: "Paul E. McKenney" <paulmck@linux•vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail•com>,
	"linux-kernel@vger•kernel.org" <linux-kernel@vger•kernel.org>,
	"linuxppc-dev@lists•ozlabs.org" <linuxppc-dev@lists•ozlabs.org>,
	Ingo Molnar <mingo@kernel•org>,
	Benjamin Herrenschmidt <benh@kernel•crashing.org>,
	Paul Mackerras <paulus@samba•org>,
	Michael Ellerman <mpe@ellerman•id.au>,
	Thomas Gleixner <tglx@linutronix•de>,
	Waiman Long <waiman.long@hp•com>
Subject: Re: [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants
Date: Mon, 14 Sep 2015 13:35:20 +0200	[thread overview]
Message-ID: <20150914113520.GP18489@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20150911124507.GB16833@arm.com>


Sorry for being tardy, I had a wee spell of feeling horrible and then I
procrastinated longer than I should have.

On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:

> Peter, any thoughts? I'm not au fait with the x86 memory model, but what
> Paul's saying is worrying.

Right, so Paul is right -- and I completely forgot (I used to know about
that).

So all the TSO archs (SPARC-TSO, x86 (!OOSTORE) and s390) can do
smp_load_acquire()/smp_store_release() with just barrier(), and while:

	smp_store_release(&x);
	smp_load_acquire(&x);

will provide full order by means of the address dependency,

	smp_store_release(&x);
	smp_load_acquire(&y);

will not. Because the one reorder TSO allows is exactly that one.

> Peter -- if the above reordering can happen on x86, then moving away
> from RCpc is going to be less popular than I hoped...

Sadly yes.. We could of course try and split LOCK from ACQUIRE again,
but I'm not sure that's going to help anything except confusion.

  parent reply	other threads:[~2015-09-14 11:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-28  2:48 [RFC 0/5] atomics: powerpc: implement relaxed/acquire/release variants of some atomics Boqun Feng
2015-08-28  2:48 ` [RFC 1/5] atomics: add test for atomic operations with _relaxed variants Boqun Feng
2015-08-28  2:48 ` [RFC 2/5] atomics: introduce arch_atomic_op_{acquire, release, fence} helpers Boqun Feng
2015-08-28 11:36   ` [RFC 2/5] atomics: introduce arch_atomic_op_{acquire,release,fence} helpers Peter Zijlstra
2015-08-28 11:50     ` Boqun Feng
2015-08-28  2:48 ` [RFC 3/5] powerpc: atomic: implement atomic{, 64}_{add, sub}_return_* variants Boqun Feng
2015-08-28 10:48   ` [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants Peter Zijlstra
2015-08-28 12:06     ` Boqun Feng
2015-08-28 14:16       ` Boqun Feng
2015-08-28 15:39         ` Peter Zijlstra
2015-08-28 16:59           ` Boqun Feng
2015-09-01 19:00           ` Will Deacon
2015-09-01 21:45             ` Paul E. McKenney
2015-09-02  9:59               ` Will Deacon
2015-09-02 10:49                 ` Paul E. McKenney
2015-09-02 15:23                 ` Pranith Kumar
2015-09-02 15:36                   ` [RFC 3/5] powerpc: atomic: implement atomic{, 64}_{add, sub}_return_* variants Pranith Kumar
2015-09-03 10:31                     ` [RFC 3/5] powerpc: atomic: implement atomic{,64}_{add,sub}_return_* variants Will Deacon
2015-09-11 12:45                 ` Will Deacon
2015-09-11 17:09                   ` Paul E. McKenney
2015-09-14 11:35                   ` Peter Zijlstra [this message]
2015-09-14 12:01                     ` Peter Zijlstra
2015-09-14 12:11                       ` Peter Zijlstra
2015-09-14 15:38                         ` Will Deacon
2015-09-14 16:26                           ` Paul E. McKenney
2015-08-28  2:48 ` [RFC 4/5] powerpc: atomic: implement xchg_* and atomic{, 64}_xchg_* variants Boqun Feng
2015-08-28  2:48 ` [RFC 5/5] powerpc: atomic: implement cmpxchg{, 64}_* and atomic{, 64}_cmpxchg_* variants Boqun Feng

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=20150914113520.GP18489@twins.programming.kicks-ass.net \
    --to=peterz@infradead$(echo .)org \
    --cc=benh@kernel$(echo .)crashing.org \
    --cc=boqun.feng@gmail$(echo .)com \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linuxppc-dev@lists$(echo .)ozlabs.org \
    --cc=mingo@kernel$(echo .)org \
    --cc=mpe@ellerman$(echo .)id.au \
    --cc=paulmck@linux$(echo .)vnet.ibm.com \
    --cc=paulus@samba$(echo .)org \
    --cc=tglx@linutronix$(echo .)de \
    --cc=waiman.long@hp$(echo .)com \
    --cc=will.deacon@arm$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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