diff options
author | David Howells <dhowells@redhat.com> | 2006-06-10 09:54:12 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-10 11:02:05 -0700 |
commit | 670bd95e0413c43f878b73a4a3919d1f452a4157 (patch) | |
tree | db7b05810c5cc61c89b856996174e31147611cba /Documentation/filesystems | |
parent | d90d2c385d4d832428d1e51c2a7edeef39c822f5 (diff) |
[PATCH] Further alterations for memory barrier document
From: David Howells <dhowells@redhat.com>
Apply some alterations to the memory barrier document that I worked out
with Paul McKenney of IBM, plus some of the alterations suggested by Alan
Stern.
The following changes were made:
(*) One of the examples given for what can happen with overlapping memory
barriers was wrong.
(*) The description of general memory barriers said that a general barrier is
a combination of a read barrier and a write barrier. This isn't entirely
true: it implies both, but is more than a combination of both.
(*) The first example in the "SMP Barrier Pairing" section was wrong: the
loads around the read barrier need to touch the memory locations in the
opposite order to the stores around the write barrier.
(*) Added a note to make explicit that the loads should be in reverse order to
the stores.
(*) Adjusted the diagrams in the "Examples Of Memory Barrier Sequences"
section to make them clearer. Added a couple of diagrams to make it more
clear as to how it could go wrong without the barrier.
(*) Added a section on memory speculation.
(*) Dropped any references to memory allocation routines doing memory
barriers. They may do sometimes, but it can't be relied on. This may be
worthy of further documentation later.
(*) Made the fact that a LOCK followed by an UNLOCK should not be considered a
full memory barrier more explicit and gave an example.
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/filesystems')
0 files changed, 0 insertions, 0 deletions