Thread (6 messages) 6 messages, 2 authors, 2019-06-18

Re: [PATCH] mm, memcg: Report number of memcg caches in slabinfo

flat view

From: Michal Hocko <mhocko@kernel.org>
Date: 2019-06-18 12:37:55
Also in: linux-mm, lkml

On Mon 17-06-19 10:50:23, Waiman Long wrote:
On 6/17/19 10:38 AM, Michal Hocko wrote:
quoted
[Cc linux-api]

On Mon 17-06-19 10:21:49, Waiman Long wrote:
quoted
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?
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?
From the user perspective, if the numbers is way above the number of
memcg's, there is probably something wrong there.
-- 
Michal Hocko
SUSE Labs
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help