This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCHv3] PowerPC: Fix a race condition when eliding a lock
- From: Andi Kleen <andi at firstfloor dot org>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org, andi at firstfloor dot org, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- Date: Sat, 10 Oct 2015 01:46:35 +0200
- Subject: Re: [PATCHv3] PowerPC: Fix a race condition when eliding a lock
- Authentication-results: sourceware.org; auth=none
- References: <55D742D3 dot 9050600 at redhat dot com> <1440439895-11812-1-git-send-email-tuliom at linux dot vnet dot ibm dot com> <1441136302 dot 5089 dot 182 dot camel at otta> <55E60E88 dot 50104 at linaro dot org> <55E61799 dot 6010707 at linux dot vnet dot ibm dot com> <1444319672 dot 25110 dot 218 dot camel at localhost dot localdomain> <5617DDA7 dot 2040602 at linux dot vnet dot ibm dot com>
On Fri, Oct 09, 2015 at 10:30:47AM -0500, Paul E. Murphy wrote:
>
> [Adding Andi if he has an opinion]
>
> On 10/08/2015 10:54 AM, Torvald Riegel wrote:
> >> A busy lock likely indicates contention in the critical section which
> >> does not benefit from elision, I'd err on the side of a persistent
> >> failure.
> >
> > I don't think I agree. An already-acquired lock is something that could
> > be hit less likely by using elision more often on this lock (think about
> > the "lemming effect").
> >
>
> My line of thinking is that you are already experiencing the effect if
> a thread hits a taken lock. It most likely [1] implies adapt_count > 0,
> so you are guaranteed a time period of serialization. The best outcome is
> that you manage to run a transaction in between an actual lock. The worst
> being you extend the serialization period.
Lemming effects happens after the taken lock is freed. It prevents
speedy recovery into the parallel eliding state.
The typical way to improve Lemming is to wait for the lock
to become free before retrying. Unfortunately that is difficult
due to the way the glibc mutexes work, as there's no way to do
this with the futex interface. It would be possible to spin a bit,
but the code doesn't do that. But to do that you shouldn't do
a persistent abort, but keep going for a bit.
>
> I think perhaps the best of both worlds might be to check the lock, and
> set the persistent bit if the lock is busy with waiters. Thoughts?
There's unfortunately nothing to check when you're experiencing the
Lemming effect. The other users just speculate on their own.
-Andi