Messages in this thread | | | Subject | Re: data dependency naming inconsistency | From | Akira Yokosawa <> | Date | Thu, 14 Oct 2021 13:43:24 +0900 |
| |
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
| |