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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.