From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754333AbbKCBOe (ORCPT ); Mon, 2 Nov 2015 20:14:34 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]:54859 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752229AbbKCBOd (ORCPT ); Mon, 2 Nov 2015 20:14:33 -0500 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Mon, 2 Nov 2015 17:14:06 -0800 From: "Paul E. McKenney" To: Will Deacon Cc: Peter Zijlstra , mingo@kernel.org, oleg@redhat.com, linux-kernel@vger.kernel.org, boqun.feng@gmail.com, corbet@lwn.net, mhocko@kernel.org, dhowells@redhat.com, torvalds@linux-foundation.org Subject: Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() Message-ID: <20151103011406.GB29027@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20151102132901.157178466@infradead.org> <20151102134941.005198372@infradead.org> <20151102135726.GR17308@twins.programming.kicks-ass.net> <20151102174347.GK29657@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151102174347.GK29657@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15110301-0013-0000-0000-000019E78350 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 02, 2015 at 05:43:48PM +0000, Will Deacon wrote: > On Mon, Nov 02, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 02, 2015 at 02:29:05PM +0100, Peter Zijlstra wrote: > > > > > Note that while smp_cond_acquire() has an explicit > > > smp_read_barrier_depends() for Alpha, neither sites it gets used in > > > were actually buggy on Alpha for their lack of it. The first uses > > > smp_rmb(), which on Alpha is a full barrier too and therefore serves > > > its purpose. The second had an explicit full barrier. > > > > > +/** > > > + * smp_cond_acquire() - Spin wait for cond with ACQUIRE ordering > > > + * @cond: boolean expression to wait for > > > + * > > > + * Equivalent to using smp_load_acquire() on the condition variable but employs > > > + * the control dependency of the wait to reduce the barrier on many platforms. > > > + * > > > + * The control dependency provides a LOAD->STORE order, the additional RMB > > > + * provides LOAD->LOAD order, together they provide LOAD->{LOAD,STORE} order, > > > + * aka. ACQUIRE. > > > + */ > > > +#define smp_cond_acquire(cond) do { \ > > > + while (!(cond)) \ > > > + cpu_relax(); \ > > > + smp_read_barrier_depends(); /* ctrl */ \ > > > + smp_rmb(); /* ctrl + rmb := acquire */ \ > > > +} while (0) > > > > So per the above argument we could leave out the > > smp_read_barrier_depends() for Alpha, although that would break > > consistency with all the other control dependency primitives we have. It > > would avoid issuing a double barrier. > > > > Thoughts? > > Do we even know that Alpha needs a barrier for control-dependencies in > the first place? You would ask that question when I am many thousands of miles from my copy of the Alpha reference manual! ;-) There is explicit wording in that manual that says that no multi-variable ordering is implied without explicit memory-barrier instructions. Thanx, Paul