Re: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg caches
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2019-07-03 00:53:13
Also in:
cgroups, linux-fsdevel, linux-mm, lkml
On Tue, 2 Jul 2019 14:37:30 -0400 Waiman Long [off-list ref] wrote:
Currently, a value of '1" is written to /sys/kernel/slab/<slab>/shrink file to shrink the slab by flushing all the per-cpu slabs and free slabs in partial lists. This applies only to the root caches, though. Extends this capability by shrinking all the child memcg caches and the root cache when a value of '2' is written to the shrink sysfs file.
Why? Please fully describe the value of the proposed feature to or users. Always.
quoted hunk ↗ jump to hunk
...--- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab@@ -429,10 +429,12 @@ KernelVersion: 2.6.22 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The shrink file is written when memory should be reclaimed from - a cache. Empty partial slabs are freed and the partial list is - sorted so the slabs with the fewest available objects are used - first. + A value of '1' is written to the shrink file when memory should + be reclaimed from a cache. Empty partial slabs are freed and + the partial list is sorted so the slabs with the fewest + available objects are used first. When a value of '2' is + written, all the corresponding child memory cgroup caches + should be shrunk as well. All other values are invalid.
One would expect this to be a bitfield, like /proc/sys/vm/drop_caches. So writing 3 does both forms of shrinking. Yes, it happens to be the case that 2 is a superset of 1, but what about if we add "4"?