From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Catalin Marinas <catalin.marinas@arm.com>
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 14:40:41 -0400 [thread overview]
Message-ID: <20090527184041.GA22545@Krystal> (raw)
In-Reply-To: <1243415686.1947.24.camel@pc1117.cambridge.arm.com>
* 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.
>
Just to make sure :
for the read seqlock, a smp_rmb() is present. I assume that given there
is no address nor control dependency (as stated above) between the
seqlock value reads and the data access, these barriers cannot be
downgraded to a smp read barrier depend. It's a shame to have to do two
full dmb for every sequence lock. Are there any plans on the ARM side to
eventually add faster read barriers ?
Basically, on arm, a seqlock fast path takes 11 cycles on UP. If we add
the two dmb, it now takes 73 cycles.
Mathieu
> --
> Catalin
>
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2009-05-27 18:41 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
2009-05-27 20:55 ` Paul E. McKenney
2009-05-27 18:40 ` Mathieu Desnoyers [this message]
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=20090527184041.GA22545@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.