lkml.org 
[lkml]   [2015]   [Oct]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2015-10-09 13:21    [W:0.211 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site