From: Namhyung Kim <namhyung@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Ian Rogers <irogers@google.com>,
Kan Liang <kan.liang@linux.intel.com>,
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-use." <linux-perf-users@vger.kernel.org>,
Andrii Nakryiko <andrii@kernel.org>, Song Liu <song@kernel.org>,
bpf <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>,
Chun-Tse Shao <ctshao@google.com>
Subject: Re: [PATCH v3 2/4] perf lock contention: Run BPF slab cache iterator
Date: Sat, 21 Dec 2024 15:55:32 -0800 [thread overview]
Message-ID: <Z2dVdH3o5iF-KrWj@google.com> (raw)
In-Reply-To: <CAADnVQLm-jA5-39-LUKybO2oGbDRr2RgPtJH5iXoeKnYqdJUuw@mail.gmail.com>
Hi Alexei,
On Fri, Dec 20, 2024 at 03:52:36PM -0800, Alexei Starovoitov wrote:
> On Thu, Dec 19, 2024 at 10:01 PM Namhyung Kim <namhyung@kernel.org> wrote:
> > +struct bpf_iter__kmem_cache___new {
> > + struct kmem_cache *s;
> > +} __attribute__((preserve_access_index));
> > +
> > +SEC("iter/kmem_cache")
> > +int slab_cache_iter(void *ctx)
> > +{
> > + struct kmem_cache *s = NULL;
> > + struct slab_cache_data d;
> > + const char *nameptr;
> > +
> > + if (bpf_core_type_exists(struct bpf_iter__kmem_cache)) {
> > + struct bpf_iter__kmem_cache___new *iter = ctx;
> > +
> > + s = BPF_CORE_READ(iter, s);
> > + }
> > +
> > + if (s == NULL)
> > + return 0;
> > +
> > + nameptr = BPF_CORE_READ(s, name);
>
> since the feature depends on the latest kernel please use
> direct access. There is no need to use BPF_CORE_READ() to
> be compatible with old kernels.
> Just iter->s and s->name will work and will be much faster.
> Underneath these loads will be marked with PROBE_MEM flag and
> will be equivalent to probe_read_kernel calls, but faster
> since the whole thing will be inlined by JITs.
Oh, thanks for your review. I thought it was requried, but it'd
be definitely better if we can access them directly. I'll fold
the below to v4, unless Arnaldo does it first. :)
Thanks,
Namhyung
---8<---
diff --git a/tools/perf/util/bpf_skel/lock_contention.bpf.c b/tools/perf/util/bpf_skel/lock_contention.bpf.c
index 6c771ef751d83b43..6533ea9b044c71d1 100644
--- a/tools/perf/util/bpf_skel/lock_contention.bpf.c
+++ b/tools/perf/util/bpf_skel/lock_contention.bpf.c
@@ -635,13 +635,13 @@ int slab_cache_iter(void *ctx)
if (bpf_core_type_exists(struct bpf_iter__kmem_cache)) {
struct bpf_iter__kmem_cache___new *iter = ctx;
- s = BPF_CORE_READ(iter, s);
+ s = iter->s;
}
if (s == NULL)
return 0;
- nameptr = BPF_CORE_READ(s, name);
+ nameptr = s->name;
bpf_probe_read_kernel_str(d.name, sizeof(d.name), nameptr);
d.id = ++slab_cache_id << LCB_F_SLAB_ID_SHIFT;
next prev parent reply other threads:[~2024-12-21 23:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 6:00 [PATCH v3 0/4] perf lock contention: Symbolize locks using slab cache names Namhyung Kim
2024-12-20 6:00 ` [PATCH v3 1/4] perf lock contention: Add and use LCB_F_TYPE_MASK Namhyung Kim
2024-12-20 6:00 ` [PATCH v3 2/4] perf lock contention: Run BPF slab cache iterator Namhyung Kim
2024-12-20 23:52 ` Alexei Starovoitov
2024-12-21 23:55 ` Namhyung Kim [this message]
2024-12-23 16:38 ` Arnaldo Carvalho de Melo
2024-12-20 6:00 ` [PATCH v3 3/4] perf lock contention: Resolve slab object name using BPF Namhyung Kim
2024-12-20 6:00 ` [PATCH v3 4/4] perf lock contention: Handle slab objects in -L/--lock-filter option Namhyung Kim
2024-12-20 19:20 ` [PATCH v3 0/4] perf lock contention: Symbolize locks using slab cache names Arnaldo Carvalho de Melo
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=Z2dVdH3o5iF-KrWj@google.com \
--to=namhyung@kernel.org \
--cc=42.hyeyoo@gmail.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=ctshao@google.com \
--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).