lkml.org 
[lkml]   [2018]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: LKMM litmus test for Roman Penyaev's rcu-rr
On Tue, May 29, 2018 at 04:10:02PM -0500, Linus Torvalds wrote:
> On Tue, May 29, 2018 at 3:49 PM Alan Stern <stern@rowland.harvard.edu>
> wrote:
>
> > Putting this into herd would be extremely difficult, if not impossible,
> > because it involves analyzing code that was not executed.

One (ugly) way to handle it, assuming we are correct about what it
happening, would be to place ordering on the other side of the "if"
that is at least as strong as on the first side. Probably some example
that completely breaks this approach, though...

> Does it?
>
> Can't we simplify the whole sequence as basically
>
> A
> if (!B)
> D
>
> for that "not B" case, and just think about that. IOW, let's ignore the
> whole "not executed" code.
>
> If B depends on A like you state, then that already implies that the write
> in D cannot come before the read of A.
>
> You fundamentally cannot do a conditional write before the read that the
> write condition depends on. So *any* write after a conditional is dependent
> on the read.
>
> So the existence of C - whether it has a barrier or not - is entirely
> immaterial at run-time.
>
> Now, the *compiler* can use the whole existence of that memory barrier in C
> to determine whether it can re-order the write to D or not, of course, but
> that's a separate issue, and then the whole "code that isn't executed" is
> not the issue any more. The compiler obviously sees all code, whether
> executing or not.
>
> Or am I being stupid and missing something entirely? That's possible.

This will take some analysis, both to make sure that I got Roman's
example correct and to get to the bottom of exactly what LKMM thinks
can be reordered. I am shifting timezones eastward, so I am not going
to dig into it today.

But here are a couple of things that take some getting used to:

1. The "if (r1 == x)" would likely be "if (r1 == &x)" in the Linux
kernel.

2. Unless there is something explicit stopping the reordering, the
herd tool assumes that the compiler can reorder unrelated code
completely across the entirety of an "if" statement. It might
well have decided that it could do so in this case, due to the
fact that the "if" statement isn't doing anything with x (just
with its address).

But yes, given that r1 comes from the load from *c, it would
be difficult (at best) to actually apply that optimization in
this case.

But let's find out what is really happening. Easy to speculate, but
much harder to speculate correctly. ;-)

Thanx, Paul

\
 
 \ /
  Last update: 2018-05-30 00:52    [W:0.092 / U:1.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site