From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756203AbbBQMpa (ORCPT ); Tue, 17 Feb 2015 07:45:30 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:54548 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752039AbbBQMp3 (ORCPT ); Tue, 17 Feb 2015 07:45:29 -0500 Date: Tue, 17 Feb 2015 13:45:21 +0100 From: Peter Zijlstra To: Kirill Tkhai Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Josh Poimboeuf , oleg@redhat.com, paulmck@linux.vnet.ibm.com Subject: Re: [PATCH 2/2] [PATCH] sched: Add smp_rmb() in task rq locking cycles Message-ID: <20150217124521.GO5029@twins.programming.kicks-ass.net> References: <20150217104516.12144.85911.stgit@tkhai> <1424170021.5749.22.camel@tkhai> <20150217121258.GM5029@twins.programming.kicks-ass.net> <1424176610.5749.34.camel@tkhai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424176610.5749.34.camel@tkhai> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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).