diff options
author | David Howells <dhowells@redhat.com> | 2006-06-25 08:48:49 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-25 13:01:19 -0400 |
commit | 2b94895b9281976cf2a0f2f89bf41ee219742235 (patch) | |
tree | bf42dba4bfb46c708d5fbb77ce7010f0058c3389 /Documentation | |
parent | 326f28e9ec4b2619c2fd410593fc95fcb0ba6b41 (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')
-rw-r--r-- | Documentation/memory-barriers.txt | 15 |
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 | |||
262 | CPU to restrict the order. | 262 | CPU to restrict the order. |
263 | 263 | ||
264 | Memory barriers are such interventions. They impose a perceived partial | 264 | Memory barriers are such interventions. They impose a perceived partial |
265 | ordering between the memory operations specified on either side of the barrier. | 265 | ordering over the memory operations on either side of the barrier. |
266 | They request that the sequence of memory events generated appears to other | 266 | |
267 | parts of the system as if the barrier is effective on that CPU. | 267 | Such enforcement is important because the CPUs and other devices in a system |
268 | can use a variety of tricks to improve performance - including reordering, | ||
269 | deferral and combination of memory operations; speculative loads; speculative | ||
270 | branch prediction and various types of caching. Memory barriers are used to | ||
271 | override or suppress these tricks, allowing the code to sanely control the | ||
272 | interaction of multiple CPUs and/or devices. | ||
268 | 273 | ||
269 | 274 | ||
270 | VARIETIES OF MEMORY BARRIER | 275 | VARIETIES OF MEMORY BARRIER |
@@ -461,8 +466,8 @@ Whilst this may seem like a failure of coherency or causality maintenance, it | |||
461 | isn't, and this behaviour can be observed on certain real CPUs (such as the DEC | 466 | isn't, and this behaviour can be observed on certain real CPUs (such as the DEC |
462 | Alpha). | 467 | Alpha). |
463 | 468 | ||
464 | To deal with this, a data dependency barrier must be inserted between the | 469 | To deal with this, a data dependency barrier or better must be inserted |
465 | address load and the data load: | 470 | between the address load and the data load: |
466 | 471 | ||
467 | CPU 1 CPU 2 | 472 | CPU 1 CPU 2 |
468 | =============== =============== | 473 | =============== =============== |