lkml.org 
[lkml]   [2006]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH] Another couple of alterations to the memory barrier doc
Date

The attached patch makes 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>
---
warthog>diffstat -p1 /tmp/mb.diff
Documentation/memory-barriers.txt | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 4710845..cc53f47 100644
--- a/Documentation/memory-barriers.txt
+++ b/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
=============== ===============
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2006-06-12 12:44    [W:0.036 / U:1.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site