From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ian Rogers <irogers@google.com>,
Kan Liang <kan.liang@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
bpf@vger.kernel.org, Stephane Eranian <eranian@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>, Kees Cook <kees@kernel.org>
Subject: [PATCH v2 0/4] perf lock contention: Symbolize locks using slab cache names
Date: Thu, 7 Nov 2024 22:14:55 -0800 [thread overview]
Message-ID: <20241108061500.2698340-1-namhyung@kernel.org> (raw)
Hello,
This is to support symbolization of dynamic locks using slab
allocator's metadata. The kernel support is in the bpf-next tree now.
It provides the new "kmem_cache" BPF iterator and "bpf_get_kmem_cache"
kfunc to get the information from an address. The feature detection is
done using BTF type info and it won't have any effect on old kernels.
v2 changes)
* don't use libbpf_get_error() (Andrii)
v1) https://lore.kernel.org/linux-perf-users/20241105172635.2463800-1-namhyung@kernel.org
With this change, it can show locks in a slab object like below. I
added "&" sign to distinguish them from global locks.
# perf lock con -abl sleep 1
contended total wait max wait avg wait address symbol
2 1.95 us 1.77 us 975 ns ffff9d5e852d3498 &task_struct (mutex)
1 1.18 us 1.18 us 1.18 us ffff9d5e852d3538 &task_struct (mutex)
4 1.12 us 354 ns 279 ns ffff9d5e841ca800 &kmalloc-cg-512 (mutex)
2 859 ns 617 ns 429 ns ffffffffa41c3620 delayed_uprobe_lock (mutex)
3 691 ns 388 ns 230 ns ffffffffa41c0940 pack_mutex (mutex)
3 421 ns 164 ns 140 ns ffffffffa3a8b3a0 text_mutex (mutex)
1 409 ns 409 ns 409 ns ffffffffa41b4cf8 tracepoint_srcu_srcu_usage (mutex)
2 362 ns 239 ns 181 ns ffffffffa41cf840 pcpu_alloc_mutex (mutex)
1 220 ns 220 ns 220 ns ffff9d5e82b534d8 &signal_cache (mutex)
1 215 ns 215 ns 215 ns ffffffffa41b4c28 tracepoint_srcu_srcu_usage (mutex)
The first two were from "task_struct" slab cache. It happened to
match with the type name of object but there's no guarantee. We need
to add type info to slab cache to resolve the lock inside the object.
Anyway, the third one has no dedicated slab cache and was allocated by
kmalloc.
Those slab objects can be used to filter specific locks using -L or
--lock-filter option. (It needs quotes to avoid special handling in
the shell).
# perf lock con -ab -L '&task_struct' sleep 1
contended total wait max wait avg wait type caller
1 25.10 us 25.10 us 25.10 us mutex perf_event_exit_task+0x39
1 21.60 us 21.60 us 21.60 us mutex futex_exit_release+0x21
1 5.56 us 5.56 us 5.56 us mutex futex_exec_release+0x21
The code is available at 'perf/lock-slab-v2' branch in my tree
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Thanks,
Namhyung
Namhyung Kim (4):
perf lock contention: Add and use LCB_F_TYPE_MASK
perf lock contention: Run BPF slab cache iterator
perf lock contention: Resolve slab object name using BPF
perf lock contention: Handle slab objects in -L/--lock-filter option
tools/perf/builtin-lock.c | 39 ++++-
tools/perf/util/bpf_lock_contention.c | 140 +++++++++++++++++-
.../perf/util/bpf_skel/lock_contention.bpf.c | 70 ++++++++-
tools/perf/util/bpf_skel/lock_data.h | 15 +-
tools/perf/util/bpf_skel/vmlinux/vmlinux.h | 8 +
tools/perf/util/lock-contention.h | 2 +
6 files changed, 267 insertions(+), 7 deletions(-)
--
2.47.0.277.g8800431eea-goog
next reply other threads:[~2024-11-08 6:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 6:14 Namhyung Kim [this message]
2024-11-08 6:14 ` [PATCH v2 1/4] perf lock contention: Add and use LCB_F_TYPE_MASK Namhyung Kim
2024-11-08 6:14 ` [PATCH v2 2/4] perf lock contention: Run BPF slab cache iterator Namhyung Kim
2024-12-09 16:36 ` Arnaldo Carvalho de Melo
2024-12-09 16:38 ` Arnaldo Carvalho de Melo
2024-12-09 20:23 ` Arnaldo Carvalho de Melo
2024-12-09 23:00 ` Andrii Nakryiko
[not found] ` <CA+JHD91Ai_ObUye4Unz2e2Hku2BH5_+0q3HyUtf7ay23uDnkjQ@mail.gmail.com>
2024-12-10 0:23 ` Andrii Nakryiko
2024-12-09 22:16 ` Namhyung Kim
2024-12-09 22:23 ` Ian Rogers
2024-11-08 6:14 ` [PATCH v2 3/4] perf lock contention: Resolve slab object name using BPF Namhyung Kim
2024-11-12 11:09 ` Vlastimil Babka
2024-11-12 14:50 ` Arnaldo Carvalho de Melo
2024-11-13 14:20 ` Vlastimil Babka
2024-11-18 18:45 ` Namhyung Kim
2024-11-08 6:14 ` [PATCH v2 4/4] perf lock contention: Handle slab objects in -L/--lock-filter option Namhyung Kim
2024-11-11 19:46 ` [PATCH v2 0/4] perf lock contention: Symbolize locks using slab cache names Ian Rogers
2024-11-18 18:35 ` Namhyung Kim
2024-12-13 17:10 ` 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=20241108061500.2698340-1-namhyung@kernel.org \
--to=namhyung@kernel.org \
--cc=42.hyeyoo@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=song@kernel.org \
--cc=vbabka@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).