Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Mon, 6 Nov 2023 18:16:24 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     j.alglave@ucl.ac.uk, will@kernel.org, catalin.marinas@arm.com,
        linux@armlinux.org.uk, mpe@ellerman.id.au, npiggin@gmail.com,
        palmer@dabbelt.com, parri.andrea@gmail.com,
        linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org,
        boqun.feng@gmail.com, davidtgoldblatt@gmail.com
Subject: Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load)
 discussion
Message-ID: <d18e0ce6-db9e-4590-a7ab-15e27b2c33f4@paulmck-laptop>
Reply-To: paulmck@kernel.org
References: <b1634b24-4541-49c5-867c-7f24292a27bb@paulmck-laptop>
 <20231105230859.GH8262@noisy.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231105230859.GH8262@noisy.programming.kicks-ass.net>
Precedence: bulk

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