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:01:10 +0200	[thread overview]
Message-ID: <87y0e8lmih.ffs@fw13> (raw)
In-Reply-To: <f4eaec7c-39f7-4040-b668-946de9c70941@linux.dev>

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.

Thanks,

        tglx
---
 kernel/futex/waitwake.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

--- a/kernel/futex/waitwake.c
+++ b/kernel/futex/waitwake.c
@@ -857,7 +857,17 @@ 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)
+				return ret;
+			if (uval != val)
+				return -EWOULDBLOCK;
+			spin_lock(&hb->lock);
+		}
 
 		ret = futex_get_value_locked(&uval, uaddr);
 



  reply	other threads:[~2026-08-14 16:01 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 [this message]
2026-08-14 16:02           ` Thomas Gleixner
     [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=87y0e8lmih.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