From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933710AbcIAOFX (ORCPT ); Thu, 1 Sep 2016 10:05:23 -0400 Received: from mail-it0-f42.google.com ([209.85.214.42]:36046 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755401AbcIAOFW (ORCPT ); Thu, 1 Sep 2016 10:05:22 -0400 Date: Thu, 1 Sep 2016 22:05:37 +0800 From: Boqun Feng To: Peter Zijlstra Cc: Manfred Spraul , Will Deacon , benh@kernel.crashing.org, paulmck@linux.vnet.ibm.com, Ingo Molnar , Andrew Morton , LKML , 1vier1@web.de, Davidlohr Bueso Subject: Re: [PATCH 1/4] spinlock: Document memory barrier rules Message-ID: <20160901140537.GD28226@tardis.cn.ibm.com> References: <20160829104815.GI10153@twins.programming.kicks-ass.net> <968e4c62-4486-a6aa-8fdf-67ff9b05a330@colorfullife.com> <20160829134424.GS10153@twins.programming.kicks-ass.net> <4859166f-ff39-e998-638b-6bf6912422a3@colorfullife.com> <20160831154049.GY10121@twins.programming.kicks-ass.net> <20160831164020.GG29505@arm.com> <80de24e3-fa01-a6d6-99e9-afd1e831e07b@colorfullife.com> <20160901084435.GN10153@twins.programming.kicks-ass.net> <3f7c39e5-4c46-0641-d29e-36c9439ad6dc@colorfullife.com> <20160901115134.GS10153@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zS7rBR6csb6tI2e1" Content-Disposition: inline In-Reply-To: <20160901115134.GS10153@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --zS7rBR6csb6tI2e1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2016 at 01:51:34PM +0200, Peter Zijlstra wrote: > On Thu, Sep 01, 2016 at 01:04:26PM +0200, Manfred Spraul wrote: >=20 > > >So for both power and arm64, you can in fact model spin_unlock_wait() > > >as LOCK+UNLOCK. >=20 > > Is this consensus? >=20 > Dunno, but it was done to fix your earlier locking scheme and both > architectures where it matters have done so. >=20 > So I suppose that could be taken as consensus ;-) >=20 > > If I understand it right, the rules are: > > 1. spin_unlock_wait() must behave like spin_lock();spin_unlock(); >=20 > From a barrier perspective, yes I think so. Ideally the implementation > would avoid stores (which was the entire point of introducing that > primitive IIRC) if at all possible (not possible on ARM64/Power). >=20 > > 2. spin_is_locked() must behave like spin_trylock() ? spin_unlock(),TRU= E : > > FALSE >=20 > Not sure on this one, That might be consistent, but I don't see the > ll/sc-nop in there. Will? >=20 My understanding is as Will stated, we don't provide this strong gaurantee for spin_is_locked(). The reason is mostly because all(?) uses of spin_is_locked() are not for correctness but for other purposes like debug output. > > 3. the ACQUIRE during spin_lock applies to the lock load, not to the st= ore. >=20 > I think we can state that ACQUIRE on _any_ atomic only applies to the > LOAD not the STORE. >=20 > And we're waiting for that to bite us again before trying to deal with ;-) > it in a more generic manner; for now only the spinlock implementations > (specifically spin_unlock_wait) deal with it. >=20 I think the hope is that, with herd or other tools, and a formal order model, we can make more people understand this "counter-intuitive" behavior and help them write correct and efficient code ;-) >=20 > Will, Boqun, did I get that right? >=20 Yep ;-) Regards, Boqun --zS7rBR6csb6tI2e1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXyDWqAAoJEEl56MO1B/q4yWcH/1xScaSmCk1HaCpeJYfTpWhh IKhwgBFGG4y5CAS4tHrl1rcFgWTq6uhUYES81djV57q3Qhi1oPtgQ9tg3f2HVGGw AgL808SM7jEDUDKRNAPK5GVJKVUDWYyAXKaFVUticDFCQfc9TRr3SQsyBxlsUccC uWMekf9RED8iHJTXYTub+LwlYZR5PHncn166llUCPOvzUMU7i76f4vefAfI46APS 0SU2vlQ+EdF017WV+7quTH01/K2lbO2R5ewmeWYvAhgXsND9aSpOKqeZiDnguSyu 8u2ElKLip2LS1dybB3TGfTsfpbuLVkmknsyZ8a/V/2B62z0bs/raRKpFZqv5DMQ= =t4EB -----END PGP SIGNATURE----- --zS7rBR6csb6tI2e1--