From: Thomas Gleixner <tglx@kernel.org>
To: 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: Tue, 25 Aug 2026 18:48:47 +0200 [thread overview]
Message-ID: <87tsoign80.ffs@fw13> (raw)
In-Reply-To: <878q5zipcx.ffs@fw13>
On Fri, Aug 21 2026 at 15:18, Thomas Gleixner wrote:
> On Thu, Aug 20 2026 at 16:14, Dmitry Ilvokhin wrote:
> There is no magic cure for this with the current implementations and I
> doubt that any benchmark will give a satisfying answer which is
> generally useful accross a wider range of application scenarios.
>
> This needs quite some thought and investigations to get right.
I looked a bit deeper into it. When the number of contenders is big
enough to cause a massive cache line bouncing issue on the futex
variable then the lock contention on hb lock helps to prevent it from
becoming worse. It basically ensures that enough waiters are stuck in
the kernel that the rest of the threads can make progress, even if they
right away after acquiring the hash bucket lock.
Works by chance but certainly not by design :)
next prev parent reply other threads:[~2026-08-25 16:48 UTC|newest]
Thread overview: 17+ 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
2026-08-20 15:19 ` Usama Arif
2026-08-20 16:23 ` Thomas Gleixner
2026-08-20 18:05 ` Usama Arif
2026-08-26 15:22 ` Usama Arif
2026-08-20 16:14 ` Dmitry Ilvokhin
2026-08-21 13:18 ` Thomas Gleixner
2026-08-25 16:48 ` Thomas Gleixner [this message]
2026-08-08 9:19 ` Thomas Gleixner
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=87tsoign80.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