Message ID | 20220509183820.573666-1-roman.gushchin@linux.dev (mailing list archive) |
---|---|
Headers | show |
Series | mm: introduce shrinker debugfs interface | expand |
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!
On Thu, May 19, 2022 at 10:15:04AM -0700, Roman Gushchin wrote: > 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? I have no time available to look at this right now, and won't for a while. Cheers, Dave.