Travis Downs (travis.downs.delete@this.gmail.com) on January 14, 2020 10:06 am wrote:
>
> I can't actually confirm this because it seems like MCS lock has
> ~zero actual uses in the kernel, unless I'm searching wrong.

I think you missed the kernel/locking/qspinlock.c file.

Nobody uses the mcs locks directly as such. But the queued spinlocks are basically the MCS lock with some modifications (and you can see a big comment at the top of that file about it).

We have various reasons why we want a spinlock to be just 4 bytes in size, partly because we embed those things in a lot of core data structures, partly because we also have things like "lock-atomic reference counts" (search for "lockref", and see lib/lockref.c) that means that we need (*) to fit the spinlock and a reference count into one 8-byte thing that can be accessed atomically.

So you are correct that there are no users of the traditional MCS lock in the kernel, but there is one very core user that uses a modified version of it.

Almost all architectures use that queued spinlock as their core spinlock implementation. The exceptions are the ones that have no scaling issues (a lot of the small ones), and powerpc that has its own issues (small power machines don't need the queued spinlocks, big ones seem to want to use the special power virtualized environment spinning logic).

Linus

(*) reflocks don't have to do that, but the fast implementation requires it so that it can do an atomic "increment this variable unless the lock is held" without actually taking the lock.