From: Jamie Lokier <jamie@shareable.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nick Piggin <npiggin@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Mackerras <paulus@samba.org>,
linux-arch@vger.kernel.org, Russell King <rmk@arm.linux.org.uk>,
Francois Romieu <romieu@fr.zoreil.com>
Subject: Re: SMP barriers semantics
Date: Sat, 24 Apr 2010 02:45:36 +0100 [thread overview]
Message-ID: <20100424014536.GD15349@shareable.org> (raw)
In-Reply-To: <1272043500.15107.87.camel@e102109-lin.cambridge.arm.com>
Catalin Marinas wrote:
> On recent ARM cores, it's only the Strongly Ordered memory that can have
> the write buffering disabled. But using such mapping for
> dma_alloc_coherent() introduces other problems like cache attribute
> aliases for a physical location (since the kernel maps the RAM as Normal
> memory already). Such aliases are not allowed hence we moved to Normal
> Non-cacheable for dma_alloc_coherent().
I'm surprised aliases between Normal-Cached and Normal-Uncached are ok,
while aliases between Normal-Cached and SO-Uncached are not ok.
Is it theoretically ok by the ARM specs, or just optimistic programming? :-)
If optimism, it's easy to imagine an implementation where
(unrequested) speculative reads populate the cached mapping, and then
accesses to the Normal-Uncached alias of it get a cache hit and use
that, wrongly. Or, conversely, if it definitely does not treat that
as a cache hit, it's hard to imagine why SO-Uncached would be different.
-- Jamie
next prev parent reply other threads:[~2010-04-24 1:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 10:52 SMP barriers semantics Catalin Marinas
2010-03-03 0:55 ` Paul Mackerras
2010-03-03 12:03 ` Catalin Marinas
2010-03-12 12:31 ` Ralf Baechle
2010-03-12 20:38 ` Jamie Lokier
2010-03-17 2:25 ` Benjamin Herrenschmidt
2010-03-17 10:31 ` Catalin Marinas
2010-03-17 13:42 ` Jamie Lokier
2010-03-22 12:02 ` Nick Piggin
2010-03-23 3:42 ` Nick Piggin
2010-03-23 10:24 ` Catalin Marinas
2010-04-06 14:20 ` Nick Piggin
2010-04-06 15:43 ` Jamie Lokier
2010-04-06 16:04 ` Nick Piggin
2010-04-23 16:23 ` Catalin Marinas
2010-04-23 16:56 ` Jamie Lokier
2010-04-23 17:25 ` Catalin Marinas
2010-04-24 1:45 ` Jamie Lokier [this message]
2010-04-26 9:21 ` Catalin Marinas
2010-03-04 2:23 ` David Dillow
2010-03-04 9:33 ` Russell King
2010-03-04 9:48 ` Catalin Marinas
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=20100424014536.GD15349@shareable.org \
--to=jamie@shareable.org \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--cc=romieu@fr.zoreil.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.