From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbcKRI0m (ORCPT ); Fri, 18 Nov 2016 03:26:42 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36491 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752452AbcKRI0h (ORCPT ); Fri, 18 Nov 2016 03:26:37 -0500 Date: Fri, 18 Nov 2016 16:26:34 +0800 From: Boqun Feng To: Will Deacon Cc: Peter Zijlstra , gregkh@linuxfoundation.org, keescook@chromium.org, elena.reshetova@intel.com, arnd@arndb.de, tglx@linutronix.de, mingo@kernel.org, hpa@zytor.com, dave@progbits.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 7/7] kref: Implement using refcount_t Message-ID: <20161118082634.GD5227@tardis.cn.ibm.com> References: <20161114173946.501528675@infradead.org> <20161114174446.832175072@infradead.org> <20161115123337.GD12110@tardis.cn.ibm.com> <20161115130154.GX3117@twins.programming.kicks-ass.net> <20161115141909.GJ27541@tardis.cn.ibm.com> <20161117092800.GD3142@twins.programming.kicks-ass.net> <20161117120836.GE22855@arm.com> <20161117161110.GG3117@twins.programming.kicks-ass.net> <20161117163624.GP22855@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jKBxcB1XkHIR0Eqt" Content-Disposition: inline In-Reply-To: <20161117163624.GP22855@arm.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 17, 2016 at 04:36:24PM +0000, Will Deacon wrote: > On Thu, Nov 17, 2016 at 05:11:10PM +0100, Peter Zijlstra wrote: > > On Thu, Nov 17, 2016 at 12:08:36PM +0000, Will Deacon wrote: > > > All sounds reasonable to me. It's worth pointing out that you can't c= reate > > > order using a control dependency hanging off the status flag of a > > > store-conditional, but the code in question here has the dependency f= rom > > > the loaded value, which is sufficient. > >=20 > > Yeah, I'm always surprised by that 'feature'. Is that ARM specific? Or > > so more LL/SC archs have this? >=20 > In general, I'm not sure, but I think PPC does allow for the control > dependency. >=20 You guys mean the "control dependency" from a sc to subsequent WRITE, like in the following litmus? PPC sc-control "" { 0:r11=3Dx;0:r12=3Dy;0:r3=3D1;0:r10=3D0; 1:r11=3Dx;1:r12=3Dy; } P0 | P1 ; lwarx r2, r10, r11 | lwz r2, 0(r12) ; stwcx. r3, r10, r11 | lwsync ; bne Fail | ; stw r3, 0(r12) | lwz r1, 0(r11) ; Fail: | ; exists (1:r2 =3D 1 /\ x =3D 1 /\ 1:r1 =3D 0) PPCMEM and herd both said the exists-clause could be triggered "Sometimes". And ISA said: """ Because a Store Conditional instruction may complete before its store has been performed, a conditional Branch instruction that depends on the CR0 value set by a Store Conditional instruction does not order the Store Conditional's store with respect to storage accesses caused by instructions that follow the Branch. """ So ppc doesn't honor this "control dependency". ;-) Regards, Boqun > Will --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAABCAAGBQJYLrs3AAoJEEl56MO1B/q4Yp8H/1/FW3Z+rtIMcUMhqu84nBv3 8OdH7xLqbIC0PO1A98byILvfqeX6G055MUNICtYrQOa1zNrVznN3j0/lc9UkRMvo e/9bb8DdzBRN8v6qyShMpnrRJYh+U7ODpGOxVt2UnO2eLF6AHZVTHC/O4S2nPGep E2yEy8hmeJ/LTOnLWkmyyi5nyxLJrjnrZqJ5BuD3SygWw7ZuNhNBzxYEH/SbImuU hFu1mvspcpGaGpv/PDrKBw7LsggU4mBGQJSUng8arrx0qd8y0H92YGvngfIFaZxt BG0HigI3q5p1sXTwLb+qQFuxzWQs/qNX9LD+g9vDjMFHTJ/RQ0HbAx6ejtlMHnc= =v3Xb -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt--