Re: [RFC] Avoid mutex starvation when optimistic spinning is disabled

From: Waiman Long
Date: Fri Jul 22 2016 - 13:56:03 EST

On 07/21/2016 04:57 PM, Jason Low wrote:
On Wed, 2016-07-20 at 16:29 +0300, Imre Deak wrote:
On ti, 2016-07-19 at 21:39 -0700, Jason Low wrote:
On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
Hi Imre,

Here is a patch which prevents a thread from spending too much "time"
waiting for a mutex in the !CONFIG_MUTEX_SPIN_ON_OWNER case.

Would you like to try this out and see if this addresses the mutex
starvation issue you are seeing in your workload when optimistic
spinning is disabled?
Although it looks like it didn't take care of the 'lock stealing' case
in the slowpath. Here is the updated fixed version:
This also got rid of the problem, I only needed to change the ww
functions accordingly. Also, imo mutex_trylock() needs the same
Good point. I supposed mutex_trylock() may not be causing starvation
issues, but I agree that it makes sense if mutex_trylock() fails too if
threads are supposed to yield to a waiter. I'll make the update.


I think making mutex_trylock() fail maybe a bit too far. Do we really have any real workload that cause starvation problem because of that. Code that does mutex_trylock() in a loop can certainly cause lock starvation, but it is not how mutex_trylock() is supposed to be used. We can't build in safeguard for all the possible abuses of the mutex APIs.