lkml.org 
[lkml]   [2023]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 08/11] slub: Replace cmpxchg_double()
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


\
 
 \ /
  Last update: 2023-05-25 15:12    [W:0.237 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site