On Wed, Feb 5, 2020 at 2:49 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > On Wed, Feb 05, 2020 at 02:24:38PM +0200, Octavian Purdila wrote: > > I was not aware that not allowing GENERIC_ATOMIC64 was intentional. I > > It might not have been, but presented with this patch, I feel like it > should've been :-) > > > understand your point that a 64 bit architecture that can't handle 64 > > bit atomic operation is broken. > > (sadly they actually exist, I shall name no names) > > > One way to deal with this in LKL would be to use GCC atomic builtins > > or if that doesn't work expose them as host operations. This would > > keep LKL as a meta-arch that can run on multiple physical > > architectures. I'll give it a try. > > What is this LKL you speak of and how does it do the 32bit atomics? > LKL is a build of the Linux kernel as a library that can run in many environments including multiple architectures and OSes [1] For 32bit atomics LKL also uses the asm-generic implementation. It is very similar with generic 64bit atomic implementation and it is used by multiple 32bit arches. I think this was my original reasoning for this patch and not going with C11 atomics. > One thing to keep in mind is that the C11 atomics (_Atomic) don't > trivially map to the LKMM -- although I keep forgetting the exact > details, there is a paper on it somewhere. Also, once you're limited to > a specific arch the issue also becomes much easier than C11 vs LKMM in > general. Thanks, I will look it up. [1] https://github.com/lkl/linux
