From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760820AbZE0P70 (ORCPT ); Wed, 27 May 2009 11:59:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756539AbZE0P7S (ORCPT ); Wed, 27 May 2009 11:59:18 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:48783 "EHLO e4.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756073AbZE0P7S (ORCPT ); Wed, 27 May 2009 11:59:18 -0400 Date: Wed, 27 May 2009 08:59:17 -0700 From: "Paul E. McKenney" To: Mathieu Desnoyers Cc: Catalin Marinas , Russell King - ARM Linux , Jamie Lokier , linux-arm-kernel@lists.arm.linux.org.uk, linux-kernel@vger.kernel.org Subject: Re: Broken ARM atomic ops wrt memory barriers (was : [PATCH] Add cmpxchg support for ARMv6+ systems) Message-ID: <20090527155917.GB6729@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20090525151724.GA14321@Krystal> <20090525161941.GA3667@n2100.arm.linux.org.uk> <20090526145950.GB26713@n2100.arm.linux.org.uk> <20090526153654.GA17096@Krystal> <20090526155906.GC26713@n2100.arm.linux.org.uk> <20090526172322.GB19443@Krystal> <20090526182310.GG26713@n2100.arm.linux.org.uk> <20090527012243.GB29692@Krystal> <1243415686.1947.24.camel@pc1117.cambridge.arm.com> <20090527145244.GC16459@Krystal> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090527145244.GC16459@Krystal> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 27, 2009 at 10:52:44AM -0400, Mathieu Desnoyers wrote: > * Catalin Marinas (catalin.marinas@arm.com) wrote: > > On Tue, 2009-05-26 at 21:22 -0400, Mathieu Desnoyers wrote: > > > So, my questions is : is ARMv7 weak memory ordering model as weak as > > > Alpha ? > > > > I'm not familiar with Alpha but ARM allows a weakly ordered memory > > system (starting with ARMv6), it's up to the processor implementer to > > decide how weak but within the ARM ARM restrictions (section A3.8.2). > > > > I think the main difference with Alpha is that ARM doesn't do > > speculative writes, only speculative reads. The write cannot become > > visible to other observers in the same shareability domain before the > > instruction occurs in program order. But because of the write buffer, > > there is no guarantee on the order of two writes becoming visible to > > other observers in the same shareability domain. The reads from normal > > memory can happen speculatively (with a few restrictions) > > > > Summarising from the ARM ARM, there are two terms used: > > > > Address dependency - an address dependency exists when the value > > returned by a read access is used to compute the virtual address > > of a subsequent read or write access. > > > > Control dependency - a control dependency exists when the data > > value returned by a read access is used to determine the > > condition code flags, and the values of the flags are used for > > condition code checking to determine the address of a subsequent > > read access. > > > > The (simplified) memory ordering restrictions of two explicit accesses > > (where multiple observers are present and in the same shareability > > domain): > > > > * If there is an address dependency then the two memory accesses > > are observed in program order by any observer > > * If the value returned by a read access is used as data written > > by a subsequent write access, then the two memory accesses are > > observed in program order > > * It is impossible for an observer of a memory location to observe > > a write access to that memory location if that location would > > not be written to in a sequential execution of a program > > > > Outside of these restrictions, the processor implementer can do whatever > > it makes the CPU faster. To ensure the relative ordering between memory > > accesses (either read or write), the software should have DMB > > instructions. > > Great, so no need to worry about smp_read_barrier_depend then, given > there is an address dependency. No need to worry from a CPU viewpoint, but still need to disable any value-speculation optimizations that the compiler guys might indulge in. Thanx, Paul > Thanks ! > > Mathieu > > > -- > > Catalin > > > > -- > Mathieu Desnoyers > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68