* Noah Meyerhans: > On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: >> > Significant performance impact has also been observed in less contrived >> > cases (MariaDB and Postgres), but I don't have a repro to share. >> >> But indeed what counts is number on real workloads. It would be nice to >> get numbers when those software are run against a rebuilt glibc. As >> those software are using a lot of atomics directly, it would be also >> interesting to have numbers with those software also rebuilt to use >> those new instructions. > > Agreed. I don't have specific examples of real world impact at the > moment. AIUI, the most significant impact comes in the usage of atomics > in pthread_mutex_lock(). When there are multiple threads contending for > a lock, one thread will (approximately) always obtain the lock, while > the others will starve. With atomics support in place, the probability > of obtaining the lock is roughly evenly distributed among all the > threads. So any workload in which multiple threads may contend for a > lock should be a candidate to demonstrate this problem in the real > world.
Does this behavior affect just one implementation with LSE, or also implementations without LSE? If the latter, we might need a different mutex implementation for AArch64. 8-(