From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Date: Tue, 26 Jan 2016 12:10:37 -0800 Message-ID: <20160126201037.GU4503@linux.vnet.ibm.com> References: <20160114204827.GE3818@linux.vnet.ibm.com> <20160118081929.GA30420@gondor.apana.org.au> <20160118154629.GB3818@linux.vnet.ibm.com> <20160126165207.GB6029@fixme-laptop.cn.ibm.com> <20160126172227.GG6357@twins.programming.kicks-ass.net> Reply-To: paulmck@linux.vnet.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Linus Torvalds Cc: Peter Zijlstra , Boqun Feng , Herbert Xu , Leonid Yegoshin , linux-mips , "linux-ia64@vger.kernel.org" , "Michael S. Tsirkin" , Will Deacon , virtualization , Peter Anvin , sparclinux@vger.kernel.org, Ingo Molnar , "linux-arch@vger.kernel.org" , linux-s390 , Russell King - ARM Linux , uml-devel , linux-sh@vger.kernel.org, Michael Ellerman , the arch/x86 maintainers , xen-devel@lists.xenproject.org, Ingo Molnar , linux-xtensa@linu List-Id: linux-arch.vger.kernel.org On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > > > This is distinct from: >=20 > That may be distinct, but: >=20 > > struct foo *x =3D READ_ONCE(*ptr); > > smp_read_barrier_depends(); > > x->bar =3D 5; >=20 > This case is complete BS. Stop perpetuating it. I already removed a > number of bogus cases of it, and I removed the incorrect documentatio= n > that had this crap. If I understand your objection correctly, you want the above pattern expressed either like this: struct foo *x =3D rcu_dereference(*ptr); x->bar =3D 5; Or like this: struct foo *x =3D lockless_dereference(*ptr); x->bar =3D 5; Or am I missing your point? > It's called "smp_READ_barrier_depends()" for a reason. >=20 > Alpha is the only one that needs it, and alpha needs it only for > dependent READS. >=20 > It's not called smp_read_write_barrier_depends(). It's not called > "smp_mb_depends()". It's a weaker form of "smp_rmb()", nothing else. >=20 > So alpha does have an implied dependency chain from a read to a > subsequent dependent write, and does not need any extra barriers. >=20 > Alpha does *not* have a dependency chain from a read to a subsequent > read, which is why we need that horrible crappy > smp_read_barrier_depends(). But it's the only reason. >=20 > This is the alpha reference manual wrt read-to-write dependency: >=20 > 5.6.1.7 Definition of Dependence Constraint >=20 > The depends relation (DP) is defined as follows. Given u and v > issued by processor Pi, where u > is a read or an instruction fetch and v is a write, u precedes v > in DP order (written u DP v, that > is, v depends on u) in either of the following situations: >=20 > =E2=80=A2 u determines the execution of v, the location accessed= by v, or > the value written by v. > =E2=80=A2 u determines the execution or address or value of anot= her > memory access z that precedes >=20 > v or might precede v (that is, would precede v in some execution > path depending > on the value read by u) by processor issue constraint (see Sectio= n 5.6.1.3). >=20 > Note that the dependence barrier honors not only control flow, but > address and data values too. This is a different syntax than we use, > but 'u' is the READ_ONCE, and 'v' is the write. Any data, address or > conditional dependency between the two implies an ordering. >=20 > So no, "smp_read_barrier_depends()" is *ONLY* about two reads, where > the second read is data-dependent on the first. Nothing else. >=20 > So if you _ever_ see a "smp_read_barrier_depends()" that isn't about = a > barrier between two reads, then that is a bug. And the smp_read_barrier_depends() in both rcu_dereference() and in lockless_dereference() is ordering the read-to-read case and the underlying hardware is ordering the read-to-write case on weakly ordere= d hardware. Or, again, am I missing your point? Thanx, Paul > The above code is crap. It's exactly as much crap as >=20 > a =3D READ_ONCE(x); > smp_rmb(); > WRITE_ONCE(b, y); >=20 > because a "rmb()" simply doesn't have anything to do with > read-vs-subsequent-write ordering. >=20 > Linus >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e34.co.us.ibm.com ([32.97.110.152]:50013 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752752AbcAZWAF (ORCPT ); Tue, 26 Jan 2016 17:00:05 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Jan 2016 15:00:04 -0700 Date: Tue, 26 Jan 2016 12:10:37 -0800 From: "Paul E. McKenney" Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Message-ID: <20160126201037.GU4503@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160114204827.GE3818@linux.vnet.ibm.com> <20160118081929.GA30420@gondor.apana.org.au> <20160118154629.GB3818@linux.vnet.ibm.com> <20160126165207.GB6029@fixme-laptop.cn.ibm.com> <20160126172227.GG6357@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: Peter Zijlstra , Boqun Feng , Herbert Xu , Leonid Yegoshin , linux-mips , "linux-ia64@vger.kernel.org" , "Michael S. Tsirkin" , Will Deacon , virtualization , Peter Anvin , sparclinux@vger.kernel.org, Ingo Molnar , "linux-arch@vger.kernel.org" , linux-s390 , Russell King - ARM Linux , uml-devel , linux-sh@vger.kernel.org, Michael Ellerman , the arch/x86 maintainers , xen-devel@lists.xenproject.org, Ingo Molnar , linux-xtensa@linux-xtensa.org, James Hogan , Arnd Bergmann , Stefano Stabellini , adi-buildroot-devel@lists.sourceforge.net, David Daney , Thomas Gleixner , linux-metag@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , Andrew Cooper , Linux Kernel Mailing List , Ralf Baechle , Joe Perches , ppc-dev , David Miller Message-ID: <20160126201037.nexza7MpgjSxmbbn6QbyfECeO0SxXH02ncmkwY_DySU@z> On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote: > On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > > > This is distinct from: > > That may be distinct, but: > > > struct foo *x = READ_ONCE(*ptr); > > smp_read_barrier_depends(); > > x->bar = 5; > > This case is complete BS. Stop perpetuating it. I already removed a > number of bogus cases of it, and I removed the incorrect documentation > that had this crap. If I understand your objection correctly, you want the above pattern expressed either like this: struct foo *x = rcu_dereference(*ptr); x->bar = 5; Or like this: struct foo *x = lockless_dereference(*ptr); x->bar = 5; Or am I missing your point? > It's called "smp_READ_barrier_depends()" for a reason. > > Alpha is the only one that needs it, and alpha needs it only for > dependent READS. > > It's not called smp_read_write_barrier_depends(). It's not called > "smp_mb_depends()". It's a weaker form of "smp_rmb()", nothing else. > > So alpha does have an implied dependency chain from a read to a > subsequent dependent write, and does not need any extra barriers. > > Alpha does *not* have a dependency chain from a read to a subsequent > read, which is why we need that horrible crappy > smp_read_barrier_depends(). But it's the only reason. > > This is the alpha reference manual wrt read-to-write dependency: > > 5.6.1.7 Definition of Dependence Constraint > > The depends relation (DP) is defined as follows. Given u and v > issued by processor Pi, where u > is a read or an instruction fetch and v is a write, u precedes v > in DP order (written u DP v, that > is, v depends on u) in either of the following situations: > > • u determines the execution of v, the location accessed by v, or > the value written by v. > • u determines the execution or address or value of another > memory access z that precedes > > v or might precede v (that is, would precede v in some execution > path depending > on the value read by u) by processor issue constraint (see Section 5.6.1.3). > > Note that the dependence barrier honors not only control flow, but > address and data values too. This is a different syntax than we use, > but 'u' is the READ_ONCE, and 'v' is the write. Any data, address or > conditional dependency between the two implies an ordering. > > So no, "smp_read_barrier_depends()" is *ONLY* about two reads, where > the second read is data-dependent on the first. Nothing else. > > So if you _ever_ see a "smp_read_barrier_depends()" that isn't about a > barrier between two reads, then that is a bug. And the smp_read_barrier_depends() in both rcu_dereference() and in lockless_dereference() is ordering the read-to-read case and the underlying hardware is ordering the read-to-write case on weakly ordered hardware. Or, again, am I missing your point? Thanx, Paul > The above code is crap. It's exactly as much crap as > > a = READ_ONCE(x); > smp_rmb(); > WRITE_ONCE(b, y); > > because a "rmb()" simply doesn't have anything to do with > read-vs-subsequent-write ordering. > > Linus >