Re: [PATCH v3 08/11] slub: Replace cmpxchg_double()

[Peter Zijlstra]

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