Please sign in to comment.
locking/mutex: Add lock handoff to avoid starvation
Implement lock handoff to avoid lock starvation. Lock starvation is possible because mutex_lock() allows lock stealing, where a running (or optimistic spinning) task beats the woken waiter to the acquire. Lock stealing is an important performance optimization because waiting for a waiter to wake up and get runtime can take a significant time, during which everyboy would stall on the lock. The down-side is of course that it allows for starvation. This patch has the waiter requesting a handoff if it fails to acquire the lock upon waking. This re-introduces some of the wait time, because once we do a handoff we have to wait for the waiter to wake up again. A future patch will add a round of optimistic spinning to attempt to alleviate this penalty, but if that turns out to not be enough, we can add a counter and only request handoff after multiple failed wakeups. There are a few tricky implementation details: - accepting a handoff must only be done in the wait-loop. Since the handoff condition is owner == current, it can easily cause recursive locking trouble. - accepting the handoff must be careful to provide the ACQUIRE semantics. - having the HANDOFF bit set on unlock requires care, we must not clear the owner. - we must be careful to not leave HANDOFF set after we've acquired the lock. The tricky scenario is setting the HANDOFF bit on an unlocked mutex. Tested-by: Jason Low <firstname.lastname@example.org> Signed-off-by: Peter Zijlstra (Intel) <email@example.com> Reviewed-by: Waiman Long <Waiman.Long@hpe.com> Cc: Andrew Morton <firstname.lastname@example.org> Cc: Linus Torvalds <email@example.com> Cc: Paul E. McKenney <firstname.lastname@example.org> Cc: Peter Zijlstra <email@example.com> Cc: Thomas Gleixner <firstname.lastname@example.org> Cc: email@example.com Signed-off-by: Ingo Molnar <firstname.lastname@example.org>
- Loading branch information...