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


Groups > linux.kernel > #1408937

Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait()
Date 2016-05-30 11:30 +0200
Message-ID <rErGh-2in-11@gated-at.bofh.it> (permalink)
References <rD4sq-7xk-5@gated-at.bofh.it> <rD4sq-7xk-21@gated-at.bofh.it> <rDlWi-1vV-15@gated-at.bofh.it> <rDlWi-1vV-13@gated-at.bofh.it> <rErGh-2in-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, May 27, 2016 at 03:34:13PM -0400, Chris Metcalf wrote:

> >Does TILE never speculate reads? Because in that case the control
> >dependency already provides a full load->load,store barrier and you'd
> >want smp_acquire__after_ctrl_dep() to be a barrier() instead of
> >smp_rmb().
> 
> Yes, that's a good point.  I didn't look at the definition of smp_acquire__after_ctrl_dep(),
> but it certainly sounds like that's exactly a compiler barrier for tile.  There is no load
> speculation performed.  The only out-of-order stuff that happens is in the memory
> subsystem: stores will become visible in arbitrary order, and loads will arrive in
> arbitrary order, but as soon as the result of a load is used in any other kind of
> instruction, the instruction issue will halt until the pending load(s) for the instruction
> operands are available.

OK; for now I'll just put in barrier() and a big comment, I'll look at
making smp_acquire__after_ctrl_dep() a proper (per arch) barrier later.
There's a little header head-ache involved.

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


Thread

[PATCH -v2 4/6] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-05-26 16:30 +0200
  Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait() Martin Schwidefsky <schwidefsky@de.ibm.com> - 2016-05-27 10:40 +0200
    Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-05-27 11:10 +0200
  Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-05-27 11:10 +0200
    Re: [PATCH -v2 4/6] locking, arch: Update spin_unlock_wait() Peter Zijlstra <peterz@infradead.org> - 2016-05-30 11:30 +0200

csiph-web