On 04/10/2019 11:07 AM, Peter Zijlstra wrote: > On Fri, Apr 05, 2019 at 03:21:05PM -0400, Waiman Long wrote: >> Because of writer lock stealing, it is possible that a constant >> stream of incoming writers will cause a waiting writer or reader to >> wait indefinitely leading to lock starvation. >> >> The mutex code has a lock handoff mechanism to prevent lock starvation. >> This patch implements a similar lock handoff mechanism to disable >> lock stealing and force lock handoff to the first waiter in the queue >> after at least a 5ms waiting period. The waiting period is used to >> avoid discouraging lock stealing too much to affect performance. > So the mutex code doesn't have that timeout, it foces the handoff if the > top waiter fails to acquire. > > I don't find the above sufficiently justifies the additional complexity. > What were the numbers with the simple scheme vs this etc..
When the handoff bit is set, it stops the lock from being acquired by anyone else until the front waiter is woken up, scheduled and take the lock. Doing that too frequently will impede the throughput when the rwsem is highly contended. I can ran some performance test to show the difference it can make. I have also been thinking about having the front waiter set the handoff bit and then spin on owner so that it can acquire the lock immediately after it is freed. It will be a follow up patch. Cheers, Longman
