* data dependency naming inconsistency
@ 2021-10-11 11:07 Michael S. Tsirkin
2021-10-14 4:43 ` Akira Yokosawa
0 siblings, 1 reply; 7+ messages in thread
From: Michael S. Tsirkin @ 2021-10-11 11:07 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul E. McKenney
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: data dependency naming inconsistency 2021-10-11 11:07 data dependency naming inconsistency Michael S. Tsirkin @ 2021-10-14 4:43 ` Akira Yokosawa 2021-10-14 5:37 ` Michael S. Tsirkin 0 siblings, 1 reply; 7+ messages in thread From: Akira Yokosawa @ 2021-10-14 4:43 UTC (permalink / raw) To: mst; +Cc: linux-kernel, paulmck, 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: data dependency naming inconsistency 2021-10-14 4:43 ` Akira Yokosawa @ 2021-10-14 5:37 ` Michael S. Tsirkin 2021-10-14 14:29 ` Akira Yokosawa 0 siblings, 1 reply; 7+ messages in thread From: Michael S. Tsirkin @ 2021-10-14 5:37 UTC (permalink / raw) To: Akira Yokosawa; +Cc: linux-kernel, paulmck, Akira Yokosawa 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: data dependency naming inconsistency 2021-10-14 5:37 ` Michael S. Tsirkin @ 2021-10-14 14:29 ` Akira Yokosawa 2021-10-14 16:06 ` Michael S. Tsirkin 2021-10-14 22:48 ` Akira Yokosawa 0 siblings, 2 replies; 7+ messages in thread From: Akira Yokosawa @ 2021-10-14 14:29 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: linux-kernel, paulmck, 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: data dependency naming inconsistency 2021-10-14 14:29 ` Akira Yokosawa @ 2021-10-14 16:06 ` Michael S. Tsirkin 2021-10-14 22:48 ` Akira Yokosawa 1 sibling, 0 replies; 7+ messages in thread From: Michael S. Tsirkin @ 2021-10-14 16:06 UTC (permalink / raw) To: Akira Yokosawa; +Cc: linux-kernel, paulmck > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: data dependency naming inconsistency 2021-10-14 14:29 ` Akira Yokosawa 2021-10-14 16:06 ` Michael S. Tsirkin @ 2021-10-14 22:48 ` Akira Yokosawa 2021-10-14 23:06 ` Paul E. McKenney 1 sibling, 1 reply; 7+ messages in thread From: Akira Yokosawa @ 2021-10-14 22:48 UTC (permalink / raw) To: Paul E. McKenney; +Cc: linux-kernel, Michael S. Tsirkin, 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 >> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: data dependency naming inconsistency 2021-10-14 22:48 ` Akira Yokosawa @ 2021-10-14 23:06 ` Paul E. McKenney 0 siblings, 0 replies; 7+ messages in thread From: Paul E. McKenney @ 2021-10-14 23:06 UTC (permalink / raw) To: Akira Yokosawa; +Cc: linux-kernel, Michael S. Tsirkin 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 > >> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-10-14 23:06 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-11 11:07 data dependency naming inconsistency Michael S. Tsirkin 2021-10-14 4:43 ` Akira Yokosawa 2021-10-14 5:37 ` Michael S. Tsirkin 2021-10-14 14:29 ` Akira Yokosawa 2021-10-14 16:06 ` Michael S. Tsirkin 2021-10-14 22:48 ` Akira Yokosawa 2021-10-14 23:06 ` Paul E. McKenney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).