> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
