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

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

flat view

From: Waiman Long <longman@redhat.com>
Date: 2019-06-18 19:27:29
Also in: linux-mm, lkml

On 6/18/19 2:32 PM, Michal Hocko wrote:
On Tue 18-06-19 12:59:24, Waiman Long wrote:
quoted
On 6/18/19 8:37 AM, Michal Hocko wrote:
[...]
quoted
quoted
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.
I am not disputing usefulness. Dead memcgs are showing up as a problem
for a longer time and having a more debugging information is definitely
useful. I am just not really sure that /proc/slabinfo is the proper
vehicle for that information. It might be just easier to stick it there
but that is not the best justification for adding something we will have
to maintain for ever. Not to mention that the number of dead memcgs
might not be enough to debug further when we can easily end up needing
to provide more in something less "carved in stone" kinda interface like
debugfs.
Fair enough.

I will rework the patch and expose the information via debugfs then.

Cheers,
Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help