[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