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@xxxxxxxxxx> 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;