Hello,

I'm proposing a new iterator and a kfunc for the slab memory allocator
to get information of each kmem_cache like in /proc/slabinfo or
/sys/kernel/slab.  Maybe I need to call it kmem_cache iter but slab
was short and easier to call. :)

My use case is `perf lock contention` tool which shows contended locks
but many of them are not global locks and don't have symbols.  If it
can tranlate the address of the lock in a slab object to the name of
the slab, it'd be much more useful.

I'm not aware of type information in slab yet, but I was told there's
a work to associate BTF ID with it.  It'd be definitely helpful to my
use case.  Probably we need another kfunc to get the start address of
the object or the offset in the object from an address if the type
info is available.  But I want to start with a simple thing first.

The slab_iter iterates kmem_cache objects under slab_mutex and will be
useful for userspace to prepare some work for specific slabs like
setting up filters in advance.  And the bpf_get_slab_cache() kfunc
will return a pointer to a slab from the address of a lock.  And the
test code is to read from the iterator and make sure it finds a slab
cache of the task_struct for the current task.

The code is available at 'bpf/slab-iter-v1' branch in
https://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (3):
  bpf: Add slab iterator
  mm/bpf: Add bpf_get_slab_cache() kfunc
  selftests/bpf: Add a test for slab_iter

 include/linux/btf_ids.h                       |   1 +
 kernel/bpf/Makefile                           |   1 +
 kernel/bpf/helpers.c                          |   1 +
 kernel/bpf/slab_iter.c                        | 131 ++++++++++++++++++
 mm/slab_common.c                              |  14 ++
 .../selftests/bpf/prog_tests/slab_iter.c      |  64 +++++++++
 tools/testing/selftests/bpf/progs/bpf_iter.h  |   7 +
 tools/testing/selftests/bpf/progs/slab_iter.c |  62 +++++++++
 8 files changed, 281 insertions(+)
 create mode 100644 kernel/bpf/slab_iter.c
 create mode 100644 tools/testing/selftests/bpf/prog_tests/slab_iter.c
 create mode 100644 tools/testing/selftests/bpf/progs/slab_iter.c

-- 
2.46.0.792.g87dc391469-goog

On Wed, Sep 25, 2024 at 03:30:20PM -0700, Namhyung Kim wrote:
> Hello,
> 
> I'm proposing a new iterator and a kfunc for the slab memory allocator
> to get information of each kmem_cache like in /proc/slabinfo or
> /sys/kernel/slab.

Hello, Namhyung!

I personally like the idea very much. With a growing number of kmem_caches
/proc/slabinfo getting close to it's limit, so having a more flexible
interface makes a lot of sense.

> Maybe I need to call it kmem_cache iter but slab
> was short and easier to call. :)

I'd personally prefer kmem_cache or slab_cache, just in case somebody later
would propose an iterator over individual slab objects within a kmem_cache.

Acked-by: Roman Gushchin <roman.gushchin@linux.dev> (mm/*)

Thanks!

On 9/26/24 02:16, Roman Gushchin wrote:
> On Wed, Sep 25, 2024 at 03:30:20PM -0700, Namhyung Kim wrote:
>> Hello,
>> 
>> I'm proposing a new iterator and a kfunc for the slab memory allocator
>> to get information of each kmem_cache like in /proc/slabinfo or
>> /sys/kernel/slab.
> 
> Hello, Namhyung!
> 
> I personally like the idea very much. With a growing number of kmem_caches
> /proc/slabinfo getting close to it's limit, so having a more flexible
> interface makes a lot of sense.
> 
>> Maybe I need to call it kmem_cache iter but slab
>> was short and easier to call. :)
> 
> I'd personally prefer kmem_cache or slab_cache, just in case somebody later
> would propose an iterator over individual slab objects within a kmem_cache.

Yeah it would be better. Even though I doubt an iterator of slabs or objects
would be really feasible.

> Acked-by: Roman Gushchin <roman.gushchin@linux.dev> (mm/*)

Acked-by: Vlastimil Babka <vbabka@suse.cz> #mm/slab

> 
> Thanks!

On Thu, Sep 26, 2024 at 12:16:15AM +0000, Roman Gushchin wrote:
> On Wed, Sep 25, 2024 at 03:30:20PM -0700, Namhyung Kim wrote:
> > Hello,
> > 
> > I'm proposing a new iterator and a kfunc for the slab memory allocator
> > to get information of each kmem_cache like in /proc/slabinfo or
> > /sys/kernel/slab.
> 
> Hello, Namhyung!

Hello Roman!

> 
> I personally like the idea very much. With a growing number of kmem_caches
> /proc/slabinfo getting close to it's limit, so having a more flexible
> interface makes a lot of sense.
> 
> > Maybe I need to call it kmem_cache iter but slab
> > was short and easier to call. :)
> 
> I'd personally prefer kmem_cache or slab_cache, just in case somebody later
> would propose an iterator over individual slab objects within a kmem_cache.

I think we can add a parameter to limit or extend the functionality
like task iter and cgroup iter.  But I'm not sure we need to use a
different name for that.  Anyway I'm ok to rename it kmem_cache iter.

> 
> Acked-by: Roman Gushchin <roman.gushchin@linux.dev> (mm/*)

Thanks for your review!
Namhyung