Sad to say, current compilers really will hoist identical stores from both
branches of an "if" statement to precede the conditional. This commit
therefore updates the description of control dependencies to reflect this
ugly reality.
Reported-by: Pranith Kumar <bobby.prani@gmail.com>
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
The transformation in the fold-to-zero example incorrectly omits the
barrier() directive. This commit therefore adds it back in.
Reported-by: Pranith Kumar <pranith@gatech.edu>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
It is possible to pair acquire and release barriers with other barriers,
so this commit adds them to the list in the SMP barrier pairing section.
Reported-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
[ paulmck: Updated pairing discussion as suggested by Peter Zijlstra. ]
Examples introducing neccesity of RMB+WMP pair reads as
A=3 READ B
www rrrrrr
B=4 READ A
Note the opposite order of reads vs writes.
But the first example without barriers reads as
A=3 READ A
B=4 READ B
There are 4 outcomes in the first example.
But if someone new to the concept tries to insert barriers like this:
A=3 READ A
www rrrrrr
B=4 READ B
he will still get all 4 possible outcomes, because "READ A" is first.
All this can be utterly confusing because barrier pair seems to be
superfluous. In short, fixup first example to match latter examples
with barriers.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix double words "the the" in various files
within Documentations.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Current compilers can "speculate" stores in the case where both legs
of the "if" statement start with identical stores. Because the stores
are identical, the compiler knows that the store will unconditionally
execute regardless of the "if" condition, and so the compiler is within
its rights to hoist the store to precede the condition. Such hoisting
destroys the control-dependency ordering. This ordering can be restored
by placing a barrier() at the beginning of each leg of the "if" statement.
This commit adds this requirement to the control-dependencies section.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
A control dependency consists of a load, a conditional that depends on
that load, and a store. This commit emphasizes this point in the
summary.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
The ACCESS_ONCE() primitive provides cache coherence, but the
documentation does not clearly state this. This commit therefore upgrades
the documentation.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Each control-dependency example needs its barriers between the "if"
condition and the body of the "if" because a control dependency is
a dependency induced by a branch. This commit makes the needed
adjustment.
Reported-by: Yongming Shen <symingz@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
This commit fixes a broken example of overlapping stores in the
Documentation/memory-barriers.txt file.
Reported-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
There are numerous broken references to Documentation files (in other
Documentation files, in comments, etc.). These broken references are
caused by typo's in the references, and by renames or removals of the
Documentation files. Some broken references are simply odd.
Fix these broken references, sometimes by dropping the irrelevant text
they were part of.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>