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

skpgkp2 at gmail dot com sourceware-bugzilla@sourceware.org
Mon Dec 8 23:53:59 GMT 2025


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

--- Comment #3 from Sunil Pandey <skpgkp2 at gmail dot com> ---
(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.

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


More information about the Glibc-bugs mailing list