[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200624015324.GC358561@carbon.lan>
Date: Tue, 23 Jun 2020 18:53:24 -0700
From: Roman Gushchin <guro@...com>
To: Shakeel Butt <shakeelb@...gle.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux.com>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Linux MM <linux-mm@...ck.org>,
Vlastimil Babka <vbabka@...e.cz>,
Kernel Team <kernel-team@...com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo
On Tue, Jun 23, 2020 at 06:43:38PM -0700, Shakeel Butt wrote:
> On Tue, Jun 23, 2020 at 10:40 AM Roman Gushchin <guro@...com> 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 .
>
> tools/cgroup/memcg_slabinfo.py*
Oh, right, I did rename it at some point to avoid a confusion with the existing
slabinfo tool.
An update version below.
Thanks!
--
>From a25bb12666ada55d1a0a47ca40b8d5ccedc639d9 Mon Sep 17 00:00:00 2001
From: Roman Gushchin <guro@...com>
Date: Sun, 21 Jun 2020 05:35:01 +0000
Subject: [PATCH v7 10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo
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/memcg_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 <guro@...com>
Acked-by: Johannes Weiner <hannes@...xchg.org>
Reviewed-by: Vlastimil Babka <vbabka@...e.cz>
Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
---
mm/memcontrol.c | 3 ---
mm/slab_common.c | 31 ++++---------------------------
2 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 5e55c7afc18c..ad43e5bc482b 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5118,9 +5118,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 4fb76b45ce23..42edfa46fee6 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
--
2.26.2
Powered by blists - more mailing lists