Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: data dependency naming inconsistency
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     linux-kernel@vger.kernel.org,
        "Michael S. Tsirkin" <mst@redhat.com>,
        Akira Yokosawa <akiyks@gmail.com>
References: <20211011064233-mutt-send-email-mst@kernel.org>
 <6c362de5-1d79-512c-37d0-81aaf5d335d1@qa2.so-net.ne.jp>
 <20211014013156-mutt-send-email-mst@kernel.org>
 <d253958f-b3d7-67c1-4cf6-38f184adabd6@gmail.com>
From:   Akira Yokosawa <akiyks@gmail.com>
Message-ID: <8a9ea500-8f8c-129a-2974-4bdda65dbf64@gmail.com>
Date:   Fri, 15 Oct 2021 07:48:09 +0900
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <d253958f-b3d7-67c1-4cf6-38f184adabd6@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Thu, 14 Oct 2021 23:29:43 +0900, Akira Yokosawa wrote:
> [-CC akys: my 2nd address]
> On Thu, 14 Oct 2021 01:37:17 -0400, Michael S. Tsirkin wrote:
>> On Thu, Oct 14, 2021 at 01:43:24PM +0900, Akira Yokosawa wrote:
>>> On Mon, 11 Oct 2021 07:07:08 -0400, Michael S. Tsirkin wrote:
>>>> Hello Paul, all!
>>>
>>> Hello Michael,
>>>
>>> I thought Paul would respond soon, but looks like he has not
>>> done so.

This is because Michael used Paul's old email address.

Forwarding to his current address.

Paul, you can see the thread at the lore archive:
https://lore.kernel.org/lkml/20211011064233-mutt-send-email-mst@kernel.org/T/

        Thanks, Akira

>>> So, I'm trying to give some hint to your findings.
>>>
>>>> I've been reading with interest Paul's posts about Rust interactions with LKMM
>>>> https://paulmck.livejournal.com/63316.html
>>>> and in particular it states:
>>>> 		A data dependency involves a load whose return value directly or
>>>> 	indirectly determine the value stored by a later store, which results in
>>>> 	the load being ordered before the store.
>>>>
>>>> This matches the perf book:
>>>> 	A data dependency occurs when the value returned by
>>>> 	a load instruction is used to compute the data stored by
>>>> 	a later store instruction.
>>>
>>> You might likely be aware, but these concern "data dependency",
>>> not a _barrier_.
>>>
>>>>
>>>> however, memory-barriers.txt states:
>>>>
>>>>      A data dependency barrier is a partial ordering on interdependent loads
>>>>      only; it is not required to have any effect on stores, independent loads
>>>>      or overlapping loads.
>>>>
>>>> It also says:
>>>> 	A data-dependency barrier is not required to order dependent writes
>>>> 	because the CPUs that the Linux kernel supports don't do writes
>>>> 	until they are certain (1) that the write will actually happen, (2)
>>>> 	of the location of the write, and (3) of the value to be written.
>>>
>>> These concern the historic "data-dependency barrier", or
>>> [smp_]read_barrier_depends(), which existed until Linux kernel v4.14.
> 
> Ah... I should have said ", which existed prior to Linux kernel v4.15".
> This invited off-by-one error below...
> 
>>>
>>>>
>>>> so the result it the same: writes are ordered without a barrier,
>>>> reads are ordered by a barrier.
>>>>
>>>> However, it would seem that a bit more consistency in naming won't
>>>> hurt.
>>>
>>> So, I don't think the historic term of "data-dependency barrier"
>>> can be changed.
>>>
>>> I guess the right approach would be to further de-emphasize
>>> "data-dependency barrier"/"data dependency barrier" in
>>> memory-barriers.txt.
>>>
>>> Rewrite by commit 8ca924aeb4f2 ("Documentation/barriers: Remove
>>> references to [smp_]read_barrier_depends()") did some of such
>>> changes, but it failed to update the introductory section of
>>> "VARIETIES OF MEMORY BARRIER".
>>> The part Michael quoted above belongs to it.
>>> I don't think it has any merit keeping it around.
>>>
>>> Also, there remain a couple of ascii-art diagrams concerning
>>> <data dependency barrier> in the first part of "EXAMPLES OF MEMORY
>>> BARRIER SEQUENCES" section, which, I think, can be removed as well.
>>>
>>> Hope this helps clarify the circumstances.
>>
>> It does, thanks! It might be worth adding a sentence along the lines of
>>
>> "NB: a data dependency barrier is distinct from a data dependency: it's
>> a barrier that used to be required in the presence of a data dependency.
>> Since v4.14 Linux no longer offers an API for a data dependency barrier.
> 
>   Since v4.15
> 
>> Instead, using READ_ONCE is sufficient for ordering in the presence of a
>> data dependency".
> 
> 
> Maybe.
> 
> But I'm more inclined to get rid of remaining contents related to the
> "data dependency barrier".
> 
>         Thanks, Akira
> 
>>
>>
>>> Paul, what is your take on the naming of "data dependency"/
>>> "data dependency barrier"?
>>>
>>>         Thanks, Akira
>>>
>>>>
>>>> Thanks,
>>>>
>>>> -- 
>>>> MST
>>