lkml.org 
[lkml]   [2020]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH v3 12/19] tools/memory-model: Remove smp_read_barrier_depends() from informal doc
    Date
    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: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Paul E. McKenney <paulmck@kernel.org>
    Signed-off-by: Will Deacon <will@kernel.org>
    ---
    .../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 e91a2eb19592..01adf9e0ebac 100644
    --- a/tools/memory-model/Documentation/explanation.txt
    +++ b/tools/memory-model/Documentation/explanation.txt
    @@ -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.
    --
    2.27.0.383.g050319c2ae-goog
    \
     
     \ /
      Last update: 2020-07-10 18:54    [W:2.377 / U:0.284 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site