All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 23 Apr 2010 17:56:28 +0100	[thread overview]
Message-ID: <20100423165628.GA15349@shareable.org> (raw)
In-Reply-To: <1272039830.15107.76.camel@e102109-lin.cambridge.arm.com>

Catalin Marinas wrote:
> On ARM, the I/O accessors are ordered with respect to device memory
> accesses but not with respect to normal non-cacheable memory
> (dma_alloc_coherent). If we want to make the writel etc. accessors
> ordered with respect to the normal non-cacheable memory, that would be
> really expensive on several ARM platforms. Apart from the CPU barrier (a
> full one - DSB - to drain the write buffer), some platforms require
> draining the write buffer of the L2 cache as well (by writing to other
> registers to the L2 cache controller).

It is useful to call it non-cacheable memory if the only way to make
it device-visible is an instruction to the L2 cache controller asking
it to flush? :-)

On at least one ARM-compatible core I know of, you can disable write
buffering for a region, independent of caching.  Is it possible in
general, to make dma_alloc_coherent on ARM return unbuffered uncached memory?

> So I'm more in favour of having stronger semantics for wmb() and leaving
> the I/O accessors semantics to only ensure device memory ordering.

From the above, I'm thinking the semantics for wmb() should include:

   - Flushes any buffered writes to memory which is mapped uncached,
     but does not have to flush buffered writes to cached memory.

So if the arch always mapped uncached memory also unbuffered, wmb()
won't have to flush the CPU write buffer, which can be expensive as you say.

You probably already planned on this, but it's good to make
it explicit in any docs - if that's an agreeable semantic.

-- Jamie

  reply	other threads:[~2010-04-23 16:56 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 [this message]
2010-04-23 17:25                     ` Catalin Marinas
2010-04-24  1:45                       ` Jamie Lokier
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=20100423165628.GA15349@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.