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

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