aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
Commit message (Collapse)AuthorAge
* [PATCH] Fix typos in Documentation/memory-barriers.txtAneesh Kumar2006-05-15
| | | | | | | | | Fix some typos in Documentation/memory-barriers.txt Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Improve data-dependency memory barrier example in documentationDavid Howells2006-04-11
| | | | | | | | | | | | | | | In the memory barrier document, improve the example of the data dependency barrier situation by: (1) showing the initial values of the variables involved; and (2) repeating the instruction sequence description, this time with the data dependency barrier actually shown to make it clear what the revised sequence actually is. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix memory barrier docs wrt atomic opsDavid Howells2006-04-11
| | | | | | | | | | | | | | | | | | | | | Fix the memory barrier documentation to attempt to describe atomic ops correctly. atomic_t ops that return a value _do_ imply smp_mb() either side, and so don't actually require smp_mb__*_atomic_*() special barriers. Also explains why special barriers exist in addition to normal barriers. Further fix the memory barrier documents to portray bitwise operation memory barrier effects correctly following Nick Piggin's comments. It makes the point that any atomic op that both modifies some state in memory and returns information on that state implies memory barriers on both sides. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Document Linux's memory barriers [try #7]David Howells2006-03-31
The attached patch documents the Linux kernel's memory barriers. I've updated it from the comments I've been given. The per-arch notes sections are gone because it's clear that there are so many exceptions, that it's not worth having them. I've added a list of references to other documents. I've tried to get rid of the concept of memory accesses appearing on the bus; what matters is apparent behaviour with respect to other observers in the system. Interrupts barrier effects are now considered to be non-existent. They may be there, but you may not rely on them. I've added a couple of definition sections at the top of the document: one to specify the minimum execution model that may be assumed, the other to specify what this document refers to by the term "memory". I've made greater mention of the use of mmiowb(). I've adjusted the way in which caches are described, and described the fun that can be had with cache coherence maintenance being unordered and data dependency not being necessarily implicit. I've described (smp_)read_barrier_depends(). I've rearranged the order of the sections, so that memory barriers are discussed in abstract first, and then described the memory barrier facilities available on Linux, before going on to more real-world discussions and examples. I've added information about the lack of memory barriering effects with atomic ops and bitops. I've added information about control dependencies. I've added more diagrams to illustrate caching interactions between CPUs. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>