From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Jamie Lokier <jamie@shareable.org>,
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)
Date: Wed, 27 May 2009 12:02:17 -0400 [thread overview]
Message-ID: <20090527160217.GC18667@Krystal> (raw)
In-Reply-To: <20090527155917.GB6729@linux.vnet.ibm.com>
* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> 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.
>
Yes, that's ACCESS_ONCE() job's, right ? (cast to volatile * and
dereference again to hide from compiler)
Mathieu
> Thanx, Paul
>
> > Thanks !
> >
> > Mathieu
> >
> > > --
> > > Catalin
> > >
> >
> > --
> > Mathieu Desnoyers
> > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2009-05-27 16:02 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090422171703.19555.83629.stgit@pc1117.cambridge.arm.com>
[not found] ` <20090423141248.22193.10543.stgit@pc1117.cambridge.arm.com>
[not found] ` <20090524131636.GB3159@n2100.arm.linux.org.uk>
2009-05-24 14:56 ` Broken ARM atomic ops wrt memory barriers (was : [PATCH] Add cmpxchg support for ARMv6+ systems) Mathieu Desnoyers
2009-05-25 13:20 ` Jamie Lokier
2009-05-25 15:17 ` Mathieu Desnoyers
2009-05-25 16:19 ` Russell King - ARM Linux
2009-05-25 17:29 ` Mathieu Desnoyers
2009-05-25 19:34 ` Russell King - ARM Linux
2009-05-25 20:05 ` Mathieu Desnoyers
2009-05-26 11:29 ` Catalin Marinas
2009-05-25 19:56 ` Russell King - ARM Linux
2009-05-25 20:22 ` Mathieu Desnoyers
2009-05-25 21:45 ` Broken ARM (and powerpc ?) futex wrt memory barriers Mathieu Desnoyers
2009-05-25 21:57 ` Russell King - ARM Linux
2009-05-25 22:27 ` Mathieu Desnoyers
2009-05-26 14:59 ` Broken ARM atomic ops wrt memory barriers (was : [PATCH] Add cmpxchg support for ARMv6+ systems) Russell King - ARM Linux
2009-05-26 15:36 ` Mathieu Desnoyers
2009-05-26 15:59 ` Russell King - ARM Linux
2009-05-26 17:23 ` Mathieu Desnoyers
2009-05-26 18:23 ` Russell King - ARM Linux
2009-05-26 19:17 ` Jamie Lokier
2009-05-26 19:56 ` Russell King - ARM Linux
2009-05-27 1:22 ` Mathieu Desnoyers
2009-05-27 8:56 ` Russell King - ARM Linux
2009-05-27 9:18 ` Catalin Marinas
2009-05-27 9:14 ` Catalin Marinas
2009-05-27 14:52 ` Mathieu Desnoyers
2009-05-27 15:59 ` Paul E. McKenney
2009-05-27 16:02 ` Mathieu Desnoyers [this message]
2009-05-27 20:55 ` Paul E. McKenney
2009-05-27 18:40 ` Mathieu Desnoyers
2009-05-28 18:20 ` Russell King - ARM Linux
2009-05-28 18:38 ` Mathieu Desnoyers
2009-05-28 18:40 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090527160217.GC18667@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=catalin.marinas@arm.com \
--cc=jamie@shareable.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox