aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2006-06-25 08:48:49 -0400
committerLinus Torvalds <torvalds@g5.osdl.org>2006-06-25 13:01:19 -0400
commit2b94895b9281976cf2a0f2f89bf41ee219742235 (patch)
treebf42dba4bfb46c708d5fbb77ce7010f0058c3389 /Documentation/memory-barriers.txt
parent326f28e9ec4b2619c2fd410593fc95fcb0ba6b41 (diff)
[PATCH] Another couple of alterations to the memory barrier doc
Make another couple of alterations to the memory barrier document following suggestions by Alan Stern and in co-operation with Paul McKenney: (*) Rework the point of introduction of memory barriers and the description of what they are to reiterate why they're needed. (*) Modify a statement about the use of data dependency barriers to note that other barriers can be used instead (as they imply DD-barriers). Signed-off-by: David Howells <dhowells@redhat.com> Acked-By: Paul E. McKenney <paulmck@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation/memory-barriers.txt')
-rw-r--r--Documentation/memory-barriers.txt15
1 files changed, 10 insertions, 5 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 4710845dbac4..cc53f47a83e8 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -262,9 +262,14 @@ What is required is some way of intervening to instruct the compiler and the
262CPU to restrict the order. 262CPU to restrict the order.
263 263
264Memory barriers are such interventions. They impose a perceived partial 264Memory barriers are such interventions. They impose a perceived partial
265ordering between the memory operations specified on either side of the barrier. 265ordering over the memory operations on either side of the barrier.
266They request that the sequence of memory events generated appears to other 266
267parts of the system as if the barrier is effective on that CPU. 267Such enforcement is important because the CPUs and other devices in a system
268can use a variety of tricks to improve performance - including reordering,
269deferral and combination of memory operations; speculative loads; speculative
270branch prediction and various types of caching. Memory barriers are used to
271override or suppress these tricks, allowing the code to sanely control the
272interaction of multiple CPUs and/or devices.
268 273
269 274
270VARIETIES OF MEMORY BARRIER 275VARIETIES OF MEMORY BARRIER
@@ -461,8 +466,8 @@ Whilst this may seem like a failure of coherency or causality maintenance, it
461isn't, and this behaviour can be observed on certain real CPUs (such as the DEC 466isn't, and this behaviour can be observed on certain real CPUs (such as the DEC
462Alpha). 467Alpha).
463 468
464To deal with this, a data dependency barrier must be inserted between the 469To deal with this, a data dependency barrier or better must be inserted
465address load and the data load: 470between the address load and the data load:
466 471
467 CPU 1 CPU 2 472 CPU 1 CPU 2
468 =============== =============== 473 =============== ===============