From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752071AbcDWDhV (ORCPT ); Fri, 22 Apr 2016 23:37:21 -0400 Received: from mail-ig0-f178.google.com ([209.85.213.178]:37245 "EHLO mail-ig0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219AbcDWDhT (ORCPT ); Fri, 22 Apr 2016 23:37:19 -0400 Date: Sat, 23 Apr 2016 11:40:29 +0800 From: Boqun Feng To: Peter Zijlstra 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: <20160423034029.GD3369@insomnia> References: <20160404122250.340636238@infradead.org> <20160404123633.484451002@infradead.org> <20160412165941.GG26124@arm.com> <20160422160857.GA3369@insomnia> <20160423023736.GZ3430@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DiL7RhKs8rK9YGuF" Content-Disposition: inline In-Reply-To: <20160423023736.GZ3430@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --DiL7RhKs8rK9YGuF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 23, 2016 at 04:37:36AM +0200, Peter Zijlstra wrote: > 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() . >=20 > That's a horrible name for a barrier :-) >=20 Indeed, and having another special barrier is a pain. > > 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. > >=20 > > 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. > >=20 > > Thoughts? >=20 > Provide a PPC specific smp_cond_load_acquire() using ISYNC ? That works, but I should do more investigation on that, I brought this up because ISYNC may be better than smp_rmb() in two cases, IIUC: 1. for old systems without LWSYNC, smp_rmb() is actually SYNC, which is heavier than ISYNC. 2. for new systems, isync may be a little faster than lwsync, according to Michael Ellerman: http://lkml.kernel.org/g/1437012028.28475.2= =2Ecamel@ellerman.id.au but I doubt these two cases will have any observed performance impact, so the current version of smp_cond_load_acquire() in your patch is fine, and we can switch to a specific one in the future we want to ;-) Regards, Boqun --DiL7RhKs8rK9YGuF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXGu6oAAoJEEl56MO1B/q4YoAH/i/5ZeWARUZZvqF78Yl8z9U/ OByPDiPQFaA+G8elT9UFzXVsyGTNRjV0nAJX7TsOI25yWetwPk686jRCZqbYbPrU Ca2IbePhLMTlihsPPk85sQFQS1rAup6gTM1BA22HYFXITd9he/dqz1Q9yRcqj/xz zi2g6JNOn+T8PjnezbP3/yXfbj02SXwLbdqestA5hHPLhQmnAGNHk75uTOWXo5P5 ZPOl29XxB7IusTMU7d3JFFooQ1HcNmDXIIOIyGZ+cfqN+7aYl6IdKavEWy3ZaflM x0MHjTcxsods3YaM1OHITxgzdan5UZXLNbilOgQFz5/8TV7ehh97LlvaAzSfoas= =c4Da -----END PGP SIGNATURE----- --DiL7RhKs8rK9YGuF--