Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@kernel.org>
To: Usama Arif <usama.arif@linux.dev>, Dmitry Ilvokhin <d@ilvokhin.com>
Cc: Usama Arif <usama.arif@linux.dev>,
	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, 07 Aug 2026 17:42:58 +0200	[thread overview]
Message-ID: <87jyq2dji5.ffs@fw13> (raw)
In-Reply-To: <20260805132831.2852771-1-usama.arif@linux.dev>

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.

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


      reply	other threads:[~2026-08-07 15:43 UTC|newest]

Thread overview: 4+ 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 [this message]

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=87jyq2dji5.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