data dependency naming inconsistency

data dependency naming inconsistency

[Michael S. Tsirkin]

Hello Paul, all!
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.

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.

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.

Thanks,

-- 
MST

Re: data dependency naming inconsistency

[Akira Yokosawa]

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.

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

Paul, what is your take on the naming of "data dependency"/
"data dependency barrier"?

        Thanks, Akira

> 
> Thanks,
> 
> -- 
> MST

Re: data dependency naming inconsistency

[Michael S. Tsirkin]

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.
> 
> > 
> > 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.
Instead, using READ_ONCE is sufficient for ordering in the presence of a
data dependency".


> Paul, what is your take on the naming of "data dependency"/
> "data dependency barrier"?
> 
>         Thanks, Akira
> 
> > 
> > Thanks,
> > 
> > -- 
> > MST

Re: data dependency naming inconsistency

[Akira Yokosawa]

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

Re: data dependency naming inconsistency

[Michael S. Tsirkin]

> But I'm more inclined to get rid of remaining contents related to the
> "data dependency barrier".
> 
>         Thanks, Akira

That's an option, too.

-- 
MST

Re: data dependency naming inconsistency

[Akira Yokosawa]

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

Re: data dependency naming inconsistency

[Paul E. McKenney]

On Fri, Oct 15, 2021 at 07:48:09AM +0900, Akira Yokosawa wrote:
> 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.

Indeed, my ibm.com email addresses died about two years ago.

> 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/

And thank you for forwarding this.

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

As noted by others, the difference is that the first two are about a
data dependency, that is a prior load affecting the value stored by
a later store.  In contrast, the last one is about a data-dependency
barrier, which need only affect trailing loads.  Trailing stores are
already covered by control dependencies.  But clearer wording might
be good.  Suggestions?

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

Given that we don't seem to have any more data-dependency barriers,
so getting rid of remaining mentions makes a lot of sense to me.

							Thanx, Paul

> >         Thanks, Akira
> > 
> >>
> >>
> >>> Paul, what is your take on the naming of "data dependency"/
> >>> "data dependency barrier"?
> >>>
> >>>         Thanks, Akira
> >>>
> >>>>
> >>>> Thanks,
> >>>>
> >>>> -- 
> >>>> MST
> >>