[Bug nptl/33704] trylock throughput reduces significantly under high concurency load.

[skpgkp2 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=33704

--- Comment #5 from Sunil Pandey <skpgkp2 at gmail dot com> ---
(In reply to Florian Weimer from comment #4)
> (In reply to Sunil Pandey from comment #3)
> > (In reply to Florian Weimer from comment #2)
> > > Is this a regression?
> > > 
> > > I think the choice is here where to do a CAS optimistically, or a regular
> > > load and check the value first. My hunch is the first approach is better
> > > because a contended trylock is never going to be fast anyway. But I might be
> > > wrong about it.
> > 
> > It is not regression, but more of perf optimization.
> > 
> > Data shows that its improving throughput by ~20x, under highly cache
> >  contested load and it scale much better with increased concurrency than the
> > current implementation.
> > 
> > Processor with more than 100+ core is getting more common, I think this fix
> > can help with scalability/performance.
> 
> My concern is that to solve the performance, you need to tackle it one layer
> up (or several layers up). Even if we make the trylock failure faster, the
> application still has to enter the fallback path. That can't be good for
> performance.

We are getting trylock cache contention perf issue in many application, either
directly or indirectly(charm++, namd3 etc.).

Can you please further explain the problem with this patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.