Re: [PATCH] futex: Avoid hash-bucket locking for mismatched waits

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Aug 20 2026 at 16:14, Dmitry Ilvokhin wrote:
> On Fri, Aug 14, 2026 at 06:02:45PM +0200, Thomas Gleixner wrote:
> I've built a benchmark to simulate this behaviour on the smaller scale
> and run it with two threads and `nproc` threads to simulate low and high
> contention cases. The benchmark is a bit on a extreme side, but I think
> it approximates the real world case quite well.
>
> The numbers below are averaged across 10 runs.
>
> SKYLAKE (2 NUMA NODES, 80 CPUS, Intel(R) Xeon(R) Gold 6138 CPU)
>
> Threads   Baseline (ops/sec)    Patched            95% CI        Diff
> -----------------------------------------------------------------------
> 2           5,917,777          6,441,061     [ -1.98%, +19.67%]   +8.84%
> 80            122,926             77,801     [-41.17%, -32.25%]  -36.71%
>
>
> BERGAMO (1 NUMA NODE, 176 CPUS, AMD EPYC 9D64)
>
> Threads   Baseline (ops/sec)    Patched            95% CI        Diff
> -----------------------------------------------------------------------
> 2            14,952,962        14,482,494     [ -4.62%, -1.68%]   -3.15%
> 176             161,294           127,563     [-21.72%, -20.11%] -20.91%
>
>
> Skylake two thread case seems in line with ~5% improvement you measured,
> but numbers are quite noisy. Other runs do not look encouraging.
>
> It looks like early bail out amplifies contention problem even more.
> Instead of letting thread spin on the hb->lock, early check returns just
> for userspace to retry again moment later. Ideally, it would be better
> to park spinning thread as fast as possible and with early bail out we
> do opposite of that.

Changing the timing even slightly either in user space or in kernel
space results in different outcomes depending on the micro architecture,
NUMA, contention scenario ...

While it is benefical for some scenarios to avoid the wait/wake, for
others especially those with high concurrency in trying to acquire the
futex the cache line bouncing just gets worse.

And yes, you are right that with your benchmark the early bail amplifies
exactly that problem. The hash bucket lock contention eases the cache
line contention for the price of wasting CPU cycles in the kernel.

There is no magic cure for this with the current implementations and I
doubt that any benchmark will give a satisfying answer which is
generally useful accross a wider range of application scenarios.

This needs quite some thought and investigations to get right.

Thanks,

        tglx