lkml.org 
[lkml]   [2017]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures
From
Date
On 06/09/2017 04:13 AM, Peter Zijlstra wrote:
> On Fri, Jun 09, 2017 at 01:05:06PM +0200, Peter Zijlstra wrote:
>
>> The spinlock based atomics should be SC, that is, none of them appear to
>> place extra barriers in atomic_cmpxchg() or any of the other SC atomic
>> primitives and therefore seem to rely on their spinlock implementation
>> being SC (I did not fully validate all that).
>
> So I did see that ARC and PARISC have 'superfluous' smp_mb() calls
> around their spinlock implementation.
>
> That is, for spinlock semantics you only need one _after_ lock and one
> _before_ unlock. But the atomic stuff relies on being SC and thus would
> need one before and after both lock and unlock.

Right we discussed this a while back: https://lkml.org/lkml/2015/6/11/276

At the time when I tried removing these extra barriers, hackbench regressed. I'm
about to get a new quad core 1GHz chip (vs. the FPGA before) and will
re-experiment. Likely we don't need it otherwise I will add a comment of this
"feature"

> But ARC could probably optimize (if they still care about that hardware)
> by pulling out those barriers and putting it in the atomic
> implementation.

A bit confused here. Reading the lkml posting for this thread, you posted 2
patches, and they had to do with atomic_set() for EZChip platform which is really
special (no ll/sc). The extra smp_mb() is related to ll/sc variants. Just tryign
to make sure that we are talking 2 different things here :-)

-Vineet

\
 
 \ /
  Last update: 2017-06-12 01:51    [W:0.051 / U:13.584 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site