'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.
Signed-off-by: Will Deacon <[email protected]>
---
.../Documentation/explanation.txt | 26 +++++++++----------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
index 488f11f6c588..3050bf67b8d0 100644
--- a/tools/memory-model/Documentation/explanation.txt
+++ b/tools/memory-model/Documentation/explanation.txt
@@ -1118,12 +1118,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()
{
@@ -1142,14 +1140,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.
--
2.24.0.rc1.363.gb1bccd3e3d-goog
On Fri, 8 Nov 2019, Will Deacon wrote:
> '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.
>
> Signed-off-by: Will Deacon <[email protected]>
> ---
> .../Documentation/explanation.txt | 26 +++++++++----------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/tools/memory-model/Documentation/explanation.txt b/tools/memory-model/Documentation/explanation.txt
> index 488f11f6c588..3050bf67b8d0 100644
> --- a/tools/memory-model/Documentation/explanation.txt
> +++ b/tools/memory-model/Documentation/explanation.txt
> @@ -1118,12 +1118,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()
> {
> @@ -1142,14 +1140,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.
Acked-by: Alan Stern <[email protected]>