diff options
author | David Howells <dhowells@redhat.com> | 2006-06-25 08:49:22 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-25 13:01:24 -0400 |
commit | 6bc392741d661eb84be503d1fdf14b6746615e4c (patch) | |
tree | a4b5b833f4425880eb6122f51186c5161018b93c | |
parent | 6f84be84b4cde72fa2a2f0d10ac284a31e923200 (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>
-rw-r--r-- | Documentation/memory-barriers.txt | 19 |
1 files changed, 9 insertions, 10 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index cc53f47a83e8..cf0d5416a4c3 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 | |||
489 | variable B might be stored in an even-numbered cache line. Then, if the | 489 | variable B might be stored in an even-numbered cache line. Then, if the |
490 | even-numbered bank of the reading CPU's cache is extremely busy while the | 490 | even-numbered bank of the reading CPU's cache is extremely busy while the |
491 | odd-numbered bank is idle, one can see the new value of the pointer P (&B), | 491 | odd-numbered bank is idle, one can see the new value of the pointer P (&B), |
492 | but the old value of the variable B (1). | 492 | but the old value of the variable B (2). |
493 | 493 | ||
494 | 494 | ||
495 | Another example of where data dependency barriers might by required is where a | 495 | Another 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 | ||
752 | If, however, a read barrier were to be placed between the load of E and the | 752 | If, however, a read barrier were to be placed between the load of B and the |
753 | load of A on CPU 2: | 753 | load 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 | ||
1467 | On a UP system - where this wouldn't be a problem - the smp_mb() is just a | 1467 | On a UP system - where this wouldn't be a problem - the smp_mb() is just a |
1468 | compiler barrier, thus making sure the compiler emits the instructions in the | 1468 | compiler barrier, thus making sure the compiler emits the instructions in the |
1469 | right order without actually intervening in the CPU. Since there there's only | 1469 | right order without actually intervening in the CPU. Since there's only one |
1470 | one CPU, that CPU's dependency ordering logic will take care of everything | 1470 | CPU, that CPU's dependency ordering logic will take care of everything else. |
1471 | else. | ||
1472 | 1471 | ||
1473 | 1472 | ||
1474 | ATOMIC OPERATIONS | 1473 | ATOMIC 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 |