From: Roland Dreier <rdreier@cisco.com>
To: Keith Owens <kaos@sgi.com>
Cc: paulmck@us.ibm.com, Andi Kleen <ak@suse.de>,
ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com,
vatsa@in.ibm.com, Oleg Nesterov <oleg@tv-sign.ru>,
linux-kernel@vger.kernel.org,
Dipankar Sarma <dipankar@in.ibm.com>,
Andrew Morton <akpm@osdl.org>, Ingo Molnar <mingo@elte.hu>
Subject: Re: Semantics of smp_mb()
Date: Thu, 15 Dec 2005 13:15:38 -0800 [thread overview]
Message-ID: <adairtqnjt1.fsf@cisco.com> (raw)
In-Reply-To: <17158.1134512861@ocs3.ocs.com.au> (Keith Owens's message of "Wed, 14 Dec 2005 09:27:41 +1100")
Keith> Why does mmiowb() map to empty on most systems, including
Keith> Alpha? Should it not map to wmb() for everything except
Keith> IA64 and MIPS?
I think the intention (as spelled out in Documentation/DocBook/deviceiobook.tmpl)
is that mmiowb() must be used in conjunction with spinlocks or some
other SMP synchronization mechanism. The locks themselves are
sufficient ordering on the archs where mmiowb() is a NOP.
One way of thinking about this is that the usually barrier operations
like wmb() affect the order of a single CPU's operations -- that is,
wmb() is saying that all writes from the current thread of execution
before the wmb() become visible before any of the writes from the
current after the wmb(). But wmb() doesn't say anything about how one
CPU's writes are ordered against anything a different CPU does.
mmiowb() is something else -- it controls the visibility of writes
from different CPUs. It says that all writes before the mmiowb()
become visible before any writes from any CPU after the mmiowb().
However, this isn't sensible unless we can order the writes between
CPUs, and that only makes sense if there's a lock that lets us say
that one CPU is executing something after the mmiowb().
- R.
next prev parent reply other threads:[~2005-12-15 21:16 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-08 19:31 [PATCH] Fix RCU race in access of nohz_cpu_mask Oleg Nesterov
2005-12-09 2:46 ` Srivatsa Vaddagiri
2005-12-09 19:17 ` Oleg Nesterov
2005-12-10 15:19 ` Srivatsa Vaddagiri
2005-12-10 18:55 ` Oleg Nesterov
2005-12-11 17:41 ` Semantics of smp_mb() [was : Re: [PATCH] Fix RCU race in access of nohz_cpu_mask ] Srivatsa Vaddagiri
2005-12-11 21:21 ` Andrew James Wade
2005-12-11 23:45 ` Rusty Russell
2005-12-12 0:49 ` Keith Owens
2005-12-12 8:41 ` Srivatsa Vaddagiri
2005-12-12 19:33 ` Oleg Nesterov
2005-12-13 5:20 ` Paul E. McKenney
2005-12-13 5:07 ` Andrew James Wade
2005-12-13 5:43 ` Paul E. McKenney
2005-12-13 11:20 ` Andi Kleen
2005-12-13 16:20 ` Paul E. McKenney
2005-12-13 22:27 ` Keith Owens
2005-12-13 22:50 ` Paul E. McKenney
2005-12-14 1:12 ` Andi Kleen
2005-12-14 1:46 ` Paul E. McKenney
2005-12-15 21:15 ` Roland Dreier [this message]
2005-12-16 7:46 ` Jeremy Higdon
2006-03-13 18:39 ` Paul E. McKenney
2006-03-31 4:56 ` Jeremy Higdon
2006-03-31 6:18 ` Paul E. McKenney
2006-03-31 23:38 ` Jesse Barnes
2005-12-12 3:10 ` [PATCH] Fix RCU race in access of nohz_cpu_mask Paul E. McKenney
2005-12-12 4:32 ` Andrew Morton
2005-12-12 4:38 ` David S. Miller
2005-12-12 4:47 ` Nick Piggin
2005-12-12 4:49 ` Paul Mackerras
2005-12-12 6:27 ` Keith Owens
2005-12-09 2:56 ` Srivatsa Vaddagiri
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=adairtqnjt1.fsf@cisco.com \
--to=rdreier@cisco.com \
--cc=ajwade@cpe001346162bf9-cm0011ae8cd564.cpe.net.cable.rogers.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=kaos@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=vatsa@in.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