[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151009110246.GY3816@twins.programming.kicks-ass.net>
Date: Fri, 9 Oct 2015 13:02:46 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Will Deacon <will.deacon@....com>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Michael Ellerman <mpe@...erman.id.au>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Boqun Feng <boqun.feng@...il.com>,
Anton Blanchard <anton@...ba.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and
update documentation
On Fri, Oct 09, 2015 at 10:40:39AM +0100, Will Deacon wrote:
> Stepping back a second, I believe that there are three cases:
>
>
> RELEASE X -> ACQUIRE Y (same CPU)
> * Needs a barrier on TSO architectures for full ordering
+PPC
> UNLOCK X -> LOCK Y (same CPU)
> * Needs a barrier on PPC for full ordering
> RELEASE X -> ACQUIRE X (different CPUs)
* Fully ordered everywhere...
* ... but needs a barrier on TSO + PPC to become a full barrier
> UNLOCK X -> ACQUIRE X (different CPUs)
s/ACQUIRE/LOCK/ ?
> * Fully ordered everywhere...
> * ... but needs a barrier on PPC to become a full barrier
If you really meant ACQUIRE, then x86 also needs a barrier in order to
upgrade, seeing how our unlock is equivalent to smp_store_release(). Our
LOCK otoh is far heavier than smp_load_acquire() and would result in
different rules.
And I'm not sure the "(different CPUs)" bit makes sense, as the same is
true if they're on the same CPU.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists