Messages in this thread | | | Date | Tue, 2 Apr 2024 04:37:53 +0100 | From | Al Viro <> | Subject | Re: [PATCH RFC cmpxchg 2/8] sparc: Emulate one-byte and two-byte cmpxchg |
| |
On Tue, Apr 02, 2024 at 01:07:58AM +0100, Al Viro wrote:
> It does, IIRC. > > > Would you like to do that patch? If so, I would be happy to drop mine > > in favor of yours. If not, could I please have your Signed-off-by so > > I can do the Co-developed-by dance? > > Will do once I dig my way from under the pile of mail (sick for a week > and subscribed to l-k, among other lists)...
FWIW, parisc is in the same situation - atomics-by-cached-spinlocks. 've a candidate branch, will post if it survives build...
Re parisc: why does it bother with arch_cmpxchg_local()? Default is * save and disable local interrupts * read the current value, compare to old * if equal, store new there * restore local interrupts For 32bit case parisc goes for __cmpxchg_u32(), which is * if (SMP) choose the spinlock (indexed by hash of address) * save and disable local interrupes * if (SMP) arch_spin_lock(spinlock) * read the current value, compare to old * if equal, store new there * if (SMP) arch_spin_unlock(spinlock) * restore local interrupts In UP case it's identical to generic; on SMP it's strictly more work. Unless I'm very confused about cmpxchg_local() semantics, the callers do not expect atomicity wrt other CPUs, so why do we bother?
| |