[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjAcA4KrZ-47WiPd3haQU7rh+i315ApH82d=oZmgBUT_A@mail.gmail.com>
Date: Wed, 26 Feb 2025 13:42:29 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Martin Uecker <uecker@...raz.at>, Ralf Jung <post@...fj.de>,
"Paul E. McKenney" <paulmck@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Ventura Jack <venturajack85@...il.com>, Kent Overstreet <kent.overstreet@...ux.dev>,
Gary Guo <gary@...yguo.net>, airlied@...il.com, boqun.feng@...il.com,
david.laight.linux@...il.com, ej@...i.de, gregkh@...uxfoundation.org,
hch@...radead.org, hpa@...or.com, ksummit@...ts.linux.dev,
linux-kernel@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)
On Wed, 26 Feb 2025 at 13:26, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> As a bystander here, I just want to ask, do you mean basically to treat all
> reads as READ_ONCE() and all writes as WRITE_ONCE()?
Absolutely not.
I thought I made that clear:
"IOW, doing CSE on reads - and combining writes - when there aren't any
aliasing issues (or when there aren't any memory ordering issues)
should absolutely be considered ok.
And doing speculative reads - even if you then don't use the value -
is also entirely fine. You didn't introduce any observable behavior
difference (we'll agree to dismiss cache footprint issues)"
all of those basic optimizations would be wrong for 'volatile'.
You can't speculatively read a volatile, you can't combine two (or
more - often *many* more) reads, and you can't combine writes.
Doing basic CSE is a core compiler optimization, and I'm not at all
saying that shouldn't be done.
But re-materialization of memory accesses is wrong. Turning one load
into two loads is not an optimization, it's the opposite - and it is
also semantically visible.
And I'm saying that we in the kernel have then been forced to use
READ_ONCE() and WRITE_ONCE() unnecessarily, because people worry about
compilers doing these invalid optimizations, because the standard
allows that crap.
I'm hoping Rust can get this right.
Linus
Powered by blists - more mailing lists