The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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);
 

  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