Re: [PATCH v4 3/6] mm: shrinkers: provide shrinkers with names

[Dave Chinner <dchinner@redhat.com>]

On Wed, May 25, 2022 at 01:25:57PM -0700, Roman Gushchin wrote:
> Currently shrinkers are anonymous objects. For debugging purposes they
> can be identified by count/scan function names, but it's not always
> useful: e.g. for superblock's shrinkers it's nice to have at least
> an idea of to which superblock the shrinker belongs.
> 
> This commit adds names to shrinkers. register_shrinker() and
> prealloc_shrinker() functions are extended to take a format and
> arguments to master a name.
> 
> In some cases it's not possible to determine a good name at the time
> when a shrinker is allocated. For such cases shrinker_debugfs_rename()
> is provided.
> 
> After this change the shrinker debugfs directory looks like:
>   $ cd /sys/kernel/debug/shrinker/
>   $ ls
>     dqcache-16          sb-hugetlbfs-17  sb-rootfs-2      sb-tmpfs-49
>     kfree_rcu-0         sb-hugetlbfs-33  sb-securityfs-6  sb-tracefs-13
>     sb-aio-20           sb-iomem-12      sb-selinuxfs-22  sb-xfs:vda1-36
>     sb-anon_inodefs-15  sb-mqueue-21     sb-sockfs-8      sb-zsmalloc-19
>     sb-bdev-3           sb-nsfs-4        sb-sysfs-26      shadow-18
>     sb-bpf-32           sb-pipefs-14     sb-tmpfs-1       thp_deferred_split-10
>     sb-btrfs:vda2-24    sb-proc-25       sb-tmpfs-27      thp_zero-9
>     sb-cgroup2-30       sb-proc-39       sb-tmpfs-29      xfs_buf-vda1-37
>     sb-configfs-23      sb-proc-41       sb-tmpfs-35      xfs_inodegc-vda1-38

sb-xfs:vda1-36
xfs_buf-vda1-37
xfs_inodegc-vda1-38

That's a parsing nightmare right there. Please use the same format
for everything. You have <subsystem>-<type>:<instance>-<id> for
superblock stuff, but <subsys>_<type>-<instance>-<id> for the XFS
stuff. Make it consistent so we aren't reduced to pulling out our
hair trying to parse this in any useful way:

sb-xfs:vda1-36
xfs-buf:vda1-37
xfs-inodegc:vda1-38

FWIW, how we are supposed to know what actually owns these:

sb-tmpfs-1
sb-tmpfs-27
sb-tmpfs-29
sb-tmpfs-35
sb-tmpfs-49

tmpfs-27 might own all the memory - how do we link that back to a
mount point, container, user, workload, etc?

Cheers,

Dave.
-- 
Dave Chinner
dchinner@redhat.com