On 6/18/19 2:32 PM, Michal Hocko wrote: > On Tue 18-06-19 12:59:24, Waiman Long wrote: >> On 6/18/19 8:37 AM, Michal Hocko wrote: > [...] >>> 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
