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

Groups > linux.kernel > #1217862

Re: futex atomic vs ordering constraints

Show all headers | View raw

On Wed, Sep 2, 2015 at 10:00 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> So I'm reading that code like:
>
>         MB
>  [RmW]  ret = *val += i
>
>
> So what is stopping later memory ops like:
>
>    [R]  a = *foo
>    [S]  *bar = b
>
> From getting reordered with the RmW, like:
>
>         MB
>
>    [R]  a = *foo
>    [S]  *bar = b
>
>  [RmW]  ret = *val += i

So I do agree that for the atomic futex operation to be usable for
locking (which I think we all agree is a primary objective), the futex
write operations have to work both as acquire and release operations,
which basically means that it has to be both an acquire _and_ release
op.

That said, I'm not sure it really needs to be a full memory barrier on
both sides, and in particular, I'm not sure it needs to be a memory
barroer for the surrounding *kernel* operations.

So I do suspect that adding full smp_mb()'s on both sides is not
necessarily required for architectures, because there are often
serialization guarantees at kernel entry/exit.

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".

For example, on x86, the locked instructions are obviously already
sufficiently strong, but even if they weren't, kernel entry/exit is
documented to be a serializing instruction (which is something
insanely much stronger than just memory ordering). And I suspect there
are similar issues on a lot of architectures where the memory ordering
is done by the core, but the cache subsystem is strongly ordered (ie
saen good SMP systems - so it sounds like tile needs the smp_mb()'s,
but I would almost suspect that POWER and ARM might *not* need them).

           Linus
--
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 | Next — Previous in thread | Next 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

csiph-web