> At 10%duty cycle you have 25 waiters behind the lock on average. I don't think this is realistic, and it means that spinning is invoked only rarely.
Perhaps some instrumentation is in order, it seems to get invoked enough to achieve some 20% increase in lock/unlock iterations. Perhaps another metric would be of more value - such as average wait time?
Why measure an unrealistic workload?
I'd be interested in seeing runs where the average number of waiters is 0.2, 0.5, 1, and 2, corresponding to moderate-to-bad contention.
25 average waiters on compute bound code means the application needs to be rewritten, no amount of mutex tweaking will help it.
Perhaps something NR_CPUS threads would be of more interest?
That seems artificial.
At 10% that's about .8 and at 25% the 2 of your upper limit. I could add a few more duty-cycle points and make 25% the max. I'll kick that off and post the results... probably tomorrow, 10M iterations takes a while, but makes the results relatively stable.
Thanks. But why not vary the number of threads as well?
Does the wakeup code select the spinning waiter, or just a random waiter?
The wakeup code selects the highest priority task in fifo order to wake-up - however, under contention it is most likely going to go back to sleep as another waiter will steal the lock out from under it. This locking strategy is unashamedly about as "unfair" as it gets.
Best to avoid the wakeup if we notice the lock was stolen.