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

[fweimer at redhat dot com]

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

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
(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.

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