On Mon, May 09, 2022 at 11:38:14AM -0700, Roman Gushchin wrote: > There are 50+ different shrinkers in the kernel, many with their own bells and > whistles. Under the memory pressure the kernel applies some pressure on each of > them in the order of which they were created/registered in the system. Some > of them can contain only few objects, some can be quite large. Some can be > effective at reclaiming memory, some not. > > The only existing debugging mechanism is a couple of tracepoints in > do_shrink_slab(): mm_shrink_slab_start and mm_shrink_slab_end. They aren't > covering everything though: shrinkers which report 0 objects will never show up, > there is no support for memcg-aware shrinkers. Shrinkers are identified by their > scan function, which is not always enough (e.g. hard to guess which super > block's shrinker it is having only "super_cache_scan"). > > To provide a better visibility and debug options for memory shrinkers > this patchset introduces a /sys/kernel/debug/shrinker interface, to some extent > similar to /sys/kernel/slab. > > For each shrinker registered in the system a directory is created. > As now, the directory will contain only a "scan" file, which allows to get > the number of managed objects for each memory cgroup (for memcg-aware shrinkers) > and each numa node (for numa-aware shrinkers on a numa machine). Other > interfaces might be added in the future. > > To make debugging more pleasant, the patchset also names all shrinkers, > so that debugfs entries can have meaningful names. > > > v3: > 1) separated the "scan" part into a separate patch, by Dave > 2) merged *_memcg, *_node and *_memcg_node interfaces, by Dave > 3) shrinkers naming enhancements, by Christophe and Dave > 4) added signal_pending() check, by Hillf > 5) enabled by default, by Dave Any comments? Thoughts? Objections? Thanks!
