On Thu, Oct 26, 2023 at 01:16:25PM +0200, Peter Zijlstra wrote: > On Thu, Oct 26, 2023 at 11:36:10AM +0100, Gary Guo wrote: > > > There's two reasons that we are using volatile read/write as opposed to > > relaxed atomic: > > * Rust lacks volatile atomics at the moment. Non-volatile atomics are > > not sufficient because the compiler is allowed (although they > > currently don't) optimise atomics. If you have two adjacent relaxed > > loads, they could be merged into one. > > Ah yes, that would be problematic, eg, if lifted out of a loop things > could go sideways fast. > > > * Atomics only works for integer types determined by the platform. On > > some 32-bit platforms you wouldn't be able to use 64-bit atomics at > > all, and on x86 you get less optimal sequence since volatile load is > > permitted to tear while atomic load needs to use LOCK CMPXCHG8B. > > We only grudgingly allowed u64 READ_ONCE() on 32bit platforms because > the fallout was too numerous to fix. Some of them are probably bugs. > > Also, I think cmpxchg8b without lock prefix would be sufficient, but > I've got too much of a head-ache to be sure. Worse is that we still > support targets without cmpxchg8b. Plus cmpxchg8b can be quite a bit heavier weight than READ_ONCE(), in some cases to the point that you would instead use some other concurrency design. > It might be interesting to make the Rust side more strict in this regard > and see where/when we run into trouble. And maybe have some other name for READ_ONCE() that is permitted to tear. > > * Atomics doesn't work for complex structs. Although I am not quite sure > > of the value of supporting it. > > So on the C side we mandate the size is no larger than machine word, > with the exception of the u64 on 32bit thing. We don't mandate strict > integer types because things like pte_t are wrapper types. On C-language atomics, people who have talked about implementing atomics for objects too large for tear-free loads and stores have tended to want ot invent locks. :-( Thanx, Paul
