From: Breno Leitao <leitao@debian.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Thomas Gleixner" <tglx@kernel.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Darren Hart" <dvhart@infradead.org>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"André Almeida" <andrealmeid@igalia.com>,
linux-kernel@vger.kernel.org, puranjay@kernel.org,
rmikey@meta.com, stuclar@meta.com, namhyung@kernel.org,
kernel-team@meta.com, dcostantino@meta.com
Subject: Re: [PATCH RFC] futex: avoid false sharing between hb->chain and the bucket lock
Date: Tue, 23 Jun 2026 03:30:07 -0700 [thread overview]
Message-ID: <ajpfO-trw3X8Z3RL@gmail.com> (raw)
In-Reply-To: <ailsiFU1Ul8j8qXG@gmail.com>
On Wed, Jun 10, 2026 at 06:56:12AM -0700, Breno Leitao wrote:
> .. same machine I used earlier 176-thread AMD EPYC host, 10s perf bench
> futex hash per run, baseline = parent commit (acb7500801e98):
I tested this on a large AI machine (NVIDIA GB200 NVL72), and the results
show the highest gains observed so far.
Test setup:
Each kernel was measured over 5 runs of the default workload (144 threads,
1024 private futexes per thread, 10s per run; the futex hash auto-resized to
1024 buckets in both cases).
Results:
The optimization shows a clear, repeatable win on this hardware. The baseline
averaged 1,149,586 ops/sec (range 1.14M-1.17M) while the patched kernel
averaged 1,764,233 ops/sec (range 1.75M-1.77M) — a ~53% throughput improvement
(1.53x).
Run-to-run variance was low (~1%) and the two distributions did not
overlap at all (baseline max sits well below the patched minimum), confirming
the gain is statistically significant.
next prev parent reply other threads:[~2026-06-23 10:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 16:53 [PATCH RFC] futex: avoid false sharing between hb->chain and the bucket lock Breno Leitao
2026-06-09 10:46 ` Peter Zijlstra
2026-06-09 15:28 ` Breno Leitao
2026-06-09 20:11 ` Peter Zijlstra
2026-06-09 20:18 ` Peter Zijlstra
2026-06-10 11:22 ` Thomas Gleixner
2026-06-10 11:25 ` Peter Zijlstra
2026-06-10 13:55 ` Peter Zijlstra
2026-06-12 7:11 ` [tip: locking/core] futex: Optimize futex hash bucket access patterns tip-bot2 for Peter Zijlstra
2026-06-12 8:13 ` Breno Leitao
2026-06-10 13:56 ` [PATCH RFC] futex: avoid false sharing between hb->chain and the bucket lock Breno Leitao
2026-06-23 10:30 ` Breno Leitao [this message]
2026-06-09 20:16 ` Thomas Gleixner
2026-06-09 20:23 ` Peter Zijlstra
2026-06-09 20:25 ` Peter Zijlstra
2026-06-09 20:32 ` 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=ajpfO-trw3X8Z3RL@gmail.com \
--to=leitao@debian.org \
--cc=andrealmeid@igalia.com \
--cc=dave@stgolabs.net \
--cc=dcostantino@meta.com \
--cc=dvhart@infradead.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=puranjay@kernel.org \
--cc=rmikey@meta.com \
--cc=stuclar@meta.com \
--cc=tglx@kernel.org \
/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