From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754221AbcDVQFv (ORCPT ); Fri, 22 Apr 2016 12:05:51 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:38280 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752369AbcDVQFt (ORCPT ); Fri, 22 Apr 2016 12:05:49 -0400 Date: Sat, 23 Apr 2016 00:08:57 +0800 From: Boqun Feng To: Will Deacon Cc: Peter Zijlstra , 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: <20160422160857.GA3369@insomnia> References: <20160404122250.340636238@infradead.org> <20160404123633.484451002@infradead.org> <20160412165941.GG26124@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <20160412165941.GG26124@arm.com> 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 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote: [...] > > +static inline void __cmpwait(volatile void *ptr, unsigned long val, in= t size) > > +{ > > + switch (size) { > > + case 1: return __cmpwait_case_1(ptr, val); > > + case 2: return __cmpwait_case_2(ptr, val); > > + case 4: return __cmpwait_case_4(ptr, val); > > + case 8: return __cmpwait_case_8(ptr, val); > > + default: BUILD_BUG(); > > + } > > + > > + unreachable(); > > +} > > + > > +#define cmpwait(ptr, val) \ > > + __cmpwait((ptr), (unsigned long)(val), sizeof(*(ptr))) >=20 > We might want to call this cmpwait_relaxed, in case we decide to add > fenced versions in the future. Or just make it cmpwait_acquire and > remove the smp_rmb() from smp_cond_load_acquire(). Dunno. >=20 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() . 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? Regards, Boqun > Will --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXGkyVAAoJEEl56MO1B/q4kHMH/3wCwTgZnxgLc47yY+Dm4u3+ 1oXyWmiSfW9gwhSd2SkKe+fjWGC4BVtOduUBgBNNId8S3AMgnDy1ZE3od9JTZ1cE yb6u2R9DoRkE6J1Emcuip6SWfLHKdX2uUGYfxWhi+bYnRq3Ek1HmhJie8lbyHZS9 PIsZ+wKimRsnk+7kwoXU75EkRMlMHA5ld687ui/vt4O+mRvBzjSjyyAyyx7lRsrq zen2Gw7TjmUHTiX2gGiYSbHE6eOqe9YTpLTjIQhvQnSrZ6+CFMbV5nn2WoDhyDT8 LVtIX4ZX/DFLIexRJsDZT9vy7K1NXklcqULmihLUlnf6TlHFmwe1qRO3CRINV/o= =7ICM -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g--