On 6/18/19 8:37 AM, Michal Hocko wrote: > On Mon 17-06-19 10:50:23, Waiman Long wrote: >> On 6/17/19 10:38 AM, Michal Hocko wrote: >>> [Cc linux-api] >>> >>> On Mon 17-06-19 10:21:49, Waiman Long wrote: >>>> There are concerns about memory leaks from extensive use of memory >>>> cgroups as each memory cgroup creates its own set of kmem caches. There >>>> is a possiblity that the memcg kmem caches may remain even after the >>>> memory cgroup removal. >>>> >>>> Therefore, it will be useful to show how many memcg caches are present >>>> for each of the kmem caches. >>> How is a user going to use that information? Btw. Don't we have an >>> interface to display the number of (dead) cgroups? >> The interface to report dead cgroups is for cgroup v2 (cgroup.stat) >> only. I don't think there is a way to find that for cgroup v1. > Doesn't debug_legacy_files provide the information for both cgroups > APIs? Not really. The debug controller doesn't provide information about the number of dead cgroups, for instance. Of course, we can always add those information there. Also the debug controller is not typically configured into a production kernel. >> Also the >> number of memcg kmem caches may not be the same as the number of >> memcg's. It can range from 0 to above the number of memcg's. So it is >> an interesting number by itself. > Is this useful enough to put into slabinfo? Doesn't this sound more like > a debugfs kinda a thing? I guess it is probably more on the debug side of things. I add it to slabinfo as the data is readily available. It will be much more work if we need to export the data via debugfs. We are seeing the kmem_cache slab growing continuously overtime when running a container-based workloads. Roman's kmem_cache reparenting patch will hopefully solve a major part of the problem, but we still need a way to confirm that by looking at how many memcg kmem_caches are associated with each root kmem_cache. Cheers, Longman
