Acquiring a lock on the same CPU that holds it - what can be done?

[Konstantin Belousov]

On Wed, Jan 08, 2014 at 11:30:30PM +0200, Andriy Gapon wrote:
> on 08/01/2014 20:59 Konstantin Belousov said the following:
> > On Wed, Jan 08, 2014 at 06:29:59PM +0200, Andriy Gapon wrote:
> >> 
> >> I am sure that the following approach was suggested before, but I can not
> >> find any references now. So, the idea is to auto-associate a priority
> >> with a lock.  Every time a priority lending would kick in we would record
> >> the priority in the lock.  The next time a thread with a lower priority
> >> acquires that lock we would automatically boost the thread to the
> >> recorded priority until it releases the lock.  This should prevent the
> >> situation that you've described where a higher priority thread preempts
> >> a lower priority thread just to discover that it holds a required lock
> >> and priority lending is required before relinquishing a CPU to the
> >> preempted thread.
> > 
> > Isn't this exactly the mechanism offered by turnstiles, and used by 
> > non-sleepable locks ?
> 
> No, as far as I can see.  The current mechanism is to lend priority when
> contention happens.  The proposal is to remember the maximal (numerically
> minimal) lent priority and thus to prevent potentially contending threads from
> even running on the same CPU.

I.e. you propose to extend the prioriry propagation to all cases of lock
acquisition.  This is not quite correct as well, but now in the other
direction, since it prevents non-contending high-priority thread from
running.

I think a good experiment would be to add critical_enter/critical_exit
to non-sleepable locks and see.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140109/173068c3/attachment.sig>