From: Tim Menninger <tmenninger@everpuredata.com>
To: Harry Yoo <harry@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org, Chuck Lever <cel@kernel.org>,
linux-nfs@vger.kernel.org, Jon Curley <jcurley@everpuredata.com>,
Eric Badger <ebadger@everpuredata.com>,
Andrew Morton <akpm@linux-foundation.org>,
Hao Li <hao.li@linux.dev>, Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
James Clark <james.clark@linaro.org>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [SLUB] nfs_page cmpxchg_double_fail and perf lock perturbation on dual-socket NFS/RDMA
Date: Mon, 21 Sep 2026 23:27:02 +0000 [thread overview]
Message-ID: <20260921232702.486161-1-tmenninger@everpuredata.com> (raw)
In-Reply-To: <arFNKeseUHBvdRCA@thinkstation>
> Did any of that change with slab_nomerge?
No. The large change in the SLUB counters still reproduced with
slab_nomerge when using perf lock record. For example:
uninstrumented perf lock record
unpinned/node0
free_fastpath 75,366,487 646,378,908
free_slowpath 41,594,255 259,704,037
node0/node0
free_fastpath 119,705,541 440,896,371
free_slowpath 6,344 6,679,339
unpinned/balanced
free_fastpath 59,404,047 384,715,890
free_slowpath 60,602,379 324,936,304
> ... unless perf lock was writing data to an NFS filesystem?
It was not. The perf data file was on the local root filesystem:
$ df -T linux-mm/
Filesystem Type
/dev/mapper/ubuntu--vg-ubuntu--lv ext4
> You can use the BPF version of perf lock to check lock contention like
> below. (it only work with 'contention' subcommand.)
>
> $ sudo perf lock con -ab sleep 10
>
> or
>
> $ sudo perf lock con -ab -E 5 sleep 10
I reran the three placement cases using the BPF version, aggregating
by lock address:
sudo perf lock con -abl -E 5 -- sleep 10
I ran only perf lock and mpstat concurrently.
The BPF version is substantially less disruptive. Comparing adjacent
10-second uninstrumented and instrumented windows:
uninstrumented BPF perf lock
unpinned/node0
throughput 45.5 GB/s 43-44 GB/s
free_fastpath 76,217,260 118,511,381
free_slowpath 39,962,005 22,717,811
cmpxchg_double_fail 9,299 9,587
system idle 22.74% 10.61%
node0/node0
throughput 46.5 GB/s 46.5 GB/s
free_fastpath 119,739,790 148,686,356
free_slowpath 5,686 8,791
cmpxchg_double_fail 1,483 3,170
system idle 83.33% 82.42%
unpinned/balanced
throughput 46.5 GB/s 46.5 GB/s
free_fastpath 59,341,738 92,824,030
free_slowpath 60,000,396 60,658,896
cmpxchg_double_fail 1,742 23,772
system idle 68.27% 50.03%
The per-lock-address BPF results are also quite different from the
perf lock record results:
unpinned/node0:
contended total wait avg wait address
8,345,025 12.27 min 88.23 us ff3ad60e50e85100
node0/node0:
contended total wait avg wait address
6,461,976 30.70 sec 4.75 us ff3ad58ecf36ac80
unpinned/balanced:
contended total wait avg wait address
6,592,568 6.50 min 59.18 us ff3ad60e50e85100
143,397 666.98 ms 4.65 us ff3ad58ecf36ac80
perf identifies these as kmem_cache_node spinlocks.
next prev parent reply other threads:[~2026-09-21 23:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260916232227.4098143-1-tmenninger@everpuredata.com>
[not found] ` <aqvq8-6IJBDer90O@thinkstation>
2026-09-17 14:10 ` Harry Yoo
2026-09-17 15:29 ` Peter Zijlstra
2026-09-18 7:04 ` Namhyung Kim
2026-09-17 16:25 ` Tim Menninger
2026-09-18 7:08 ` Vlastimil Babka (SUSE)
2026-09-21 15:31 ` Harry Yoo
2026-09-21 23:27 ` Tim Menninger [this message]
2026-09-18 7:14 ` Namhyung Kim
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=20260921232702.486161-1-tmenninger@everpuredata.com \
--to=tmenninger@everpuredata.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=cel@kernel.org \
--cc=cl@gentwo.org \
--cc=ebadger@everpuredata.com \
--cc=hao.li@linux.dev \
--cc=harry@kernel.org \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jcurley@everpuredata.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@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
all inboxes | Powered by JetHome®