So the 1-2 threads case is the standard case on a small
system, isn't it? This may well cause regressions.

Well, the common case should be uncontended, which is faster.
But yes, testing would be nice.

quoted

In the extremely unlikely case that all the queue node entries are
used up, the current code will fall back to busy spinning without
waiting in a queue with warning message.

Traditionally we had some code which could take thousands
of locks in rare cases (e.g. all locks in a hash table or all locks of
a big reader lock) 

Doesn't apply; the question implies a misunderstanding of what's
happening.  The entry is only needed while spinning waiting for
the lock.  Once the lock has been acquired, it may be recycled.

The thread may *hold* thousands of locks; the entries only apply
to locks being *waited for*.

From process context a thread may only be waiting for one at a time.
Additional entries are only needed in case a processor takes an interrupt
while spinning, and the interrupt handler wants to take a lock, too.

If that lock also has to be waited for, and during the wait you take a
nested interrupt or NMI, a third level might happen.

The chances of this being nested more than 4 deep seem sufficiently
minute.