From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752244AbcDWCho (ORCPT ); Fri, 22 Apr 2016 22:37:44 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:48323 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbcDWChm (ORCPT ); Fri, 22 Apr 2016 22:37:42 -0400 Date: Sat, 23 Apr 2016 04:37:36 +0200 From: Peter Zijlstra To: Boqun Feng Cc: Will Deacon , linux-kernel@vger.kernel.org, waiman.long@hpe.com, mingo@redhat.com, paulmck@linux.vnet.ibm.com, torvalds@linux-foundation.org, dave@stgolabs.net Subject: Re: [RFC][PATCH 3/3] locking,arm64: Introduce cmpwait() Message-ID: <20160423023736.GZ3430@twins.programming.kicks-ass.net> References: <20160404122250.340636238@infradead.org> <20160404123633.484451002@infradead.org> <20160412165941.GG26124@arm.com> <20160422160857.GA3369@insomnia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160422160857.GA3369@insomnia> 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 Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > How about replace smp_rmb() with a smp_acquire_barrier__after_cmpwait()? > This barrier is designed to provide an ACQUIRE ordering when combining a > cmpwait() . That's a horrible name for a barrier :-) > And cmpwait() only has minimal ordering guarantee, but if it is actually > an ACQUIRE, then the corresponding smp_acquire_barrier__after_cmpwait() > is just empty. > > We might need this special barrier on ppc, because we can implement it > with "isync" given that cmpwait() has control dependency and ctrl+isync > is ACQUIRE on ppc. > > Thoughts? Provide a PPC specific smp_cond_load_acquire() using ISYNC ?