Re: [RFC] making nested spin_trylock() work on UP?

[Vlastimil Babka <vbabka@suse.cz>]

On 2/14/26 17:32, Linus Torvalds wrote:
> On Fri, 13 Feb 2026 at 22:29, Matthew Wilcox <willy@infradead.org> wrote:
>>
>> What if we use an atomic_t on UP to simulate there being a spinlock,
>> but only for pcp?
> 
> Yes. Please just wrap this - very unusual - use case with a special
> wrapper that can then be entirely different for UP and SMP, and use
> something like the suggested "pcp_lock" that becomes a spinlock on
> smp, and just a tracking variable on UP.
> 
> And I don't think it needs to even be marked as 'atomic_t' on UP - the
> value is going to be idempotent even when modified from interrupts
> (because it will just be modified back), so no need for any special
> logic, I think. The generic 'atomic_t' ops on UP disable interrupts,
> which is horrendous.

I think we could be using local_trylock_t, which does exactly this without
atomic_t.

However David had an even better suggestion (in a chat) that the pcp cache
is unnecessary on UP for scalability anyway, so we can just have the trylock
wrapper do nothing and fail unconditionally with SMP=n, and then all the
cleanups I wanted are immediately possible and we'll even save some memory
that would be cached unnecessarily on those small systems (and some code
will be eliminated as dead). So I'll be going with that.

> Changing spinlocks globally on UP to be something they haven't been
> before does not sound like a good idea, particularly since no actual
> developer uses UP any more (and  honestly, UP is dead outside of very
> low-end platforms or legacy like 68k).

Ack, thanks.

>             Linus