[v6,10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo

Commit Message

Roman Gushchin June 8, 2020, 11:06 p.m. UTC

Deprecate memory.kmem.slabinfo.

An empty file will be presented if corresponding config options are
enabled.

The interface is implementation dependent, isn't present in cgroup v2,
and is generally useful only for core mm debugging purposes. In other
words, it doesn't provide any value for the absolute majority of users.

A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
and also allows to get any additional information without a need
to recompile the kernel.

If a drgn-based solution is too slow for a task, a bpf-based tracing
tool can be used, which can easily keep track of all slab allocations
belonging to a memory cgroup.

Signed-off-by: Roman Gushchin <[e-mail]>
Acked-by: Johannes Weiner <[e-mail]>
Reviewed-by: Vlastimil Babka <[e-mail]>
---
 mm/memcontrol.c  |  3 ---
 mm/slab_common.c | 31 ++++---------------------------
 2 files changed, 4 insertions(+), 30 deletions(-)

Comments

Shakeel Butt June 22, 2020, 5:12 p.m. UTC | #1

On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <[e-mail]> wrote:
>
> Deprecate memory.kmem.slabinfo.
>
> An empty file will be presented if corresponding config options are
> enabled.
>
> The interface is implementation dependent, isn't present in cgroup v2,
> and is generally useful only for core mm debugging purposes. In other
> words, it doesn't provide any value for the absolute majority of users.
>
> A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> and also allows to get any additional information without a need
> to recompile the kernel.
>
> If a drgn-based solution is too slow for a task, a bpf-based tracing
> tool can be used, which can easily keep track of all slab allocations
> belonging to a memory cgroup.
>
> Signed-off-by: Roman Gushchin <[e-mail]>
> Acked-by: Johannes Weiner <[e-mail]>
> Reviewed-by: Vlastimil Babka <[e-mail]>

Hi Roman,

I am not against removing the memory.kmem.slabinfo interface but I
would like to have an alternative solution more accessible than
tools/cgroup/slabinfo.py.

In our case, we don't have ssh access and if we need something for
debugging, it is much more preferable to provide a file to read to
SREs. After the review, that file will be added to a whitelist and
then we can directly read that file through automated tools without
approval for each request.

I am just wondering if a file interface can be provided for whatever
tools/cgroup/slabinfo.py is providing.

Shakeel

Roman Gushchin June 22, 2020, 6:01 p.m. UTC | #2

On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <[e-mail]> wrote:
> >
> > Deprecate memory.kmem.slabinfo.
> >
> > An empty file will be presented if corresponding config options are
> > enabled.
> >
> > The interface is implementation dependent, isn't present in cgroup v2,
> > and is generally useful only for core mm debugging purposes. In other
> > words, it doesn't provide any value for the absolute majority of users.
> >
> > A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> > and also allows to get any additional information without a need
> > to recompile the kernel.
> >
> > If a drgn-based solution is too slow for a task, a bpf-based tracing
> > tool can be used, which can easily keep track of all slab allocations
> > belonging to a memory cgroup.
> >
> > Signed-off-by: Roman Gushchin <[e-mail]>
> > Acked-by: Johannes Weiner <[e-mail]>
> > Reviewed-by: Vlastimil Babka <[e-mail]>
> 
> Hi Roman,
> 
> I am not against removing the memory.kmem.slabinfo interface but I
> would like to have an alternative solution more accessible than
> tools/cgroup/slabinfo.py.
> 
> In our case, we don't have ssh access and if we need something for
> debugging, it is much more preferable to provide a file to read to
> SREs. After the review, that file will be added to a whitelist and
> then we can directly read that file through automated tools without
> approval for each request.
> 
> I am just wondering if a file interface can be provided for whatever
> tools/cgroup/slabinfo.py is providing.
> 
> Shakeel

Hello, Shakeel!

I understand your point, but Idk how much we wanna make this code a part
of the kernel and the cgroup interface. The problem is that reading
from it will be really slow in comparison to all other cgroup interface
files. Idk if Google's version of SLAB has a list of all slab pages,
but if not (as in generic SLUB case), it requires scanning of the whole RAM.
So it's not suitable for periodic reading "just in case". But also
the absolute majority of users don't need this information.

If for some reason you're not comfortable with deploying drgn, it's fairly
easy to write a small standalone tool (similar to page-types), which will
do the trick. Maybe it can work for you?

Thanks!

Shakeel Butt June 22, 2020, 6:09 p.m. UTC | #3

On Mon, Jun 22, 2020 at 11:02 AM Roman Gushchin <[e-mail]> wrote:
>
> On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote:
> > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <[e-mail]> wrote:
> > >
> > > Deprecate memory.kmem.slabinfo.
> > >
> > > An empty file will be presented if corresponding config options are
> > > enabled.
> > >
> > > The interface is implementation dependent, isn't present in cgroup v2,
> > > and is generally useful only for core mm debugging purposes. In other
> > > words, it doesn't provide any value for the absolute majority of users.
> > >
> > > A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> > > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> > > and also allows to get any additional information without a need
> > > to recompile the kernel.
> > >
> > > If a drgn-based solution is too slow for a task, a bpf-based tracing
> > > tool can be used, which can easily keep track of all slab allocations
> > > belonging to a memory cgroup.
> > >
> > > Signed-off-by: Roman Gushchin <[e-mail]>
> > > Acked-by: Johannes Weiner <[e-mail]>
> > > Reviewed-by: Vlastimil Babka <[e-mail]>
> >
> > Hi Roman,
> >
> > I am not against removing the memory.kmem.slabinfo interface but I
> > would like to have an alternative solution more accessible than
> > tools/cgroup/slabinfo.py.
> >
> > In our case, we don't have ssh access and if we need something for
> > debugging, it is much more preferable to provide a file to read to
> > SREs. After the review, that file will be added to a whitelist and
> > then we can directly read that file through automated tools without
> > approval for each request.
> >
> > I am just wondering if a file interface can be provided for whatever
> > tools/cgroup/slabinfo.py is providing.
> >
> > Shakeel
>
> Hello, Shakeel!
>
> I understand your point, but Idk how much we wanna make this code a part
> of the kernel and the cgroup interface.

No need for the cgroup interface. I was thinking of a new interface
like /proc/slabinfo_full which tells active objects for each
kmem_cache and memcg pair.

> The problem is that reading
> from it will be really slow in comparison to all other cgroup interface
> files. Idk if Google's version of SLAB has a list of all slab pages,
> but if not (as in generic SLUB case), it requires scanning of the whole RAM.

That's a bummer. Does drgn-based script scan the whole RAM?

Roman Gushchin June 22, 2020, 6:25 p.m. UTC | #4

On Mon, Jun 22, 2020 at 11:09:47AM -0700, Shakeel Butt wrote:
> On Mon, Jun 22, 2020 at 11:02 AM Roman Gushchin <[e-mail]> wrote:
> >
> > On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote:
> > > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <[e-mail]> wrote:
> > > >
> > > > Deprecate memory.kmem.slabinfo.
> > > >
> > > > An empty file will be presented if corresponding config options are
> > > > enabled.
> > > >
> > > > The interface is implementation dependent, isn't present in cgroup v2,
> > > > and is generally useful only for core mm debugging purposes. In other
> > > > words, it doesn't provide any value for the absolute majority of users.
> > > >
> > > > A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> > > > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> > > > and also allows to get any additional information without a need
> > > > to recompile the kernel.
> > > >
> > > > If a drgn-based solution is too slow for a task, a bpf-based tracing
> > > > tool can be used, which can easily keep track of all slab allocations
> > > > belonging to a memory cgroup.
> > > >
> > > > Signed-off-by: Roman Gushchin <[e-mail]>
> > > > Acked-by: Johannes Weiner <[e-mail]>
> > > > Reviewed-by: Vlastimil Babka <[e-mail]>
> > >
> > > Hi Roman,
> > >
> > > I am not against removing the memory.kmem.slabinfo interface but I
> > > would like to have an alternative solution more accessible than
> > > tools/cgroup/slabinfo.py.
> > >
> > > In our case, we don't have ssh access and if we need something for
> > > debugging, it is much more preferable to provide a file to read to
> > > SREs. After the review, that file will be added to a whitelist and
> > > then we can directly read that file through automated tools without
> > > approval for each request.
> > >
> > > I am just wondering if a file interface can be provided for whatever
> > > tools/cgroup/slabinfo.py is providing.
> > >
> > > Shakeel
> >
> > Hello, Shakeel!
> >
> > I understand your point, but Idk how much we wanna make this code a part
> > of the kernel and the cgroup interface.
> 
> No need for the cgroup interface. I was thinking of a new interface
> like /proc/slabinfo_full which tells active objects for each
> kmem_cache and memcg pair.

To me it's a perfect example where tools like drgn and bpf shine.
They are more flexible and do not blow the kernel up with
the debug-only code.

> 
> > The problem is that reading
> > from it will be really slow in comparison to all other cgroup interface
> > files. Idk if Google's version of SLAB has a list of all slab pages,
> > but if not (as in generic SLUB case), it requires scanning of the whole RAM.
> 
> That's a bummer. Does drgn-based script scan the whole RAM?

To be precise, not over all RAM, but over all struct pages.
Unfortunately, there is no better option with SLUB, as there is no
comprehensive list of slab pages available. So the only option is to scan
over all pages with PageSlab flag set.

Thanks!

Shakeel Butt June 22, 2020, 6:38 p.m. UTC | #5

On Mon, Jun 22, 2020 at 11:25 AM Roman Gushchin <[e-mail]> wrote:
>
> On Mon, Jun 22, 2020 at 11:09:47AM -0700, Shakeel Butt wrote:
> > On Mon, Jun 22, 2020 at 11:02 AM Roman Gushchin <[e-mail]> wrote:
> > >
> > > On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote:
> > > > On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <[e-mail]> wrote:
> > > > >
> > > > > Deprecate memory.kmem.slabinfo.
> > > > >
> > > > > An empty file will be presented if corresponding config options are
> > > > > enabled.
> > > > >
> > > > > The interface is implementation dependent, isn't present in cgroup v2,
> > > > > and is generally useful only for core mm debugging purposes. In other
> > > > > words, it doesn't provide any value for the absolute majority of users.
> > > > >
> > > > > A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> > > > > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> > > > > and also allows to get any additional information without a need
> > > > > to recompile the kernel.
> > > > >
> > > > > If a drgn-based solution is too slow for a task, a bpf-based tracing
> > > > > tool can be used, which can easily keep track of all slab allocations
> > > > > belonging to a memory cgroup.
> > > > >
> > > > > Signed-off-by: Roman Gushchin <[e-mail]>
> > > > > Acked-by: Johannes Weiner <[e-mail]>
> > > > > Reviewed-by: Vlastimil Babka <[e-mail]>
> > > >
> > > > Hi Roman,
> > > >
> > > > I am not against removing the memory.kmem.slabinfo interface but I
> > > > would like to have an alternative solution more accessible than
> > > > tools/cgroup/slabinfo.py.
> > > >
> > > > In our case, we don't have ssh access and if we need something for
> > > > debugging, it is much more preferable to provide a file to read to
> > > > SREs. After the review, that file will be added to a whitelist and
> > > > then we can directly read that file through automated tools without
> > > > approval for each request.
> > > >
> > > > I am just wondering if a file interface can be provided for whatever
> > > > tools/cgroup/slabinfo.py is providing.
> > > >
> > > > Shakeel
> > >
> > > Hello, Shakeel!
> > >
> > > I understand your point, but Idk how much we wanna make this code a part
> > > of the kernel and the cgroup interface.
> >
> > No need for the cgroup interface. I was thinking of a new interface
> > like /proc/slabinfo_full which tells active objects for each
> > kmem_cache and memcg pair.
>
> To me it's a perfect example where tools like drgn and bpf shine.
> They are more flexible and do not blow the kernel up with
> the debug-only code.
>
> >
> > > The problem is that reading
> > > from it will be really slow in comparison to all other cgroup interface
> > > files. Idk if Google's version of SLAB has a list of all slab pages,
> > > but if not (as in generic SLUB case), it requires scanning of the whole RAM.
> >
> > That's a bummer. Does drgn-based script scan the whole RAM?
>
> To be precise, not over all RAM, but over all struct pages.
> Unfortunately, there is no better option with SLUB, as there is no
> comprehensive list of slab pages available. So the only option is to scan
> over all pages with PageSlab flag set.
>

So, SLUB does not have any field available in the struct page to
support the list of slab pages?

Anyways, that's a separate discussion.

Reviewed-by: Shakeel Butt <[e-mail]>

Patch

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index f0ea0ce6bea5..004a31941a88 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5116,9 +5116,6 @@  static struct cftype mem_cgroup_legacy_files[] = {
 	(defined(CONFIG_SLAB) || defined(CONFIG_SLUB_DEBUG))
 	{
 		.name = "kmem.slabinfo",
-		.seq_start = memcg_slab_start,
-		.seq_next = memcg_slab_next,
-		.seq_stop = memcg_slab_stop,
 		.seq_show = memcg_slab_show,
 	},
 #endif
diff --git a/mm/slab_common.c b/mm/slab_common.c
index b578ae29c743..3c89c2adc930 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -1523,35 +1523,12 @@  void dump_unreclaimable_slab(void)
 }
 
 #if defined(CONFIG_MEMCG_KMEM)
-void *memcg_slab_start(struct seq_file *m, loff_t *pos)
-{
-	struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
-
-	mutex_lock(&slab_mutex);
-	return seq_list_start(&memcg->kmem_caches, *pos);
-}
-
-void *memcg_slab_next(struct seq_file *m, void *p, loff_t *pos)
-{
-	struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
-
-	return seq_list_next(p, &memcg->kmem_caches, pos);
-}
-
-void memcg_slab_stop(struct seq_file *m, void *p)
-{
-	mutex_unlock(&slab_mutex);
-}
-
 int memcg_slab_show(struct seq_file *m, void *p)
 {
-	struct kmem_cache *s = list_entry(p, struct kmem_cache,
-					  memcg_params.kmem_caches_node);
-	struct mem_cgroup *memcg = mem_cgroup_from_seq(m);
-
-	if (p == memcg->kmem_caches.next)
-		print_slabinfo_header(m);
-	cache_show(s, m);
+	/*
+	 * Deprecated.
+	 * Please, take a look at tools/cgroup/slabinfo.py .
+	 */
 	return 0;
 }
 #endif