Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 6 Nov 2023 18:16:24 -0800 | From | "Paul E. McKenney" <> | 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
| ![\](/images/icornerr.gif) |