From: Catalin Marinas <catalin.marinas@arm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: 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,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: Broken ARM atomic ops wrt memory barriers (was : [PATCH] Add cmpxchg support for ARMv6+ systems)
Date: Wed, 27 May 2009 10:14:46 +0100 [thread overview]
Message-ID: <1243415686.1947.24.camel@pc1117.cambridge.arm.com> (raw)
In-Reply-To: <20090527012243.GB29692@Krystal>
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.
--
Catalin
next prev parent reply other threads:[~2009-05-27 9:15 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 ` 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 [this message]
2009-05-27 14:52 ` Mathieu Desnoyers
2009-05-27 15:59 ` Paul E. McKenney
2009-05-27 16:02 ` Mathieu Desnoyers
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=1243415686.1947.24.camel@pc1117.cambridge.arm.com \
--to=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=mathieu.desnoyers@polymtl.ca \
--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
all inboxes | Powered by JetHome®