From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932692AbbJPTHq (ORCPT ); Fri, 16 Oct 2015 15:07:46 -0400 Received: from casper.infradead.org ([85.118.1.10]:40571 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932103AbbJPTHo (ORCPT ); Fri, 16 Oct 2015 15:07:44 -0400 Date: Fri, 16 Oct 2015 21:07:41 +0200 From: Peter Zijlstra To: "Paul E. McKenney" Cc: Catalin Marinas , Will Deacon , Linux Kernel Mailing List , Oleg Nesterov , Ingo Molnar Subject: Re: Q: schedule() and implied barriers on arm64 Message-ID: <20151016190741.GD3816@twins.programming.kicks-ass.net> References: <20151016151830.GZ3816@twins.programming.kicks-ass.net> <20151016160422.GQ3910@linux.vnet.ibm.com> <20151016161608.GA3816@twins.programming.kicks-ass.net> <20151016172811.GT3910@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151016172811.GT3910@linux.vnet.ibm.com> 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 Fri, Oct 16, 2015 at 10:28:11AM -0700, Paul E. McKenney wrote: > In other words, if task2() acquires the lock after task1() releases it, > all CPUs must agree on the order of the operations in the two critical > sections, even if these other CPUs don't acquire the lock. > > This same guarantee is needed if task1() and then task2() run in > succession on the same CPU with no additional synchronization of any sort. > > Does this work on arm64? Yes, their load-acquire and store-release are RCsc.