On Mon 24-06-19 13:42:19, Waiman Long wrote: > With the slub memory allocator, the numbers of active slab objects > reported in /proc/slabinfo are not real because they include objects > that are held by the per-cpu slab structures whether they are actually > used or not. The problem gets worse the more CPUs a system have. For > instance, looking at the reported number of active task_struct objects, > one will wonder where all the missing tasks gone. > > I know it is hard and costly to get a real count of active objects. What exactly is expensive? Why cannot slabinfo reduce the number of active objects by per-cpu cached objects? > So > I am not advocating for that. Instead, this patch extends the > /proc/sys/vm/drop_caches sysctl parameter by using a new bit (bit 3) > to shrink all the kmem slabs which will flush out all the slabs in the > per-cpu structures and give a more accurate view of how much memory are > really used up by the active slab objects. This is a costly operation, > of course, but it gives a way to have a clearer picture of the actual > number of slab objects used, if the need arises. drop_caches is a terrible interface. It destroys all the caching and people are just too easy in using it to solve any kind of problem they think they might have and cause others they might not see immediately. I am strongly discouraging anybody - except for some tests which really do want to see reproducible results without cache effects - from using this interface and therefore I am not really happy to paper over something that might be a real problem with yet another mode. If SLUB indeed caches too aggressively on large machines then this should be fixed. -- Michal Hocko SUSE Labs
