On Wed, Feb 5, 2020 at 7:13 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > 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. Ah, yes, I overlooked that. (I think that they are equivalent for LKL because it is a non-SMP arch only at this moment, but I agree that the better approach is to have a proper implementation in LKL)
