Message-ID: <d253958f-b3d7-67c1-4cf6-38f184adabd6@gmail.com>
Date:   Thu, 14 Oct 2021 23:29:43 +0900
From:   Akira Yokosawa <akiyks@...il.com>
To:     "Michael S. Tsirkin" <mst@...hat.com>
Cc:     linux-kernel@...r.kernel.org, paulmck@...ux.ibm.com,
        Akira Yokosawa <akiyks@...il.com>
Subject: Re: data dependency naming inconsistency

[-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.
>> 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
> 

Powered by blists - more mailing lists