Message-ID: <d18e0ce6-db9e-4590-a7ab-15e27b2c33f4@paulmck-laptop>
Date:   Mon, 6 Nov 2023 18:16:24 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     j.alglave@....ac.uk, will@...nel.org, catalin.marinas@....com,
        linux@...linux.org.uk, mpe@...erman.id.au, npiggin@...il.com,
        palmer@...belt.com, parri.andrea@...il.com,
        linux-kernel@...r.kernel.org, linux-toolchains@...r.kernel.org,
        boqun.feng@...il.com, davidtgoldblatt@...il.com
Subject: Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load)
 discussion

On Mon, Nov 06, 2023 at 12:08:59AM +0100, Peter Zijlstra wrote:
> On Fri, Oct 27, 2023 at 02:08:13PM -0700, Paul E. McKenney wrote:
> > Hello!
> > 
> > FYI, unless someone complains, it is quite likely that C++ (and thus
> > likely C) compilers and standards will enforce Hans Boehm's proposal
> > for ordering relaxed loads before relaxed stores.  The document [1]
> > cites "Bounding data races in space and time" by Dolan et al. [2], and
> > notes an "average a 2.x% slow down" for ARMv8 and PowerPC.  In the past,
> > this has been considered unacceptable, among other things, due to the
> > fact that this issue is strictly theoretical.
> > 
> > This would not (repeat, not) affect the current Linux kernel, which
> > relies on volatile loads and stores rather than C/C++ atomics.
> > 
> > To be clear, the initial proposal is not to change the standards, but
> > rather to add a command-line argument to enforce the stronger ordering.
> > However, given the long list of ARM-related folks in the Acknowledgments
> > section, the future direction is clear.
> > 
> > So, do any ARMv8, PowerPC, or RISC-V people still care?  If so, I strongly
> > recommend speaking up.  ;-)
> 
> OK, I finally had some time to read up...
> 
> Colour me properly confused. To me this all reads like C people can't
> deal with relaxed atomics and are doing crazy things to try and 'fix'
> it.
> 
> And while I don't speak for ARM/Power, I do worry this all takes C/C++
> even further away from LKMM instead of closing the gap.
> 
> Worse, things like:
> 
>   https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/
> 
> Which state:
> 
>  "It would solve real issues in the Linux Kernel without costly fences
>  (the kernel does not use relaxed atomics or the ISO C/C++ model - the
>  load buffering issue affects the ISO C and linux memory models) ..."
> 
> Which is a contradiction if ever I saw one. It both claims this atrocity
> fixes our volatile_if() woes while at the same time saying we're
> unaffected because we don't use any of the C/C++ atomic batshit.

I guess that my traditional reply would be that if you are properly
confused by all this, that just means that you were reading carefully.

> Anyway, I worry that all this faffing about will get in the way of our
> volatile_if() 'demands'. Compiler people will tell us, just use relaxed
> atomics, which that is very much not what we want. We know relaxed loads
> and stores behave 'funny', we've been doing that for a long long time.
> Don't impose that madness on us. And certainly don't use us as an excuse
> to peddle this nonsense.

I am very much against incurring real overhead to solve an issue that is
an issue only in theory and not in practice.  I wish I could confidently
say that my view will prevail, but...

> Bah, what a load of crazy.
> 
> /me stomps off in disgust.

If this goes through and if developers see any overhead from relaxed
atomics in a situation that matters to them, they will reach for some
other tool.  Inline assembly and volatile accesses, I suppose.  Or the
traditional approach of a compiler flag.

							Thanx, Paul

Powered by blists - more mailing lists