| Message ID | 20200526214227.989341-11-guro@fb.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | The new cgroup slab memory controller | expand |
On 5/26/20 11:42 PM, Roman Gushchin 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 <guro@fb.com> Also there was a Acked-by: Johannes Weiner <hannes@cmpxchg.org> for this patch. And here's mine: Acked-by: Vlastimil Babka <vbabka@suse.cz> Of course this depends on whether we break somebody's workflow and they complain. > --- > 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 ed12bff81ea5..eca03e13c7ec 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -5052,9 +5052,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 >
On Wed, May 27, 2020 at 05:54:50PM +0200, Vlastimil Babka wrote: > On 5/26/20 11:42 PM, Roman Gushchin 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 <guro@fb.com> > > Also there was a > Acked-by: Johannes Weiner <hannes@cmpxchg.org> > for this patch. > And here's mine: > Acked-by: Vlastimil Babka <vbabka@suse.cz> Thanks! > > Of course this depends on whether we break somebody's workflow and they complain. We've discussed it a bit around RFC/v1. I hope nobody uses it for anything except debug purposes, where dragon + bpf can be as good or better. And actually it is what it is: there are no more per-memcg kmem caches, so there is nothing to display.
diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ed12bff81ea5..eca03e13c7ec 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5052,9 +5052,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
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 <guro@fb.com> --- mm/memcontrol.c | 3 --- mm/slab_common.c | 31 ++++--------------------------- 2 files changed, 4 insertions(+), 30 deletions(-)