summaryrefslogtreecommitdiffstats
path: root/Documentation/memory-barriers.txt
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2016-04-12 11:52:49 -0400
committerIngo Molnar <mingo@kernel.org>2016-04-13 02:52:21 -0400
commita5052657c164107032d521f0d9e92703d78845f2 (patch)
tree3f9ed953ae89b091ddca52a14bb1e4bcc21a6b9b /Documentation/memory-barriers.txt
parent5c8a010c2411729a07cb1b90c09fa978ac0ac6c0 (diff)
locking/Documentation: Clarify relationship of barrier() to control dependencies
The current documentation claims that the compiler ignores barrier(), which is not the case. Instead, the compiler carefully pays attention to barrier(), but in a creative way that still manages to destroy the control dependency. This commit sets the story straight. Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: bobby.prani@gmail.com Cc: dhowells@redhat.com Cc: dipankar@in.ibm.com Cc: dvhart@linux.intel.com Cc: edumazet@google.com Cc: fweisbec@gmail.com Cc: jiangshanlai@gmail.com Cc: josh@joshtriplett.org Cc: oleg@redhat.com Cc: rostedt@goodmis.org Link: http://lkml.kernel.org/r/1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'Documentation/memory-barriers.txt')
-rw-r--r--Documentation/memory-barriers.txt7
1 files changed, 4 insertions, 3 deletions
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 3729cbe60e41..ec1289042396 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -813,9 +813,10 @@ In summary:
813 the same variable, then those stores must be ordered, either by 813 the same variable, then those stores must be ordered, either by
814 preceding both of them with smp_mb() or by using smp_store_release() 814 preceding both of them with smp_mb() or by using smp_store_release()
815 to carry out the stores. Please note that it is -not- sufficient 815 to carry out the stores. Please note that it is -not- sufficient
816 to use barrier() at beginning of each leg of the "if" statement, 816 to use barrier() at beginning of each leg of the "if" statement
817 as optimizing compilers do not necessarily respect barrier() 817 because, as shown by the example above, optimizing compilers can
818 in this case. 818 destroy the control dependency while respecting the letter of the
819 barrier() law.
819 820
820 (*) Control dependencies require at least one run-time conditional 821 (*) Control dependencies require at least one run-time conditional
821 between the prior load and the subsequent store, and this 822 between the prior load and the subsequent store, and this