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


Groups > linux.kernel > #1220025

Re: futex atomic vs ordering constraints

From Will Deacon <will.deacon@arm.com>
Newsgroups linux.kernel
Subject Re: futex atomic vs ordering constraints
Date 2015-09-07 11:40 +0200
Message-ID <q6146-1Dd-17@gated-at.bofh.it> (permalink)
References (4 earlier) <q4fNV-5vS-27@gated-at.bofh.it> <q4iVs-1Ic-3@gated-at.bofh.it> <q4jHP-2S4-13@gated-at.bofh.it> <q4nBL-8s3-13@gated-at.bofh.it> <q5pUS-7AS-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Sat, Sep 05, 2015 at 06:53:02PM +0100, Peter Zijlstra wrote:
> On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote:
> > So I think we could possibly relax the requirements (and document this
> > very clearly) to say that the futex operation must be totally ordered
> > wrt any other _user_space_ accesses by that thread. I suspect a lot of
> > architectures can then say "we may be very weakly ordered, but kernel
> > entry/exit implies enough synchronization that we do not need any
> > futher memory barriers".
> 
> Right, so before sending this email I actually spoke to Ralf about this
> option, and he said that this is not actually well defined for MIPS.
> 
> But we could certainly document it such and let archs for which this is
> well documented (I would expect this to be most) choose that
> implementation.

Whilst a control-dependency + exception return forms a barrier of sorts
on arm/arm64, it's not required to be transitive [1], so I wouldn't be
comfortable making that relaxation on the futex path.

Will

[1] See, for example, "ISA2+dmb+ctrlisb+dmb" at
    https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#ARM
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


Thread

futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-08-26 20:20 +0200
  Re: futex atomic vs ordering constraints Davidlohr Bueso <dave@stgolabs.net> - 2015-08-29 03:40 +0200
    Re: futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-09-01 18:40 +0200
  Re: futex atomic vs ordering constraints Will Deacon <will.deacon@arm.com> - 2015-09-01 18:40 +0200
    Re: futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-09-01 18:50 +0200
      Re: futex atomic vs ordering constraints Will Deacon <will.deacon@arm.com> - 2015-09-01 18:50 +0200
      Re: futex atomic vs ordering constraints Thomas Gleixner <tglx@linutronix.de> - 2015-09-01 21:10 +0200
        Re: futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-09-02 15:00 +0200
          Re: futex atomic vs ordering constraints Chris Metcalf <cmetcalf@ezchip.com> - 2015-09-02 18:20 +0200
            Re: futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-09-02 19:10 +0200
              Re: futex atomic vs ordering constraints Chris Metcalf <cmetcalf@ezchip.com> - 2015-09-02 19:30 +0200
              Re: futex atomic vs ordering constraints Linus Torvalds <torvalds@linux-foundation.org> - 2015-09-02 23:20 +0200
                Re: futex atomic vs ordering constraints Peter Zijlstra <peterz@infradead.org> - 2015-09-05 20:00 +0200
                Re: futex atomic vs ordering constraints Will Deacon <will.deacon@arm.com> - 2015-09-07 11:40 +0200

csiph-web