aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorDavid Howells <dhowells@redhat.com>2006-06-25 08:49:22 -0400
committerLinus Torvalds <torvalds@g5.osdl.org>2006-06-25 13:01:24 -0400
commit6bc392741d661eb84be503d1fdf14b6746615e4c (patch)
treea4b5b833f4425880eb6122f51186c5161018b93c /Documentation
parent6f84be84b4cde72fa2a2f0d10ac284a31e923200 (diff)
[PATCH] Corrections to memory barrier doc
Apply some small corrections to the memory barrier document, as contributed by: Christoph Lameter <clameter@sgi.com> Kirill Smelkov <kirr@mns.spb.ru> Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David Howells <dhowells@redhat.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.txt19
1 files changed, 9 insertions, 10 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index cc53f47a83e..cf0d5416a4c 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -287,7 +287,7 @@ Memory barriers come in four basic varieties:
287 A write barrier is a partial ordering on stores only; it is not required 287 A write barrier is a partial ordering on stores only; it is not required
288 to have any effect on loads. 288 to have any effect on loads.
289 289
290 A CPU can be viewed as as commiting a sequence of store operations to the 290 A CPU can be viewed as committing a sequence of store operations to the
291 memory system as time progresses. All stores before a write barrier will 291 memory system as time progresses. All stores before a write barrier will
292 occur in the sequence _before_ all the stores after the write barrier. 292 occur in the sequence _before_ all the stores after the write barrier.
293 293
@@ -418,7 +418,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
418 indirect effect will be the order in which the second CPU sees the effects 418 indirect effect will be the order in which the second CPU sees the effects
419 of the first CPU's accesses occur, but see the next point: 419 of the first CPU's accesses occur, but see the next point:
420 420
421 (*) There is no guarantee that the a CPU will see the correct order of effects 421 (*) There is no guarantee that a CPU will see the correct order of effects
422 from a second CPU's accesses, even _if_ the second CPU uses a memory 422 from a second CPU's accesses, even _if_ the second CPU uses a memory
423 barrier, unless the first CPU _also_ uses a matching memory barrier (see 423 barrier, unless the first CPU _also_ uses a matching memory barrier (see
424 the subsection on "SMP Barrier Pairing"). 424 the subsection on "SMP Barrier Pairing").
@@ -489,7 +489,7 @@ lines. The pointer P might be stored in an odd-numbered cache line, and the
489variable B might be stored in an even-numbered cache line. Then, if the 489variable B might be stored in an even-numbered cache line. Then, if the
490even-numbered bank of the reading CPU's cache is extremely busy while the 490even-numbered bank of the reading CPU's cache is extremely busy while the
491odd-numbered bank is idle, one can see the new value of the pointer P (&B), 491odd-numbered bank is idle, one can see the new value of the pointer P (&B),
492but the old value of the variable B (1). 492but the old value of the variable B (2).
493 493
494 494
495Another example of where data dependency barriers might by required is where a 495Another example of where data dependency barriers might by required is where a
@@ -749,7 +749,7 @@ some effectively random order, despite the write barrier issued by CPU 1:
749 : : 749 : :
750 750
751 751
752If, however, a read barrier were to be placed between the load of E and the 752If, however, a read barrier were to be placed between the load of B and the
753load of A on CPU 2: 753load of A on CPU 2:
754 754
755 CPU 1 CPU 2 755 CPU 1 CPU 2
@@ -1466,9 +1466,8 @@ instruction itself is complete.
1466 1466
1467On a UP system - where this wouldn't be a problem - the smp_mb() is just a 1467On a UP system - where this wouldn't be a problem - the smp_mb() is just a
1468compiler barrier, thus making sure the compiler emits the instructions in the 1468compiler barrier, thus making sure the compiler emits the instructions in the
1469right order without actually intervening in the CPU. Since there there's only 1469right order without actually intervening in the CPU. Since there's only one
1470one CPU, that CPU's dependency ordering logic will take care of everything 1470CPU, that CPU's dependency ordering logic will take care of everything else.
1471else.
1472 1471
1473 1472
1474ATOMIC OPERATIONS 1473ATOMIC OPERATIONS
@@ -1645,9 +1644,9 @@ functions:
1645 1644
1646 The PCI bus, amongst others, defines an I/O space concept - which on such 1645 The PCI bus, amongst others, defines an I/O space concept - which on such
1647 CPUs as i386 and x86_64 cpus readily maps to the CPU's concept of I/O 1646 CPUs as i386 and x86_64 cpus readily maps to the CPU's concept of I/O
1648 space. However, it may also mapped as a virtual I/O space in the CPU's 1647 space. However, it may also be mapped as a virtual I/O space in the CPU's
1649 memory map, particularly on those CPUs that don't support alternate 1648 memory map, particularly on those CPUs that don't support alternate I/O
1650 I/O spaces. 1649 spaces.
1651 1650
1652 Accesses to this space may be fully synchronous (as on i386), but 1651 Accesses to this space may be fully synchronous (as on i386), but
1653 intermediary bridges (such as the PCI host bridge) may not fully honour 1652 intermediary bridges (such as the PCI host bridge) may not fully honour