lkml.org 
[lkml]   [2021]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: data dependency naming inconsistency
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
> >>

\
 
 \ /
  Last update: 2021-10-15 01:07    [W:0.063 / U:26.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site