On Wed, Feb 05, 2020 at 04:00:41PM +0200, Octavian Purdila wrote: > 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] Thanks, I'll put it on the to-read list. > 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. Uh no, asm-generic/atomic.h is radically different from lib/atomic64.c. asm-generic/atomic.h builds all required atomic operations from cmpxchg() (loops), while lib/atomic64.c builds 64bit atomics by using a hashed set of spinlocks. The asm-generic stuff gives you real atomic ops, albeit sub-optimal, lib/atomic64.c gives you a turd.
