| Message ID | 20190619144610.12520-1-longman@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm, memcg: Add a memcg_slabinfo debugfs file | expand |
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
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
On Wed, Jun 19, 2019 at 8:30 AM Waiman Long <longman@redhat.com> wrote: > > 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. > Yes, it is very verbose but it is only for debugging and normal users should not be (continuously) reading that interface. Shakeel
On 6/19/19 11:35 AM, Shakeel Butt wrote: > On Wed, Jun 19, 2019 at 8:30 AM Waiman Long <longman@redhat.com> wrote: >> 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. >> > Yes, it is very verbose but it is only for debugging and normal users > should not be (continuously) reading that interface. I am not against it. It is just an observation. I still think we can skip kmem caches that don't have any child memcg caches as the information is in slabinfo already. Cheers, Longman
diff --git a/mm/slab_common.c b/mm/slab_common.c index 58251ba63e4a..63fb18f4f811 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -17,6 +17,7 @@ #include <linux/uaccess.h> #include <linux/seq_file.h> #include <linux/proc_fs.h> +#include <linux/debugfs.h> #include <asm/cacheflush.h> #include <asm/tlbflush.h> #include <asm/page.h> @@ -1498,6 +1499,58 @@ static int __init slab_proc_init(void) return 0; } module_init(slab_proc_init); + +#if defined(CONFIG_DEBUG_FS) && defined(CONFIG_MEMCG) +/* + * Display information about slabs that are in memcg kmem caches, but not + * in the root kmem caches. + */ +static int memcg_slabinfo_show(struct seq_file *m, void *unused) +{ + struct kmem_cache *s, *c; + struct slabinfo sinfo, cinfo; + + mutex_lock(&slab_mutex); + seq_puts(m, "# <name> <active_objs> <num_objs> <active_slabs>"); + seq_puts(m, " <num_slabs> <num_caches> <num_empty_caches>\n"); + memset(&sinfo, 0, sizeof(sinfo)); + list_for_each_entry(s, &slab_root_caches, root_caches_node) { + int scnt = 0; /* memcg kmem cache count */ + int ecnt = 0; /* # of empty kmem caches */ + + for_each_memcg_cache(c, s) { + memset(&cinfo, 0, sizeof(cinfo)); + get_slabinfo(c, &cinfo); + + sinfo.active_slabs += cinfo.active_slabs; + sinfo.num_slabs += cinfo.num_slabs; + sinfo.active_objs += cinfo.active_objs; + sinfo.num_objs += cinfo.num_objs; + scnt++; + if (!cinfo.num_slabs) + ecnt++; + } + if (!scnt) + continue; + seq_printf(m, "%-17s %6lu %6lu %6lu %6lu %3d %3d\n", + cache_name(s), sinfo.active_objs, sinfo.num_objs, + sinfo.active_slabs, sinfo.num_slabs, scnt, ecnt); + memset(&sinfo, 0, sizeof(sinfo)); + } + mutex_unlock(&slab_mutex); + return 0; +} +DEFINE_SHOW_ATTRIBUTE(memcg_slabinfo); + +static int __init memcg_slabinfo_init(void) +{ + debugfs_create_file("memcg_slabinfo", S_IFREG | S_IRUGO, + NULL, NULL, &memcg_slabinfo_fops); + return 0; +} + +late_initcall(memcg_slabinfo_init); +#endif /* CONFIG_DEBUG_FS && CONFIG_MEMCG */ #endif /* CONFIG_SLAB || CONFIG_SLUB_DEBUG */ static __always_inline void *__do_krealloc(const void *p, size_t new_size,
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. A portion of a sample output of the file was: # <name> <active_objs> <num_objs> <active_slabs> <num_slabs> <num_caches> <num_empty_caches> rpc_inode_cache 0 0 0 0 1 1 xfs_inode 6342 7888 232 232 59 13 RAWv6 0 0 0 0 2 2 UDPv6 100 100 4 4 5 3 TCPv6 0 0 0 0 1 1 UNIX 4864 4864 152 152 53 35 RAW 0 0 0 0 1 1 TCP 14 14 1 1 2 1 Besides the number of objects and slabs in the memcg kmem caches only, it also shows the total number of memcg kmem caches associated with each root kmem cache as well as the number memcg kmem caches that are empty. Signed-off-by: Waiman Long <longman@redhat.com> --- mm/slab_common.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)