From: Thomas Gleixner <tglx@kernel.org>
To: Usama Arif <usama.arif@linux.dev>, Dmitry Ilvokhin <d@ilvokhin.com>
Cc: peterz@infradead.org, andrealmeid@igalia.com, dave@stgolabs.net,
dvhart@infradead.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, mingo@redhat.com,
shuah@kernel.org, shakeel.butt@linux.dev, hannes@cmpxchg.org,
riel@surriel.com, kernel-team@meta.com
Subject: Re: [PATCH] futex: Avoid hash-bucket locking for mismatched waits
Date: Fri, 14 Aug 2026 18:02:45 +0200 [thread overview]
Message-ID: <87v79clmfu.ffs@fw13> (raw)
In-Reply-To: <87y0e8lmih.ffs@fw13>
On Fri, Aug 14 2026 at 18:01, Thomas Gleixner wrote:
> On Mon, Aug 10 2026 at 13:17, Usama Arif wrote:
>> 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.
>
> It's not a memory ordering instruction, but it has to guarantee that the
> AC change is effective when the subsequent permission check
> happens. That's true for both STAC and CLAC.
>
> So it _cannot_ be free by definition and the penalty depends on the
> micro architecture.
>
>> 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].
>
> It's not relevant whether your ZEN5 works fine or not. We are not
> optimizing for a particular machine.
>
> A trivial futex bouncing test case with two threads degrades on a ZEN3
> by ~20% and when looking at it with perf top clearly the extra user
> access stands out very prominently.
>
> The below variant does not expose that behavior and actually improves
> the same test case by ~5% on that machine.
Bah. Included the broken version. Fixed one is below.
Thanks,
tglx
---
kernel/futex/waitwake.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -857,7 +857,21 @@ int futex_wait_setup(u32 __user *uaddr,
CLASS(hbr, hbr)(&q->key);
auto hb = hbr.hb;
- futex_q_lock(q, hb);
+ futex_hb_waiters_inc(hb);
+ q->lock_ptr = &hb->lock;
+
+ if (!spin_trylock(&hb->lock)) {
+ ret = get_user_inline(uval, uaddr);
+ if (ret) {
+ futex_hb_waiters_dec(hb);
+ return ret;
+ }
+ if (uval != val) {
+ futex_hb_waiters_dec(hb);
+ return -EWOULDBLOCK;
+ }
+ spin_lock(&hb->lock);
+ }
ret = futex_get_value_locked(&uval, uaddr);
next prev parent reply other threads:[~2026-08-14 16:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 19:26 [PATCH] futex: Avoid hash-bucket locking for mismatched waits Usama Arif
2026-08-04 17:07 ` Dmitry Ilvokhin
2026-08-05 13:28 ` Usama Arif
2026-08-07 15:42 ` Thomas Gleixner
2026-08-10 12:17 ` Usama Arif
2026-08-14 16:01 ` Thomas Gleixner
2026-08-14 16:02 ` Thomas Gleixner [this message]
[not found] ` <87v79lm0kk.ffs@fw13>
2026-08-10 12:35 ` Usama Arif
2026-08-14 15:55 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v79clmfu.ffs@fw13 \
--to=tglx@kernel.org \
--cc=andrealmeid@igalia.com \
--cc=d@ilvokhin.com \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=usama.arif@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox