lkml.org 
[lkml]   [2016]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH -v2 4/4] locking/mutex: Add lock handoff to avoid starvation
On 08/30/2016 07:53 AM, Peter Zijlstra wrote:
> On Mon, Aug 29, 2016 at 05:41:09PM +0200, Peter Zijlstra wrote:
>> On Fri, Aug 26, 2016 at 07:40:34PM -0400, Waiman Long wrote:
>>> On 08/26/2016 11:18 AM, Peter Zijlstra wrote:
>>>> Still need to look at adding spinning to the handoff case.
>>>> Also need to look at writing (much) better changelogs, they stink.
>>>>
>>> I have looked at the handoff code and I didn't see any problem.
>> So I found (or rather the buildbot did) a problem with it.
>>
>> locking-selftest has testcases like:
>>
>>
>> lock(&A);
>> if (trylock(&A))
>> /* fail */
>>
>> and
>>
>> ww_lock(&A)
>> if (ww_lock(&A) != -EDEADLK)
>> /* fail */
>>
>> But with the 'trylock' accepting the lock if owner==current, in order to
>> accept the hand-off, this breaks in interesting ways.
>>
>> Now, ARCH_MIN_TASKALIGN is at least 8 (mips, s390, parisc) which would
>> give us one more FLAG bit to play with.
>>
>>
>> The below seems to make things happy again..
> Much simpler solution... only accept handoffs when we're stuck in the
> wait loop (which precludes doing recursive locking, since that would've
> failed much earlier).
>
> Now, let me look at that spinner patch you sent.

Yes, that is like my original mutex patch that sets a flag (the handoff
bit) that disable the optimistic spinner from grabbing the lock. I
hadn't been thinking about the corner case of a trylock after lock.
Fortunately, we have test that can uncover those problems.

Cheers,
Longman

\
 
 \ /
  Last update: 2016-09-17 09:58    [W:0.063 / U:0.860 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site