On Wed, Aug 28, 2024 at 01:48:41PM +0000, Arnd Bergmann wrote: > On Wed, Aug 28, 2024, at 13:11, Paul E. McKenney wrote: > > Hello, Arnd, > > > > You know how it goes, give them an inch... > > > > I did get a request for 16-bit xchg(), but last I checked, Linux still > > supports some systems that do not have 16-bit store instructions. > > > > Could you please let me know whether this is still the case? > > Hi Paul, > > The only one I'm aware of that can't do it easily > is a configuration on 32-bit ARM that enables both > CONFIG_CPU_V6 and CONFIG_SMP, but I already wrote > a patch that forbids that configuration for other > reasons. I just need to send that patch. Very good, and thank you! > There is a related problem with ARM RiscPC, which > uses a kernel built with -march=armv3, and that > disallows 16-bit load/store instructions entirely, > similar to how alpha ev5 and earlier lacked both > byte and word access. And one left to go. Progress, anyway. ;-) > Everything else that I see has native load/store > on 16-bit words and either has 16-bit atomics or > can emulate them using the 32-bit ones. > > However, the one thing that people usually > want 16-bit xchg() for is qspinlock, and that > one not only depends on it being atomic but also > on strict forward-progress guarantees, which > I think the emulated version can't provide > in general. > > This does not prevent architectures from doing > it anyway. Given that the simpler spinlock does not provide forward-progress guarantees, I don't see any reason that these guarantees cannot be voided for architectures without native 16-bit stores and atomics. After all, even without those guarantees, qspinlock provides very real benefits over simple spinlocks. Thanx, Paul
