Re: [PATCH] futex: Avoid hash-bucket locking for mismatched waits
Thomas Gleixner <[email protected]>
| Newsgroups | org.kernel.vger.linux-kselftest,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <87jyq2dji5.ffs@fw13> |
On Wed, Aug 05 2026 at 06:28, Usama Arif wrote: > On Tue, 4 Aug 2026 17:07:59 +0000 Dmitry Ilvokhin <[email protected]> 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. 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. It's carefully written to minimize lock contention in order to optimize wakeup latencies. The effect of the extra unlocked access and it's side effects shifts the timing enough that it runs into significantly more lock contentions than before. So it might be great for your use case, but not so great for others. Thanks, tglx