Messages in this thread | | | Date | Tue, 30 Aug 2016 18:32:16 -0400 | From | Waiman Long <> | Subject | Re: [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
| |