From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965978AbcA1BME (ORCPT ); Wed, 27 Jan 2016 20:12:04 -0500 Received: from mail-oi0-f43.google.com ([209.85.218.43]:35825 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965647AbcA1BMB (ORCPT ); Wed, 27 Jan 2016 20:12:01 -0500 Date: Thu, 28 Jan 2016 09:11:19 +0800 From: Boqun Feng To: "Maciej W. Rozycki" Cc: Will Deacon , David Daney , =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= , Peter Zijlstra , Ralf Baechle , linux-kernel@vger.kernel.org, Paul McKenney , Linus Torvalds Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock() Message-ID: <20160128011119.GA28090@fixme-laptop.cn.ibm.com> References: <20151112123123.GZ17308@twins.programming.kicks-ass.net> <5644D08D.4080206@caviumnetworks.com> <5644D7B5.6020009@caviumnetworks.com> <20160127114348.GF2390@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Maciej, On Wed, Jan 27, 2016 at 12:41:29PM +0000, Maciej W. Rozycki wrote: > On Wed, 27 Jan 2016, Will Deacon wrote: >=20 > > > Overall I think it should be safe after all to use SYNC_RELEASE and = other=20 > > > modern lightweight barriers uncondtionally under the assumption that= =20 > > > architecture was meant to remain backward compatible. Even though it= =20 > > > might be possible someone would implement unusual semantics for the t= hen=20 > > > undefined `stype' values, I highly doubt it as it would be extra effo= rt=20 > > > and hardware logic space for no gain. We could try and reach archite= cture=20 > > > overseers to double-check whether the `stype' encodings, somewhat=20 > > > irregularly distributed, were indeed defined in a manner so as not to= =20 > > > clash with values implementers chose to use before rev. 2.61 of the= =20 > > > architecture specification. > >=20 > > Do you know whether a SYNC 18 (RELEASE) followed in program order by a > > SYNC 17 (ACQUIRE) creates a full barrier (i.e. something like SYNC 16)? >=20 > By my reading of architecture specifications it does. Specifically=20 > SYNC_RELEASE (18) applies to older loads and stores, and newer stores, an= d=20 > SYNC_ACQUIRE (17) applies to older loads, and newer loads and stores. So= =20 > the two combined ought to be the equivalent to SYNC_MB (16), which applie= s=20 > to both older and newer loads and stores. Of course care has to be taken= =20 Hmm.. so the following reordering couldn't happen? Program order: LOAD A SYNC_RELEASE STORE B LOAD C SYNC_ACQUIRE LOAD D First becomes: LOAD C <------------ SYNC_RELEASE doesn't order newer loads. LOAD A SYNC_RELEASE STORE B SYNC_ACQUIRE LOAD D And then becomes: LOAD C <---- SYNC_ACQUIRE still affect those loads. LOAD D <------------ SYNC_RELEASE doesn't order newer loads. LOAD A SYNC_RELEASE STORE B SYNC_ACQUIRE here doesn't mean that SYNC instructions can be reordered, it here means that the reordering doesn't break SYNC_ACQUIRE's guarantee. I ask this because some architectures(e.g. PPC) allows this kind of reordering. Please see "ACQUIRING FUNCTIONS" in memory-barriers.txt for more information. Thank you ;-) Regards, Boqun > about what happens between SYNC_RELEASE and SYNC_ACQUIRE. This is still= =20 > more lightweight than classic SYNC (0). See the architecture documents,= =20 > e.g. the MIPS32 one[1] for details. >=20 > References: >=20 > [1] "MIPS Architecture For Programmers, Volume II-A: The MIPS32=20 > Instruction Set", MIPS Technologies, Inc., Document Number: MD00086, > Revision 5.04, December 11, 2013, Table 4.7 "Encodings of the=20 > Bits[10:6] of the SYNC instruction; the SType Field", p. 305 >=20 > HTH, >=20 > Maciej >=20 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWqWqyAAoJEEl56MO1B/q4R5cH/1Vym7SSY+4ISwrpcGWKDM+g d9VeSvgxQe7A4Q1aygxoDlPq3acVCDchiwarIYWdDtLvxEjGg+rNbycH3Yg+1+oY p+RDlUoYERBPfToAYo61T1Xu5H7bU9qDtjqBnFB22YIZSELQQWUrykW+k0rTBWh2 ZFBV4ztnmFjVv+n0UR+nPeXlF3EE5dT5ev1Vf41TSE4qwuAudwQtDjVR3hMkhdB6 suuaJ6hbEuQz+xMbDY6hmiiMAJbDtQbHt9MdSM4MtqEH3JCl88RSDjxV1VjLd/3Z F60VmtNTlnVqgoggVzoIl6S3tlczsWK9MJWzePVW7Gi+PNgr0R4/DUetbLJfBnw= =IyuZ -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--