From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754493AbbJPQEs (ORCPT ); Fri, 16 Oct 2015 12:04:48 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:37820 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751968AbbJPQEY (ORCPT ); Fri, 16 Oct 2015 12:04:24 -0400 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Fri, 16 Oct 2015 09:04:22 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Will Deacon , linux-kernel@vger.kernel.org, Oleg Nesterov , Ingo Molnar Subject: Re: Q: schedule() and implied barriers on arm64 Message-ID: <20151016160422.GQ3910@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151016151830.GZ3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151016151830.GZ3816@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15101616-0025-0000-0000-00001DFD8B6D Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 16, 2015 at 05:18:30PM +0200, Peter Zijlstra wrote: > Hi, > > IIRC Paul relies on schedule() implying a full memory barrier with > strong transitivity for RCU. > > If not, ignore this email. Not so sure about schedule(), but definitely need strong transitivity for the rcu_node structure's ->lock field. And the atomic operations on the rcu_dyntick structure's fields when entering or leaving the idle loop. With schedule, the thread later reports the quiescent state, which involves acquiring the rcu_node structure's ->lock field. So I -think- that the locks in the scheduler can be weakly transitive. > If so, however, I suspect AARGH64 is borken and would need (just like > PPC): > > #define smp_mb__before_spinlock() smp_mb() > > The problem is that schedule() (when a NO-OP) does: > > smp_mb__before_spinlock(); > LOCK rq->lock > > clear_bit() > > UNLOCK rq->lock > > And nothing there implies a full barrier on AARGH64, since > smp_mb__before_spinlock() defaults to WMB, LOCK is an "ldaxr" or > load-acquire, UNLOCK is "stlrh" or store-release and clear_bit() isn't > anything. > > Pretty much every other arch has LOCK implying a full barrier, either > because its strongly ordered or because it needs one for the ACQUIRE > semantics. Well, arm64 might well need smp_mb__after_unlock_lock() to be non-empty. But I thought that it used a dmb in the spinlock code somewhere or another... Thanx, Paul