From: Waiman Long <longman@redhat.com>
To: Shakeel Butt <shakeelb@google.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@kernel.org>, Roman Gushchin <guro@fb.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH] mm, memcg: Add a memcg_slabinfo debugfs file
Date: Wed, 19 Jun 2019 11:30:16 -0400 [thread overview]
Message-ID: <20831975-590f-ecab-53db-5d7e6b1a053f@redhat.com> (raw)
In-Reply-To: <CALvZod5yHbtYe2x3TGQKGtxjvTDpAGjvSc8Pvphbn00pdRfs2g@mail.gmail.com>
On 6/19/19 11:18 AM, Shakeel Butt wrote:
> On Wed, Jun 19, 2019 at 7:46 AM Waiman Long <longman@redhat.com> 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.
>>
>> This patch introduces a new <debugfs>/memcg_slabinfo file which is
>> somewhat similar to /proc/slabinfo in format, but lists only slabs that
>> are in memcg kmem caches. Information available in /proc/slabinfo are
>> not repeated in memcg_slabinfo.
>>
> At Google, we have an interface /proc/slabinfo_full which shows each
> kmem cache (root and memcg) on a separate line i.e. no accumulation.
> This interface has helped us a lot for debugging zombies and memory
> leaks. The name of the memcg kmem caches include the memcg name, css
> id and "dead" for offlined memcgs. I think these extra information is
> much more useful for debugging. What do you think?
>
> Shakeel
Yes, I think that can be a good idea. My only concern is that it can be
very verbose. Will work on a v2 patch.
Thanks,
Longman
next prev parent reply other threads:[~2019-06-19 15:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 14:46 Waiman Long
2019-06-19 15:18 ` Shakeel Butt
2019-06-19 15:30 ` Waiman Long [this message]
2019-06-19 15:35 ` Shakeel Butt
2019-06-19 15:47 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20831975-590f-ecab-53db-5d7e6b1a053f@redhat.com \
--to=longman@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox