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!
