On Tue, 11 Mar 2025 19:04:47 +0100
Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
> A small bit before that:
> if (!spin_trylock_irqsave(&zone->lock, flags)) {
> if (unlikely(alloc_flags & ALLOC_TRYLOCK))
> return NULL;
> spin_lock_irqsave(&zone->lock, flags);
> }
>
> This is going to perform worse when contested due to an extra access to
> the lock. I presume it was done this way to avoid suffering another
> branch, with the assumption the trylock is normally going to succeed.
What extra access? If a spinlock were to fail, it keeps checking the
lock until it's released. If anything, this may actually help with
performance when contended.
Now, there's some implementations of spinlocks where on failure to
secure the lock, some magic is done to spin on another bit instead of
the lock to prevent cache bouncing (as locks usually live on the same
cache line as the data they protect). When the owner releases the lock,
it will also have to tell the spinners that the lock is free again.
But this extra trylock is not going to show up outside the noise.
-- Steve
