| Message ID | 20190626165614.18586-1-longman@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | memcg: Add kmem.slabinfo to v2 for debugging purpose | expand |
On Wed, 26 Jun 2019 12:56:14 -0400 Waiman Long <longman@redhat.com> wrote: > With memory cgroup v1, there is a kmem.slabinfo file that can be > used to view what slabs are allocated to the memory cgroup. There > is currently no such equivalent in memory cgroup v2. This file can > be useful for debugging purpose. > > This patch adds an equivalent kmem.slabinfo to v2 with the caveat that > this file will only show up as ".__DEBUG__.memory.kmem.slabinfo" when the > "cgroup_debug" parameter is specified in the kernel boot command line. > This is to avoid cluttering the cgroup v2 interface with files that > are seldom used by end users. > > ... > > mm/memcontrol.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) A change to the kernel's user interface triggers a change to the kernel's user interface documentation. This should be automatic by now :(
On 6/26/19 6:25 PM, Andrew Morton wrote: > On Wed, 26 Jun 2019 12:56:14 -0400 Waiman Long <longman@redhat.com> wrote: > >> With memory cgroup v1, there is a kmem.slabinfo file that can be >> used to view what slabs are allocated to the memory cgroup. There >> is currently no such equivalent in memory cgroup v2. This file can >> be useful for debugging purpose. >> >> This patch adds an equivalent kmem.slabinfo to v2 with the caveat that >> this file will only show up as ".__DEBUG__.memory.kmem.slabinfo" when the >> "cgroup_debug" parameter is specified in the kernel boot command line. >> This is to avoid cluttering the cgroup v2 interface with files that >> are seldom used by end users. >> >> ... >> >> mm/memcontrol.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) > A change to the kernel's user interface triggers a change to the > kernel's user interface documentation. This should be automatic by > now :( > > We don't usually document debugging only files as they are subject to change with no stability guarantee. That is the point of marking it for debugging instead of a regular file that we need to support forever. Cheers, Longman
Hello, Waiman. On Wed, Jun 26, 2019 at 12:56:14PM -0400, Waiman Long wrote: > With memory cgroup v1, there is a kmem.slabinfo file that can be > used to view what slabs are allocated to the memory cgroup. There > is currently no such equivalent in memory cgroup v2. This file can > be useful for debugging purpose. > > This patch adds an equivalent kmem.slabinfo to v2 with the caveat that > this file will only show up as ".__DEBUG__.memory.kmem.slabinfo" when the > "cgroup_debug" parameter is specified in the kernel boot command line. > This is to avoid cluttering the cgroup v2 interface with files that > are seldom used by end users. Can you please take a look at drgn? https://github.com/osandov/drgn Baking in debug interface files always is limited and nasty and drgn can get you way more flexible debugging / monitoring tool w/o having to bake in anything into the kernel. For an example, please take a look at https://lore.kernel.org/bpf/20190614015620.1587672-10-tj@kernel.org/ Thanks.
On 6/27/19 10:20 AM, Tejun Heo wrote: > Hello, Waiman. > > On Wed, Jun 26, 2019 at 12:56:14PM -0400, Waiman Long wrote: >> With memory cgroup v1, there is a kmem.slabinfo file that can be >> used to view what slabs are allocated to the memory cgroup. There >> is currently no such equivalent in memory cgroup v2. This file can >> be useful for debugging purpose. >> >> This patch adds an equivalent kmem.slabinfo to v2 with the caveat that >> this file will only show up as ".__DEBUG__.memory.kmem.slabinfo" when the >> "cgroup_debug" parameter is specified in the kernel boot command line. >> This is to avoid cluttering the cgroup v2 interface with files that >> are seldom used by end users. > Can you please take a look at drgn? > > https://github.com/osandov/drgn > > Baking in debug interface files always is limited and nasty and drgn > can get you way more flexible debugging / monitoring tool w/o having > to bake in anything into the kernel. For an example, please take a > look at > > https://lore.kernel.org/bpf/20190614015620.1587672-10-tj@kernel.org/ > > Thanks. > Thanks for the information. Will take a serious look at that. Cheers, Longman
diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ba9138a4a1de..236554a23f8f 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5812,6 +5812,22 @@ static struct cftype memory_files[] = { .seq_show = memory_oom_group_show, .write = memory_oom_group_write, }, +#ifdef CONFIG_MEMCG_KMEM + { + /* + * This file is for debugging purpose only and will show + * up as ".__DEBUG__.memory.kmem.slabinfo" when the + * "cgroup_debug" parameter is specified in the kernel + * boot command line. + */ + .name = "kmem.slabinfo", + .flags = CFTYPE_NOT_ON_ROOT | CFTYPE_DEBUG, + .seq_start = memcg_slab_start, + .seq_next = memcg_slab_next, + .seq_stop = memcg_slab_stop, + .seq_show = memcg_slab_show, + }, +#endif { } /* terminate */ };
With memory cgroup v1, there is a kmem.slabinfo file that can be used to view what slabs are allocated to the memory cgroup. There is currently no such equivalent in memory cgroup v2. This file can be useful for debugging purpose. This patch adds an equivalent kmem.slabinfo to v2 with the caveat that this file will only show up as ".__DEBUG__.memory.kmem.slabinfo" when the "cgroup_debug" parameter is specified in the kernel boot command line. This is to avoid cluttering the cgroup v2 interface with files that are seldom used by end users. Signed-off-by: Waiman Long <longman@redhat.com> --- mm/memcontrol.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)