On Thu, May 25, 2023 at 12:52:06PM +0200, Arnd Bergmann wrote: > On Thu, May 25, 2023, at 12:29, Peter Zijlstra wrote: > > On Wed, May 24, 2023 at 11:32:47AM +0200, Peter Zijlstra wrote: > >> On Mon, May 15, 2023 at 09:57:07AM +0200, Peter Zijlstra wrote: > > > > This then also means I need to look at this_cpu_cmpxchg128 and > > this_cpu_cmoxchg64 behaviour when we dont have the CPUID feature. > > > > Because current verions seem to assume the instruction is present. > > As far as I could tell when reviewing your series, this_cpu_cmpxchg64() > is always available on all architectures. Depending on compile-time > feature detection this would be either a native instruction that > is guaranteed to work, or the irq-disabled version. On x86, this > is handled at runtime with alternative_io(). > > this_cpu_cmpxchg128() clearly needed the system_has_cmpxchg128() > check, same as system_has_cmpxchg_double() today. So, having just dug through all that, on x86: this_cpu_cmpxchg64() is: X86_CMPXCHG64=n -> fallback, irrespective of CX8 X86_CMPXCHG64=y -> cmpxchg8b X86_64 -> cmpxchg I've changed it to be similar between 32bit and 64bit such that both: cmpxchg#b when CX#, otherwise this_cpu_cmpxchg#b_emu
