Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1662689

Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny' architectures

Show all headers | View raw

On Fri, Jun 09, 2017 at 10:28:50AM -0700, Vineet Gupta wrote:
> 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 :-)

Could be I just got all my variants in a twist... wouldn't be the first
time ;-)

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC][PATCH]: documentation,atomic: Add a new atomic_t document Peter Zijlstra <peterz@infradead.org> - 2017-06-09 11:30 +0200
  [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'  architectures Peter Zijlstra <peterz@infradead.org> - 2017-06-09 13:10 +0200
    Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'  architectures Peter Zijlstra <peterz@infradead.org> - 2017-06-09 13:20 +0200
      Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'  architectures Vineet Gupta <Vineet.Gupta1@synopsys.com> - 2017-06-09 19:30 +0200
        Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'  architectures Peter Zijlstra <peterz@infradead.org> - 2017-06-09 21:00 +0200
      Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'  architectures James Bottomley <James.Bottomley@HansenPartnership.com> - 2017-06-09 21:00 +0200
  Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Will Deacon <will.deacon@arm.com> - 2017-06-09 17:50 +0200
    Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Peter Zijlstra <peterz@infradead.org> - 2017-06-09 21:40 +0200
      Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Boqun Feng <boqun.feng@gmail.com> - 2017-06-11 16:00 +0200
        Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Peter Zijlstra <peterz@infradead.org> - 2017-06-12 17:00 +0200
          Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Boqun Feng <boqun.feng@gmail.com> - 2017-06-13 08:40 +0200
          Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Will Deacon <will.deacon@arm.com> - 2017-06-14 14:40 +0200
  Re: [RFC][PATCH]: documentation,atomic: Add a new atomic_t document Randy Dunlap <rdunlap@infradead.org> - 2017-06-09 20:20 +0200

csiph-web