Messages in this thread | | | Date | Thu, 14 Oct 2021 01:37:17 -0400 | From | "Michael S. Tsirkin" <> | Subject | Re: 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
| |