From: Boqun Feng <boqun.feng@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: "Paul E. McKenney" <paulmck@kernel.org>,
"Björn Töpel" <bjorn.topel@gmail.com>, bpf <bpf@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
parri.andrea@gmail.com, "Will Deacon" <will@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, akiyks@gmail.com, dlustig@nvidia.com,
joel@joelfernandes.org,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>
Subject: Re: XDP socket rings, and LKMM litmus tests
Date: Fri, 5 Mar 2021 09:12:30 +0800 [thread overview]
Message-ID: <YEGFfjmOYfbuir9o@boqun-archlinux> (raw)
In-Reply-To: <20210304161142.GB1612307@rowland.harvard.edu>
On Thu, Mar 04, 2021 at 11:11:42AM -0500, Alan Stern wrote:
> On Thu, Mar 04, 2021 at 02:33:32PM +0800, Boqun Feng wrote:
>
> > Right, I was thinking about something unrelated.. but how about the
> > following case:
> >
> > local_v = &y;
> > r1 = READ_ONCE(*x); // f
> >
> > if (r1 == 1) {
> > local_v = &y; // e
> > } else {
> > local_v = &z; // d
> > }
> >
> > p = READ_ONCE(local_v); // g
> >
> > r2 = READ_ONCE(*p); // h
> >
> > if r1 == 1, we definitely think we have:
> >
> > f ->ctrl e ->rfi g ->addr h
> >
> > , and if we treat ctrl;rfi as "to-r", then we have "f" happens before
> > "h". However compile can optimze the above as:
> >
> > local_v = &y;
> >
> > r1 = READ_ONCE(*x); // f
> >
> > if (r1 != 1) {
> > local_v = &z; // d
> > }
> >
> > p = READ_ONCE(local_v); // g
> >
> > r2 = READ_ONCE(*p); // h
> >
> > , and when this gets executed, I don't think we have the guarantee we
> > have "f" happens before "h", because CPU can do optimistic read for "g"
> > and "h".
>
> In your example, which accesses are supposed to be to actual memory and
> which to registers? Also, remember that the memory model assumes the
Given that we use READ_ONCE() on local_v, local_v should be a memory
location but only accessed by this thread.
> hardware does not reorder loads if there is an address dependency
> between them.
>
Right, so "g" won't be reordered after "h".
> > Part of this is because when we take plain access into consideration, we
> > won't guarantee a read-from or other relations exists if compiler
> > optimization happens.
> >
> > Maybe I'm missing something subtle, but just try to think through the
> > effect of making dep; rfi as "to-r".
>
> Forget about local variables for the time being and just consider
>
> dep ; [Plain] ; rfi
>
> For example:
>
> A: r1 = READ_ONCE(x);
> y = r1;
> B: r2 = READ_ONCE(y);
>
> Should B be ordered after A? I don't see how any CPU could hope to
> excute B before A, but maybe I'm missing something.
>
Agreed.
> There's another twist, connected with the fact that herd7 can't detect
> control dependencies caused by unexecuted code. If we have:
>
> A: r1 = READ_ONCE(x);
> if (r1)
> WRITE_ONCE(y, 5);
> r2 = READ_ONCE(y);
> B: WRITE_ONCE(z, r2);
>
> then in executions where x == 0, herd7 doesn't see any control
> dependency. But CPUs do see control dependencies whenever there is a
> conditional branch, whether the branch is taken or not, and so they will
> never reorder B before A.
>
Right, because B in this example is a write, what if B is a read that
depends on r2, like in my example? Let y be a pointer to a memory
location, and initialized as a valid value (pointing to a valid memory
location) you example changed to:
A: r1 = READ_ONCE(x);
if (r1)
WRITE_ONCE(y, 5);
C: r2 = READ_ONCE(y);
B: r3 = READ_ONCE(*r2);
, then A don't have the control dependency to B, because A and B is
read+read. So B can be ordered before A, right?
> One last thing to think about: My original assessment or Björn's problem
> wasn't right, because the dep in (dep ; rfi) doesn't include control
> dependencies. Only data and address. So I believe that the LKMM
Ah, right. I was mising that part (ctrl is not in dep). So I guess my
example is pointless for the question we are discussing here ;-(
> wouldn't consider A to be ordered before B in this example even if x
> was nonzero.
Yes, and similar to my example (changing B to a read).
I did try to run my example with herd, and got confused no matter I make
dep; [Plain]; rfi as to-r (I got the same result telling me a reorder
can happen). Now the reason is clear, because this is a ctrl; rfi not a
dep; rfi.
Thanks so much for walking with me on this ;-)
Regards,
Boqun
>
> Alan
next prev parent reply other threads:[~2021-03-05 1:13 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 18:46 XDP socket rings, and LKMM litmus tests Björn Töpel
2021-03-02 19:57 ` Paul E. McKenney
2021-03-02 20:04 ` Paul E. McKenney
2021-03-02 20:37 ` Björn Töpel
2021-03-02 20:24 ` Björn Töpel
2021-03-02 20:41 ` Paul E. McKenney
2021-03-02 20:51 ` Björn Töpel
2021-03-02 21:14 ` Alan Stern
2021-03-02 23:50 ` Paul E. McKenney
2021-03-03 6:37 ` maranget
2021-03-03 16:54 ` Paul E. McKenney
2021-03-03 17:12 ` Alan Stern
2021-03-03 17:37 ` maranget
2021-03-03 17:39 ` maranget
2021-03-03 21:56 ` Paul E. McKenney
2021-03-03 19:40 ` Alan Stern
2021-03-03 17:40 ` Paul E. McKenney
2021-03-03 20:22 ` Alan Stern
2021-03-03 22:03 ` Paul E. McKenney
2021-03-04 3:21 ` Alan Stern
2021-03-04 5:04 ` Paul E. McKenney
2021-03-04 15:35 ` Alan Stern
2021-03-04 19:05 ` Paul E. McKenney
2021-03-04 21:27 ` Alan Stern
2021-03-04 22:05 ` Paul E. McKenney
2021-03-04 1:26 ` Boqun Feng
2021-03-04 3:13 ` Alan Stern
2021-03-04 6:33 ` Boqun Feng
2021-03-04 16:11 ` Alan Stern
2021-03-05 1:12 ` Boqun Feng [this message]
2021-03-05 16:15 ` Alan Stern
2021-03-04 15:44 ` maranget
2021-03-04 19:07 ` Paul E. McKenney
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=YEGFfjmOYfbuir9o@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=akiyks@gmail.com \
--cc=bjorn.topel@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=magnus.karlsson@intel.com \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=toke@redhat.com \
--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).