renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-20 11:13:58 +08:00
Code

tools/memory-model: Remove smp_read_barrier_depends() from informal doc

Browse Source 
smp_read_barrier_depends() has gone the way of mmiowb() and so many
esoteric memory barriers before it. Drop the two mentions of this
deceased barrier from the LKMM informal explanation document.

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
This commit is contained in:
Will Deacon 2019-11-07 14:44:06 +00:00
parent 9ce1b14e74
commit 628fd55671
1 changed files with 12 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
tools/memory-model/Documentation/explanation.txt
View File

@ -1122,12 +1122,10 @@ maintain at least the appearance of FIFO order.
In practice, this difficulty is solved by inserting a special fence
between P1's two loads when the kernel is compiled for the Alpha
architecture. In fact, as of version 4.15, the kernel automatically
adds this fence (called smp_read_barrier_depends() and defined as
nothing at all on non-Alpha builds) after every READ_ONCE() and atomic
load. The effect of the fence is to cause the CPU not to execute any
po-later instructions until after the local cache has finished
processing all the stores it has already received. Thus, if the code
was changed to:
adds this fence after every READ_ONCE() and atomic load on Alpha. The
effect of the fence is to cause the CPU not to execute any po-later
instructions until after the local cache has finished processing all
the stores it has already received. Thus, if the code was changed to:
P1()
{
@ -1146,14 +1144,14 @@ READ_ONCE() or another synchronization primitive rather than accessed
directly.
The LKMM requires that smp_rmb(), acquire fences, and strong fences
share this property with smp_read_barrier_depends(): They do not allow
the CPU to execute any po-later instructions (or po-later loads in the
case of smp_rmb()) until all outstanding stores have been processed by
the local cache. In the case of a strong fence, the CPU first has to
wait for all of its po-earlier stores to propagate to every other CPU
in the system; then it has to wait for the local cache to process all
the stores received as of that time -- not just the stores received
when the strong fence began.
share this property: They do not allow the CPU to execute any po-later
instructions (or po-later loads in the case of smp_rmb()) until all
outstanding stores have been processed by the local cache. In the
case of a strong fence, the CPU first has to wait for all of its
po-earlier stores to propagate to every other CPU in the system; then
it has to wait for the local cache to process all the stores received
as of that time -- not just the stores received when the strong fence
began.
And of course, none of this matters for any architecture other than
Alpha.