Message-ID: <4f5228b6-839c-9e04-bf7c-34fb8e25fd13@huaweicloud.com>
Date:   Sat, 4 Nov 2023 19:20:27 +0100
From:   Jonas Oberhauser <jonas.oberhauser@...weicloud.com>
To:     "Alglave, Jade" <j.alglave@....ac.uk>,
        "will@...nel.org" <will@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "npiggin@...il.com" <npiggin@...il.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "parri.andrea@...il.com" <parri.andrea@...il.com>,
        "paulmck@...nel.org" <paulmck@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-toolchains@...r.kernel.org" <linux-toolchains@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "boqun.feng@...il.com" <boqun.feng@...il.com>,
        "davidtgoldblatt@...il.com" <davidtgoldblatt@...il.com>,
        viktor@...-sws.org
Subject: Re: [isocpp-parallel] OOTA fix (via fake branch-after-load)
 discussion

Thanks Jade.

I agree with the position you linked to in that the move is... unwise.

IMO, for a high-level language like C, if you need to outrule OOTA, just 
declare it impossible (Viktor, in CC, made this suggestion a while ago) 
by a "no OOTA axiom".

BTW, is there at least a proof that just making relaxed atomics ordered 
in this way rules out OOTA in programs that contain non-atomics?
Or can we have something like the LKMM OOTA example I sent around last year?


best wishes,

jonas


Am 11/3/2023 um 6:02 PM schrieb Alglave, Jade:
> Dear all, (resending because I accidentally sent it in html first, sorry)
>
> Arm’s official position on the topic can be found in this recent blog:
> https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-technical-view-on-relaxed-atomics
>
> Please do reach out to memory-model@....com if there are any questions.
> Thanks,
> Jade
>
>
> From: Paul E. McKenney <paulmck@...nel.org>
> Sent: 27 October 2023 22:08
> To: Alglave, Jade <j.alglave@....ac.uk>; will@...nel.org <will@...nel.org>; catalin.marinas@....com <catalin.marinas@....com>; linux@...linux.org.uk <linux@...linux.org.uk>; mpe@...erman.id.au <mpe@...erman.id.au>; npiggin@...il.com <npiggin@...il.com>; palmer@...belt.com <palmer@...belt.com>; parri.andrea@...il.com <parri.andrea@...il.com>
> Cc: linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>; linux-toolchains@...r.kernel.org <linux-toolchains@...r.kernel.org>; peterz@...radead.org <peterz@...radead.org>; boqun.feng@...il.com <boqun.feng@...il.com>; davidtgoldblatt@...il.com <davidtgoldblatt@...il.com>
> Subject: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion
>
> ⚠ Caution: External sender
>
>
> 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.  ;-)
>
>                                                          Thanx, Paul
>
> [1] https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/
> [2] https://dl.acm.org/doi/10.1145/3192366.3192421
>
> ----- Forwarded message from David Goldblatt via Parallel <parallel@...ts.isocpp.org> -----
>
> Date: Fri, 27 Oct 2023 11:09:18 -0700
> From: David Goldblatt via Parallel <parallel@...ts.isocpp.org>
> To: SG1 concurrency and parallelism <parallel@...ts.isocpp.org>
> Reply-To: parallel@...ts.isocpp.org
> Cc: David Goldblatt <davidtgoldblatt@...il.com>
> Subject: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion
>
> Those who read this list but not the LLVM discourse might be interested in:
> - This discussion, proposing `-mstrict-rlx-atomics`:
> https://discourse.llvm.org/t/rfc-strengthen-relaxed-atomics-implementation-behind-mstrict-rlx-atomics-flag/74473
> to enforce load-store ordering
> - The associated blog post here:
> https://lukegeeson.com/blog/2023-10-17-A-Proposal-For-Relaxed-Atomics/
>
> - David
>
> _______________________________________________
> Parallel mailing list
> Parallel@...ts.isocpp.org
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/parallel
> Link to this post: http://lists.isocpp.org/parallel/2023/10/4151.php
>
>
> ----- End forwarded message -----

Powered by blists - more mailing lists