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