Messages in this thread | | | Date | 28 Jan 2014 21:57:40 -0500 | From | "George Spelvin" <> | Subject | Re: [PATCH v3 1/2] qspinlock: Introducing a 4-byte queue spinlock implementation |
| |
> 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.
>> 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.
| |