From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754965AbcAOSzE (ORCPT ); Fri, 15 Jan 2016 13:55:04 -0500 Received: from [195.59.15.196] ([195.59.15.196]:51959 "EHLO mailapp01.imgtec.com" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751112AbcAOSzA (ORCPT ); Fri, 15 Jan 2016 13:55:00 -0500 Message-ID: <56994068.4050402@imgtec.com> Date: Fri, 15 Jan 2016 10:54:32 -0800 From: Leonid Yegoshin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Will Deacon , "Paul E. McKenney" CC: Peter Zijlstra , "Michael S. Tsirkin" , , Arnd Bergmann , , Andrew Cooper , Russell King - ARM Linux , , Stefano Stabellini , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Joe Perches , David Miller , , , , , , , , , , , , , , "Ralf Baechle" , Ingo Molnar , , , Michael Ellerman Subject: Re: [v3,11/41] mips: reuse asm-generic/barrier.h References: <569565DA.2010903@imgtec.com> <20160113104516.GE25458@arm.com> <56969F4B.7070001@imgtec.com> <20160113204844.GV6357@twins.programming.kicks-ass.net> <5696BA6E.4070508@imgtec.com> <20160114120445.GB15828@arm.com> <56980145.5030901@imgtec.com> <20160114204827.GE3818@linux.vnet.ibm.com> <56981212.7050301@imgtec.com> <20160114222046.GH3818@linux.vnet.ibm.com> <20160115095756.GA2131@arm.com> In-Reply-To: <20160115095756.GA2131@arm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.20.3.92] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/15/2016 01:57 AM, Will Deacon wrote: > Paul, > > > I think you figured this out while I was sleeping, but just to confirm: > > 1. The MIPS64 ISA doc [1] talks about SYNC in a way that applies only > to memory accesses appearing in *program-order* before the SYNC > > 2. We need WRC+sync+addr to work, which means that the SYNC in P1 must > also capture the store in P0 as being "before" the barrier. Leonid > reckons it works, but his explanation [2] focussed on the address > dependency in P2 as to why this works. If that is the case (i.e. > address dependency provides global transitivity), then WRC+addr+addr > should also work (even though its not required). No, it is not correct. There is one old design which provides access to core (thread0 + thread1) write-buffers for threads load in advance of it is visible to other cores. It means, that WRC+sync+addr passes because of SYNC in write thread and register dependency inside other thread but WRC+addr+addr may fail because other core may get a stale data. > > 3. It seems that WRC+addr+addr doesn't work, so I'm still suspicious > about WRC+sync+addr, because neither the architecture document or > Leonid's explanation tell me that it should be forbidden. > > Will > > [1] https://imgtec.com/?do-download=4302 > [2] http://lkml.kernel.org/r/569565DA.2010903@imgtec.com (scroll to the end)