linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul Heidekrüger" <paul.heidekrueger@in.tum.de>
Cc: Andrea Parri <parri.andrea@gmail.com>,
	Will Deacon <will@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Boqun Feng <boqun.feng@gmail.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	David Howells <dhowells@redhat.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	Luc Maranget <luc.maranget@inria.fr>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Akira Yokosawa <akiyks@gmail.com>,
	Daniel Lustig <dlustig@nvidia.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Marco Elver <elver@google.com>
Subject: Re: (Non-) Ctrl Dependency in litmus-tests.txt?
Date: Fri, 3 Jun 2022 10:48:14 -0400	[thread overview]
Message-ID: <YpofLjYu5W0yI2uE@rowland.harvard.edu> (raw)
In-Reply-To: <YpoW1deb/QeeszO1@ethstick13.dse.in.tum.de>

On Fri, Jun 03, 2022 at 04:12:37PM +0200, Paul Heidekrüger wrote:
> Hi all,
> 
> I was going through litmus-tests.txt and came across the following:
> 
> > LIMITATIONS
> > ===========
> > 
> > Limitations of the Linux-kernel memory model (LKMM) include:
> > 
> > 1.Compiler optimizations are not accurately modeled.  Of course,
> > 	the use of READ_ONCE() and WRITE_ONCE() limits the compiler's
> > 	ability to optimize, but under some circumstances it is possible
> > 	for the compiler to undermine the memory model.  For more
> > 	information, see Documentation/explanation.txt (in particular,
> > 	the "THE PROGRAM ORDER RELATION: po AND po-loc" and "A WARNING"
> > 	sections).
> > 
> > 	Note that this limitation in turn limits LKMM's ability to
> > 	accurately model address, control, and data dependencies.
> > 	For example, if the compiler can deduce the value of some variable
> > 	carrying a dependency, then the compiler can break that dependency
> > 	by substituting a constant of that value.
> > 
> > 	Conversely, LKMM sometimes doesn't recognize that a particular
> > 	optimization is not allowed, and as a result, thinks that a
> > 	dependency is not present (because the optimization would break it).
> > 	The memory model misses some pretty obvious control dependencies
> > 	because of this limitation.  A simple example is:
> > 
> > 		r1 = READ_ONCE(x);
> > 		if (r1 == 0)
> > 			smp_mb();
> > 		WRITE_ONCE(y, 1);
> > 
> > 	There is a control dependency from the READ_ONCE to the WRITE_ONCE,
> > 	even when r1 is nonzero, but LKMM doesn't realize this and thinks
> > 	that the write may execute before the read if r1 != 0.  (Yes, that
> > 	doesn't make sense if you think about it, but the memory model's
> > 	intelligence is limited.)
> 
> I'm unclear as to why the documentation sees a control dependency from
> the READ_ONCE() to the WRITE_ONCE() here.
> 
> Quoting from explanation.txt:
> > Finally, a read event and another memory access event are linked by a
> > control dependency if the value obtained by the read affects whether
> > the second event is executed at all.
> 
> Architectures might consider this control-dependent, yes, but since the
> value of the if condition does not affect whether the WRITE_ONCE() is
> executed at all, I'm not sure why this should be considered
> control-dependent in LKMM? 
> 
> I might have another question about explanation.txt's definition of
> control dependencies as per above, but will address it more thoroughly
> in another email :-)

You're right; strictly speaking this isn't a control dependency.  In 
fact it's not a dependency at all, just an ordering restriction that's 
connected with a conditional test.

If you would like to submit a patch updating the text, please feel free 
to do so.

Alan

      reply	other threads:[~2022-06-03 14:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03 14:12 (Non-) Ctrl Dependency in litmus-tests.txt? Paul Heidekrüger
2022-06-03 14:48 ` Alan Stern [this message]

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=YpofLjYu5W0yI2uE@rowland.harvard.edu \
    --to=stern@rowland.harvard.edu \
    --cc=akiyks@gmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=elver@google.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paul.heidekrueger@in.tum.de \
    --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).