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

[Usama Arif <usama.arif@linux.dev>]

On 07/08/2026 16:42, Thomas Gleixner wrote:
> On Wed, Aug 05 2026 at 06:28, Usama Arif wrote:
>> On Tue, 4 Aug 2026 17:07:59 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
>> The above data shows the significance of the patch.
>> It provides a very meaningful improvement (22.4% of time spent in futex_q_lock()
>> will be significantly optimized and will also deliver second-order effects)
>> and has no measurable impact on latency in the matching path.
>> IMHO, this patch is a free lunch.
> 
> Not really free. The user space access is not exactly cheap either
> because CLAC/STAC are memory fencing to meet the SMAP guarantees.
> 


My understanding from 86e6b1547b3d is that STAC/CLAC “end up serializing
execution on older Zen,” while Zen 5’s AC renaming “improves performance
of STAC/CLAC a lot a lot.”  Architecturally, they only change the AC bit.
They are not memory-ordering instructions like LFENCE. I am currently
testing on Zen5 which could be why I didn't see any wall-time regression
in futex_wait_timeout.c from [1].

> I've tried that lockless read/test before and gave up when a
> multi-waiter real world test case degraded by 5-10% depending on micro
> architecture.
> 


futex_wait_timeout.c [1] deliberately makes every call take the two-read path
and doesnt show any wall-time regression. The extra userspace read ofcourse
introduces additional instructions, but it is not showing up in any metric what
I thought would be the worst case in real world metrics.

The precheck adds no work while hb->lock is held, so it won't cause any more
contention.

I have been trying to coming up with some example userspace program that
would be negatively impacted by this patch and can't. I am not sure how
multi-waiter case that you described can result in 5-10% degradation
as the extra read is not showing up in wall clock time and we are not
adding more work under lock. I am currently testing on a Zen5 system.
Could you share the reproducer, thread topology, measured metric, and CPU
model on which you saw the 5–10% regression?

[1] https://lore.kernel.org/all/20260805132831.2852771-1-usama.arif@linux.dev/