Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Feb 17, 2015 at 03:36:50PM +0300, Kirill Tkhai wrote:

> > If we observe the new cpu value, we've acquired the new rq->lock and its
> > ACQUIRE will pair with the WMB to ensure we see the migrate value.
> 
> Yes, I warried about new_cpu case.
> 
> So, spin_lock() implies smp_rmb(). I used to think it does not do
> (I was confused by smp_mb__before_spin_lock(), but it's for STORE).
> 
> Thanks for the explanation :)

No, it does not imply RMB, its an ACQUIRE barrier.

>From Documentation/memory-barriers.txt:

 (5) ACQUIRE operations.

     This acts as a one-way permeable barrier.  It guarantees that all memory
     operations after the ACQUIRE operation will appear to happen after the
     ACQUIRE operation with respect to the other components of the system.
     ACQUIRE operations include LOCK operations and smp_load_acquire()
     operations.

     Memory operations that occur before an ACQUIRE operation may appear to
     happen after it completes.

     An ACQUIRE operation should almost always be paired with a RELEASE
     operation.

And note that the [L] rq = task_rq() cannot happen _after_ the acquire
because the acquire has an address dependency on it, we must complete
the load in order to actually take the lock.

(of course, taking the lock implies further stores and atomic ops, but
those need not actually imply more than the ACQUIRE barrier -- even
though they will on x86).