The patch titled
Another couple of alterations to the memory barrier doc
has been added to the -mm tree. Its filename is
another-couple-of-alterations-to-the-memory-barrier-doc.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: Another couple of alterations to the memory barrier doc
From: David Howells <dhowells@xxxxxxxxxx>
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@xxxxxxxxxx>
Acked-By: Paul E. McKenney <paulmck@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
Documentation/memory-barriers.txt | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff -puN Documentation/memory-barriers.txt~another-couple-of-alterations-to-the-memory-barrier-doc Documentation/memory-barriers.txt
--- a/Documentation/memory-barriers.txt~another-couple-of-alterations-to-the-memory-barrier-doc
+++ a/Documentation/memory-barriers.txt
@@ -262,9 +262,14 @@ What is required is some way of interven
CPU to restrict the order.
Memory barriers are such interventions. They impose a perceived partial
-ordering between the memory operations specified on either side of the barrier.
-They request that the sequence of memory events generated appears to other
-parts of the system as if the barrier is effective on that CPU.
+ordering over the memory operations on either side of the barrier.
+
+Such enforcement is important because the CPUs and other devices in a system
+can use a variety of tricks to improve performance - including reordering,
+deferral and combination of memory operations; speculative loads; speculative
+branch prediction and various types of caching. Memory barriers are used to
+override or suppress these tricks, allowing the code to sanely control the
+interaction of multiple CPUs and/or devices.
VARIETIES OF MEMORY BARRIER
@@ -461,8 +466,8 @@ Whilst this may seem like a failure of c
isn't, and this behaviour can be observed on certain real CPUs (such as the DEC
Alpha).
-To deal with this, a data dependency barrier must be inserted between the
-address load and the data load:
+To deal with this, a data dependency barrier or better must be inserted
+between the address load and the data load:
CPU 1 CPU 2
=============== ===============
_
Patches currently in -mm which might be from dhowells@xxxxxxxxxx are
git-nfs.patch
add-page_mkwrite-vm_operations-method.patch
selinux-add-hooks-for-key-subsystem.patch
fix-incorrect-sa_onstack-behaviour-for-64-bit-processes.patch
prepare-for-__copy_from_user_inatomic-to-not-zero-missed-bytes.patch
keys-fix-race-between-two-instantiators-of-a-key.patch
keys-fix-race-between-two-instantiators-of-a-key-tidy.patch
another-couple-of-alterations-to-the-memory-barrier-doc.patch
net-rxrpc-use-list_move.patch
fs-use-list_move.patch
mutex-subsystem-synchro-test-module.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
