Re: [PATCH RFC 00/14] The new slab memory controller

[Roman Gushchin]

On Tue, Oct 01, 2019 at 05:12:02PM +0200, Michal Koutný wrote:
> On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin <guro@xxxxxx> wrote:
> > Roman Gushchin (14):
> > [...]
> >   mm: memcg/slab: use one set of kmem_caches for all memory cgroups
> From that commit's message:
> 
> > 6) obsoletes kmem.slabinfo cgroup v1 interface file, as there are
> >   no per-memcg kmem_caches anymore (empty output is printed)
> 
> The empty file means no allocations took place in the particular cgroup.
> I find this quite a surprising change for consumers of these stats.
> 
> I understand obtaining the same data efficiently from the proposed
> structures is difficult, however, such a change should be avoided. (In
> my understanding, obsoleted file ~ not available in v2, however, it
> should not disappear from v1.)

Well, my assumption is that nobody is using this file for anything except
debugging purposes (I might be wrong, if somebody has an automation based
on it, please, let me know). A number of allocations of each type per memory
cgroup is definitely a useful debug information, but currently it barely works
(displayed numbers show mostly the number of allocated pages, not the number
of active objects). We can support it, but it comes with the price, and
most users don't really need it. So I don't think it worth it to make all
allocations slower just to keep some debug interface working for some
cgroup v1 users. Do you have examples when it's really useful and worth
extra cpu cost?

Unfortunately, we can't enable it conditionally, as a user can switch
between cgroup v1 and cgroup v2 memory controllers dynamically.

Thanks!