Re: [PATCH memory-model] docs: memory-barriers: Add note on compiler transformation and address deps

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 10/19/2023 um 6:39 PM schrieb Paul E. McKenney:
On Wed, Oct 18, 2023 at 12:11:58PM +0200, Jonas Oberhauser wrote:
Hi Paul,
[...]
The compiler is forbidden from inventing pointer comparisons.

TIL :) Btw, do you remember a discussion where this is clarified? A quick search didn't turn up anything.


Best wishes,

jonas

Am 10/6/2023 um 6:39 PM schrieb Jonas Oberhauser:
Hi Paul,

The "more up-to-date information" makes it sound like (some of) the
information in this section is out-of-date/no longer valid.
The old smp_read_barrier_depends() that these section cover really
does no longer exist.


You mean that they *intend to* cover? smp_read_barrier_depends never appears in the text, so anyone reading this section without prior knowledge has no way of realizing that this is what the sections are talking about.

On the other hand the implicit address dependency barriers that do exist are mentioned in the text. And that part is still true.



But after reading the sections, it seems the information is valid, but
discusses mostly the history of address dependency barriers.

Given that the sepcond part  specifically already starts with a
disclaimer that this information is purely relevant to people interested
in history or working on alpha, I think it would make more sense to
modify things slightly differently.

Firstly I'd remove the "historical" part in the first section, and add
two short paragraphs explaining that

- every marked access implies a address dependency barrier
This is covered in rcu_dereference.rst.

Let me quote a much wiser man than myself here: "

The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense.  ;-)

"

The main reason I would like to add this here at the very top is that

- this section serves to frigthen children about the dangers of address dependencies,

- never mentions a way to add them - I need to happen to read another section of the manual to find that out

- and says this information is historical without specifying which parts are still relevant

(and the parts that are still there are all still relevant, while the parts that only the authors know was intended to be there and is out-of-date is already gone).

So I would add a disclaimer specifying that (since 4.15) *all* marked accesses imply read dependency barriers which resolve most of the issues mentioned in the remainder of the article. However, some issues remain because the dependencies that are preserved by such barriers are just *semantic* dependencies, and readers should check rcu_dereference.rst for examples of what that implies.


[...]
most situations would be better served by an _acquire() suffix than by
a relaxed version of [...] an atomic [...]


I completely agree. I even considered removing address dependencies altogether from the company-internal memory models.
But people sometimes get a little bit angry and start asking many questions.
The valuable time of the model maintainer should be considered when designing memory models.



- address dependencies considered by the model are *semantic*
dependencies, meaning that a *syntactic* dependency is not sufficient to
imply ordering; see the rcu file for some examples where compilers can
elide syntactic dependencies
There is a bunch of text in rcu_dereference.rst to this effect.  Or
is there some aspect that is missing from that document?


That's what I meant by "see the rcu file" --- include a link to rcu_dereference.rst in that paragraph. So that people know to check out rcu_dereference.rst for more explanations to this effect.


The longer-term direction, perhaps a few years from now, is for the
first section to simply reference rcu_dereference.rst and for the second
section to be removed completely.


Sounds good to me, but that doesn't mean we need to compromise the readability in the interim :)



[...]
The problem is that people insist on diving into the middle of documents,
so sometimes repetition is a necessary form of self defense.  ;-)

But I very much appreciate your review and feedback, and I also apologize
for my slowness.

							Thanx, Paul


Thanks for the response, I started thinking my mails aren't getting through again.

Have fun,

jonas





[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux