From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
kernel-team@fb.com, mingo@kernel.org, parri.andrea@gmail.com,
will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com
Subject: Re: [PATCH memory-model 5/8] tools/memory-model: Add a glossary of LKMM terms
Date: Fri, 6 Nov 2020 15:40:08 -0500 [thread overview]
Message-ID: <20201106204008.GA55521@rowland.harvard.edu> (raw)
In-Reply-To: <20201106195912.GA3249@paulmck-ThinkPad-P72>
On Fri, Nov 06, 2020 at 11:59:12AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 06, 2020 at 02:23:51PM -0500, Alan Stern wrote:
> > On Fri, Nov 06, 2020 at 10:04:46AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 06, 2020 at 11:59:30AM -0500, Alan Stern wrote:
> > > > > + See also "Control Dependency".
> > > >
> > > > There should also be an entry for "Data Dependency", linked from here
> > > > and from Control Dependency.
> > > >
> > > > > +Marked Access: An access to a variable that uses an special function or
> > > > > + macro such as "r1 = READ_ONCE()" or "smp_store_release(&a, 1)".
> > > >
> > > > How about "r1 = READ_ONCE(x)"?
> > >
> > > Good catches! I am planning to squash the commit below into the
> > > original. Does that cover it?
> >
> > No, because you didn't add a glossary entry for "Data Dependency" and
> > there's no link from "Control Dependency" to "Data Dependency".
>
> Sigh. I was thinking "entry in the list", and didn't even thing to
> check for an entry in the glossary as a whole. With the patch below
> (on top of the one sent earlier), are we good?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 5a49c32551e83d30e304d6c3fbb660737ba2654e
> Author: Paul E. McKenney <paulmck@kernel.org>
> Date: Fri Nov 6 11:57:25 2020 -0800
>
> fixup! tools/memory-model: Add a glossary of LKMM terms
>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> diff --git a/tools/memory-model/Documentation/glossary.txt b/tools/memory-model/Documentation/glossary.txt
> index 471bf13..b2da636 100644
> --- a/tools/memory-model/Documentation/glossary.txt
> +++ b/tools/memory-model/Documentation/glossary.txt
> @@ -64,7 +64,7 @@ Control Dependency: When a later store's execution depends on a test
> fragile, and can be easily destroyed by optimizing compilers.
> Please see control-dependencies.txt for more information.
>
> - See also "Address Dependency".
> + See also "Address Dependency" and "Data Dependency".
>
> Cycle: Memory-barrier pairing is restricted to a pair of CPUs, as the
> name suggests. And in a great many cases, a pair of CPUs is all
> @@ -85,6 +85,23 @@ Cycle: Memory-barrier pairing is restricted to a pair of CPUs, as the
>
> See also "Pairing".
>
> +Data Dependency: When the data written by a later store is computed based
> + on the value returned by an earlier load, a "data dependency"
> + extends from that load to that later store. For example:
> +
> + 1 r1 = READ_ONCE(x);
> + 2 WRITE_ONCE(y, r1 + 1);
> +
> + In this case, the data dependency extends from the READ_ONCE()
> + on line 1 to the WRITE_ONCE() on line 2. Data dependencies are
> + fragile and can be easily destroyed by optimizing compilers.
> + Because optimizing compilers put a great deal of effort into
> + working out what values integer variables might have, this is
> + especially true in cases where the dependency is carried through
> + an integer.
> +
> + See also "Address Dependency" and "Control Dependency".
> +
> From-Reads (fr): When one CPU's store to a given variable happened
> too late to affect the value returned by another CPU's
> load from that same variable, there is said to be a from-reads
Yes, this is better.
Is it really true that data dependencies are so easily destroyed? I
would expect that a true "semantic" dependency (i.e., one where the
value written really does vary according to the value read) would be
rather hard to second guess.
Alan
next prev parent reply other threads:[~2020-11-06 20:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-05 21:59 [PATCH memory-model 0/8] LKMM updates for v5.11 Paul E. McKenney
2020-11-05 22:00 ` [PATCH memory-model 1/8] tools: memory-model: Document that the LKMM can easily miss control dependencies paulmck
2020-11-05 22:00 ` [PATCH memory-model 2/8] tools/memory-model: Move Documentation description to Documentation/README paulmck
2020-11-05 22:00 ` [PATCH memory-model 3/8] tools/memory-model: Document categories of ordering primitives paulmck
2020-11-06 16:56 ` Alan Stern
2020-11-06 19:11 ` Paul E. McKenney
2020-11-05 22:00 ` [PATCH memory-model 4/8] docs/memory-barriers.txt: Fix a typo in CPU MEMORY BARRIERS section paulmck
2020-11-05 22:00 ` [PATCH memory-model 5/8] tools/memory-model: Add a glossary of LKMM terms paulmck
2020-11-06 1:47 ` Boqun Feng
2020-11-06 18:01 ` Paul E. McKenney
2020-11-07 3:07 ` Boqun Feng
2020-11-06 16:59 ` Alan Stern
2020-11-06 18:04 ` Paul E. McKenney
2020-11-06 19:23 ` Alan Stern
2020-11-06 19:59 ` Paul E. McKenney
2020-11-06 20:40 ` Alan Stern [this message]
2020-11-06 21:04 ` Paul E. McKenney
2020-11-07 2:32 ` Alan Stern
2020-11-05 22:00 ` [PATCH memory-model 6/8] tools/memory-model: Add types to litmus tests paulmck
2020-11-05 22:41 ` Akira Yokosawa
2020-11-05 22:56 ` Paul E. McKenney
2020-11-25 11:34 ` Akira Yokosawa
2020-11-27 15:46 ` Paul E. McKenney
2020-11-28 5:56 ` Akira Yokosawa
2020-11-28 6:00 ` [PATCH 1/2] tools/memory-model: Remove redundant initialization in " Akira Yokosawa
2020-11-28 6:01 ` [PATCH 2/2] tools/memory-model: Fix typo in klitmus7 compatibility table Akira Yokosawa
2020-11-29 3:33 ` Paul E. McKenney
2020-11-05 22:00 ` [PATCH memory-model 7/8] tools/memory-model: Use "buf" and "flag" for message-passing tests paulmck
2020-11-05 22:00 ` [PATCH memory-model 8/8] tools/memory-model: Label MP tests' producers and consumers paulmck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201106204008.GA55521@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=kernel-team@fb.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).