| Message ID | 20230515075659.118447996@infradead.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce cmpxchg128() -- aka. the demise of cmpxchg_double() | expand |
On Mon, May 15, 2023, at 09:56, Peter Zijlstra wrote: > > Since v2: > > - reworked this_cpu_cmpxchg() to not implicity do u128 but provide explicit > this_cpu_cmpxchg128() (arnd) > - added try_cmpxchg12_local() (per the addition of the try_cmpxchg*_local() > family of functions) > - slight cleanup of the SLUB conversion (due to rebase and having to touch it) > - added a 'cleanup' patch for SLUB, since I was staring at that anyway > This is clearly an improvement over the previous state, so I'm happy with that, and the explicit this_cpu_cmpxchg128() interface addresses most of my previous concerns. Reviewed-by: Arnd Bergmann <arnd@arndb.de> The need for runtime feature checking in the callers on x86-64 is still a bit awkward, but this is no worse than before. I understand that turning this into a compile-time choice would require first settling a larger debate about raising the default target for distros beyond the current CONFIG_GENERIC_CPU. Arnd
On Mon, May 15, 2023 at 11:42:23AM +0200, Arnd Bergmann wrote: > The need for runtime feature checking in the callers on x86-64 is still > a bit awkward, but this is no worse than before. I understand that > turning this into a compile-time choice would require first settling > a larger debate about raising the default target for distros beyond > the current CONFIG_GENERIC_CPU. Looks like Power is going to be in the same boat, they can do cmpxchg128, but only for Power8+.