From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752017AbcDWD67 (ORCPT ); Fri, 22 Apr 2016 23:58:59 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:35410 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751219AbcDWD66 (ORCPT ); Fri, 22 Apr 2016 23:58:58 -0400 Date: Sat, 23 Apr 2016 12:02:00 +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: <20160423040200.GE3369@insomnia> References: <20160404122250.340636238@infradead.org> <20160404123633.484451002@infradead.org> <20160412165941.GG26124@arm.com> <20160422160857.GA3369@insomnia> <20160422165310.GN10289@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SNIs70sCzqvszXB4" Content-Disposition: inline In-Reply-To: <20160422165310.GN10289@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 --SNIs70sCzqvszXB4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 22, 2016 at 05:53:11PM +0100, Will Deacon wrote: > On Sat, Apr 23, 2016 at 12:08:57AM +0800, Boqun Feng wrote: > > On Tue, Apr 12, 2016 at 05:59:41PM +0100, Will Deacon wrote: > > [...] > > > > +static inline void __cmpwait(volatile void *ptr, unsigned long val= , int 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 > >=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() . > >=20 > > 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 > Maybe, but that makes it difficult for me to use a load-acquire instructi= on > for the ACQUIRE case. >=20 You're right. I was missting that point. Please ignore this proposal. So I think having a cmpwait_relaxed makes more sense for the people knowing they could only rely on the control dependency? Or we actually don't want to encourage this kind of people ;-) Regards, Boqun > Will --SNIs70sCzqvszXB4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXGvOxAAoJEEl56MO1B/q4U5MIAIh8ndEb7N24MC2n5C5puFx2 gudLmrLSV89IEMZKDLDHmHhbyQjbFJpwB3AzkwxW9iRYNBkSE+zoNpNM2uaJPw0Q WQ7SI8Qvy6eI2lSH0C/b7OWISUDMc1pnW5K0DQytSeu4T61MJMf+4UvKZUrbji2g A/s+xvLI6W+0zFWQxAstwwZzP4J48WRkxRrRbPor0LvRqUa2HulDby+Jx5b2QNVq ejaEj1LvEYwg5W4XjOQ8uCbohZPWXQPcEsMAwiivxdctL4SP3i7Nq1HMyLVIZhXB 2CqvolJ7sZqNchqh7havirez3HdPPsCyw/cVFVQ2jY+CIZecWyYTZbz7MYeTGpg= =h6pQ -----END PGP SIGNATURE----- --SNIs70sCzqvszXB4--