From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: mingo@elte.hu, laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
eric.dumazet@gmail.com, darren@dvhart.com,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: [PATCH RFC tip/core/rcu 06/11] smp: Document transitivity for memory barriers.
Date: Tue, 22 Feb 2011 17:39:35 -0800 [thread overview]
Message-ID: <1298425183-21265-6-git-send-email-paulmck@linux.vnet.ibm.com> (raw)
In-Reply-To: <20110223013917.GA20996@linux.vnet.ibm.com>
Transitivity is guaranteed only for full memory barriers (smp_mb()).
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
Documentation/memory-barriers.txt | 58 +++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 631ad2f..f0d3a80 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -21,6 +21,7 @@ Contents:
- SMP barrier pairing.
- Examples of memory barrier sequences.
- Read memory barriers vs load speculation.
+ - Transitivity
(*) Explicit kernel barriers.
@@ -959,6 +960,63 @@ the speculation will be cancelled and the value reloaded:
retrieved : : +-------+
+TRANSITIVITY
+------------
+
+Transitivity is a deeply intuitive notion about ordering that is not
+always provided by real computer systems. The following example
+demonstrates transitivity (also called "cumulativity"):
+
+ CPU 1 CPU 2 CPU 3
+ ======================= ======================= =======================
+ { X = 0, Y = 0 }
+ STORE X=1 LOAD X STORE Y=1
+ <general barrier> <general barrier>
+ LOAD Y LOAD X
+
+Suppose that CPU 2's load from X returns 1 and its load from Y returns 0.
+This indicates that CPU 2's load from X in some sense follows CPU 1's
+store to X and that CPU 2's load from Y in some sense preceded CPU 3's
+store to Y. The question is then "Can CPU 3's load from X return 0?"
+
+Because CPU 2's load from X in some sense came after CPU 1's store, it
+is natural to expect that CPU 3's load from X must therefore return 1.
+This expectation is an example of transitivity: if a load executing on
+CPU A follows a load from the same variable executing on CPU B, then
+CPU A's load must either return the same value that CPU B's load did,
+or must return some later value.
+
+In the Linux kernel, use of general memory barriers guarantees
+transitivity. Therefore, in the above example, if CPU 2's load from X
+returns 1 and its load from Y returns 0, then CPU 3's load from X must
+also return 1.
+
+However, transitivity is -not- guaranteed for read or write barriers.
+For example, suppose that CPU 2's general barrier in the above example
+is changed to a read barrier as shown below:
+
+ CPU 1 CPU 2 CPU 3
+ ======================= ======================= =======================
+ { X = 0, Y = 0 }
+ STORE X=1 LOAD X STORE Y=1
+ <read barrier> <general barrier>
+ LOAD Y LOAD X
+
+This substitution destroys transitivity: in this example, it is perfectly
+legal for CPU 2's load from X to return 1, its load from Y to return 0,
+and CPU 3's load from X to return 0.
+
+The key point is that although CPU 2's read barrier orders its pair
+of loads, it does not guarantee to order CPU 1's store. Therefore, if
+this example runs on a system where CPUs 1 and 2 share a store buffer
+or a level of cache, CPU 2 might have early access to CPU 1's writes.
+General barriers are therefore required to ensure that all CPUs agree
+on the combined order of CPU 1's and CPU 2's accesses.
+
+To reiterate, if your code requires transitivity, use general barriers
+throughout.
+
+
========================
EXPLICIT KERNEL BARRIERS
========================
--
1.7.3.2
next prev parent reply other threads:[~2011-02-23 1:41 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-23 1:39 [PATCH tip/core/rcu 0/14] Preview of RCU patches for 2.6.39 Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 01/11] rcu: call __rcu_read_unlock() in exit_rcu for tiny RCU Paul E. McKenney
2011-02-25 8:29 ` Lai Jiangshan
2011-02-25 19:40 ` Paul E. McKenney
2011-03-24 3:45 ` Lai Jiangshan
2011-03-24 13:07 ` Paul E. McKenney
2011-03-25 2:30 ` Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 02/11] rcutorture: Get rid of duplicate sched.h include Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 03/11] rcu: add documentation saying which RCU flavor to choose Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 04/11] rcupdate: remove dead code Paul E. McKenney
2011-02-23 14:36 ` Mathieu Desnoyers
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 05/11] rcu: add comment saying why DEBUG_OBJECTS_RCU_HEAD depends on PREEMPT Paul E. McKenney
2011-02-23 3:23 ` Steven Rostedt
2011-02-23 13:59 ` Mathieu Desnoyers
[not found] ` <BLU0-SMTP615CB0BE0A2623EF62925096DB0@phx.gbl>
2011-02-23 14:11 ` Steven Rostedt
2011-02-23 14:37 ` Mathieu Desnoyers
2011-02-23 14:55 ` Steven Rostedt
2011-02-23 15:02 ` Mathieu Desnoyers
2011-02-23 15:13 ` [PATCH] debug rcu head support !PREEMPT config Mathieu Desnoyers
[not found] ` <BLU0-SMTP1519908E0ACAEE1384F71896DB0@phx.gbl>
2011-02-23 15:27 ` Steven Rostedt
2011-02-23 15:37 ` Mathieu Desnoyers
[not found] ` <BLU0-SMTP42770DC9BDE561B962274096DB0@phx.gbl>
2011-02-23 18:31 ` Paul E. McKenney
2011-02-23 18:40 ` Mathieu Desnoyers
[not found] ` <BLU0-SMTP900C4ABCF4001FBCB1594696DB0@phx.gbl>
2011-02-23 17:49 ` Paul E. McKenney
2011-02-23 1:39 ` Paul E. McKenney [this message]
2011-02-23 3:29 ` [PATCH RFC tip/core/rcu 06/11] smp: Document transitivity for memory barriers Steven Rostedt
2011-02-23 6:21 ` Lai Jiangshan
2011-02-23 15:14 ` Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 07/11] rcu: Remove conditional compilation for RCU CPU stall warnings Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 08/11] rcu: Decrease memory-barrier usage based on semi-formal proof Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 09/11] rcu: merge TREE_PREEPT_RCU blocked_tasks[] lists Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 10/11] rcu: Update documentation to reflect blocked_tasks[] merge Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 11/11] rcu: move TREE_RCU from softirq to kthread Paul E. McKenney
2011-02-23 2:44 ` Frederic Weisbecker
2011-02-23 15:11 ` Paul E. McKenney
2011-02-23 3:09 ` Frederic Weisbecker
2011-02-23 15:12 ` Paul E. McKenney
2011-02-23 14:02 ` Mathieu Desnoyers
[not found] ` <BLU0-SMTP211F39903EDACD9B7E025C96DB0@phx.gbl>
2011-02-23 14:42 ` Steven Rostedt
2011-02-23 16:16 ` Frederic Weisbecker
2011-02-23 16:41 ` Steven Rostedt
2011-02-23 17:03 ` Mathieu Desnoyers
2011-02-23 17:14 ` Frederic Weisbecker
[not found] ` <BLU0-SMTP5642728A153E83B94895F896DB0@phx.gbl>
2011-02-23 17:30 ` Frederic Weisbecker
[not found] ` <BLU0-SMTP65F733B8D1D704C7EA1F8796DB0@phx.gbl>
2011-02-23 17:34 ` Christoph Lameter
2011-02-23 18:17 ` Steven Rostedt
2011-02-23 18:29 ` Christoph Lameter
2011-02-23 18:32 ` Steven Rostedt
2011-02-23 19:19 ` Christoph Lameter
2011-02-23 19:23 ` Peter Zijlstra
2011-02-23 19:35 ` Steven Rostedt
2011-02-23 19:40 ` Christoph Lameter
2011-02-23 20:15 ` Paul E. McKenney
2011-02-23 19:16 ` Paul E. McKenney
2011-02-23 19:24 ` Christoph Lameter
2011-02-23 20:45 ` Paul E. McKenney
2011-02-23 18:38 ` Mathieu Desnoyers
2011-02-23 18:27 ` Mathieu Desnoyers
2011-02-23 19:10 ` Paul E. McKenney
2011-02-23 19:22 ` Christoph Lameter
2011-02-23 19:39 ` Paul E. McKenney
2011-02-23 16:50 ` Frederic Weisbecker
2011-02-23 19:06 ` Paul E. McKenney
2011-02-23 19:13 ` Frederic Weisbecker
2011-02-23 20:41 ` Paul E. McKenney
[not found] ` <BLU0-SMTP57EE20F30B92B8763FD2FE96DB0@phx.gbl>
2011-02-23 18:52 ` Paul E. McKenney
2011-02-25 8:17 ` Lai Jiangshan
2011-02-25 20:32 ` Paul E. McKenney
2011-02-28 3:29 ` Lai Jiangshan
2011-02-28 9:47 ` Peter Zijlstra
2011-03-01 0:13 ` Paul E. McKenney
2011-03-01 14:38 ` Peter Zijlstra
2011-03-02 0:07 ` Paul E. McKenney
2011-03-02 22:41 ` Paul E. McKenney
2011-02-28 23:51 ` Paul E. McKenney
2011-03-02 1:52 ` Lai Jiangshan
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 12/14] rcu: priority boosting for TREE_PREEMPT_RCU Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 13/14] rcu: eliminate unused boosting statistics Paul E. McKenney
2011-02-23 1:39 ` [PATCH RFC tip/core/rcu 14/14] rcu: Add boosting to TREE_PREEMPT_RCU tracing Paul E. McKenney
2011-02-23 3:07 ` Lai Jiangshan
2011-02-23 16:31 ` Paul E. McKenney
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=1298425183-21265-6-git-send-email-paulmck@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®