All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	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: Tue, 6 Apr 2010 16:43:21 +0100	[thread overview]
Message-ID: <20100406154321.GC29236@shareable.org> (raw)
In-Reply-To: <20100406142054.GE5288@laptop>

Nick Piggin wrote:
> On Tue, Mar 23, 2010 at 10:24:07AM +0000, Catalin Marinas wrote:
> 
> But hmm, I don't know if we even need acquire/release IO barriers at
> all. Might be better to just fix up wmb(), get rid of mmiowb(),
> strengthen IO accessors, and then just add special case barriers as
> the need arises.

I must admit I don't understand what wmb() means at this point,
generically from the point of view of arch-independent drivers!  It's
not an inter-CPU ordering (smb_wmb is sufficient), and it doesn't
order all memory and I/O writes (otherwise why mmiowb?).  I suspect a
few people have been unsure, resulting in a bit of confusion about
what goes into different arch implementations of wmb().

For strengthening I/O accessors, do you mean the equivalent of putting
"dmb;dsb" before _and_ after the I/O write inside every call to
writel()?  (That's using ARM as an example: "dmb" means barrier, and
"dsb" means flush write buffers I think, and some ARMs need other,
rather heavier instructions such as a coprocessor instruction or even
an instruction to the L2 cache.)

Because I'm not sure if that's as light as we'd like it to be on
slower CPUs, and __raw_writel or something will get used instead by
some driver writer... leading back to needing to be very clear about
the meaning of wmb/mmiowb.

-- Jamie

  reply	other threads:[~2010-04-06 15:43 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 [this message]
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
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=20100406154321.GC29236@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.