From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Date: Wed, 27 Jan 2016 08:51:29 +0100 Message-ID: <20160127075129.GH6357@twins.programming.kicks-ass.net> 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> <20160126201037.GU4503@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Linus Torvalds Cc: 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 , Herbert Xu , linux-sh@vger.kernel.org, Michael Ellerman , the arch/x86 maintainers , xen-devel@lists.xenproject.org, Ingo Molnar , Paul McKenney , linux-xtensa@linux-xtensa.org, James Hogan , uml-devel , Stefano Stabellini List-Id: linux-arch.vger.kernel.org On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > If it turns out that some architecture does actually need a barrier > between a read and a dependent write, then that will mean that > > (a) we'll have to make up a _new_ barrier, because > "smp_read_barrier_depends()" is not that barrier. We'll presumably > then have to make that new barrier part of "rcu_derefence()" and > friends. > > (b) we will have found an architecture with even worse memory > ordering semantics than alpha, and we'll have to stop castigating > alpha for being the worst memory ordering ever. > > but I sincerely hope that we'll never find that kind of broken architecture. So for a moment it looked like MIPS wanted to equal or surpass Alpha in this respect. And Paul made the point that smp_read_barrier_depends() really should be smp_aquire_barrier_depends() in that we rely on both dependent reads and writes to be ordered against the initial pointer load. Now, as you've made abundantly clear, Alpha does this, although it needs the little extra help in the dependent read department. The 'problem' is that someone seemed to have used our Documentation/memory-barriers.txt as a specification for what hardware is permitted and we require. And in that light Paul noted that read_barrier_depends really should be considered an acquire_barrier_depends and order both dependent reads and writes against the (prior) read (if nothing else already does). Now clearly, any sane architecture doesn't need anything like this, but again our document doesn't seem to judge. That is, from reading the document one can get the impression is a perfectly fine thing to do. Nowhere does our disdain for this thing show. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bombadil.infradead.org ([198.137.202.9]:45583 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751642AbcA0HwD (ORCPT ); Wed, 27 Jan 2016 02:52:03 -0500 Date: Wed, 27 Jan 2016 08:51:29 +0100 From: Peter Zijlstra Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h Message-ID: <20160127075129.GH6357@twins.programming.kicks-ass.net> 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> <20160126201037.GU4503@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: Paul McKenney , 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: <20160127075129.UiWgyY8f1YjbapArxJkqNvmlTL0Cy3aBKJxkt3mSBus@z> On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > If it turns out that some architecture does actually need a barrier > between a read and a dependent write, then that will mean that > > (a) we'll have to make up a _new_ barrier, because > "smp_read_barrier_depends()" is not that barrier. We'll presumably > then have to make that new barrier part of "rcu_derefence()" and > friends. > > (b) we will have found an architecture with even worse memory > ordering semantics than alpha, and we'll have to stop castigating > alpha for being the worst memory ordering ever. > > but I sincerely hope that we'll never find that kind of broken architecture. So for a moment it looked like MIPS wanted to equal or surpass Alpha in this respect. And Paul made the point that smp_read_barrier_depends() really should be smp_aquire_barrier_depends() in that we rely on both dependent reads and writes to be ordered against the initial pointer load. Now, as you've made abundantly clear, Alpha does this, although it needs the little extra help in the dependent read department. The 'problem' is that someone seemed to have used our Documentation/memory-barriers.txt as a specification for what hardware is permitted and we require. And in that light Paul noted that read_barrier_depends really should be considered an acquire_barrier_depends and order both dependent reads and writes against the (prior) read (if nothing else already does). Now clearly, any sane architecture doesn't need anything like this, but again our document doesn't seem to judge. That is, from reading the document one can get the impression is a perfectly fine thing to do. Nowhere does our disdain for this thing show.