From: Roman Gushchin <guro@fb.com>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>,
Shakeel Butt <shakeelb@google.com>,
Vladimir Davydov <vdavydov.dev@gmail.com>,
Waiman Long <longman@redhat.com>
Subject: Re: [PATCH RFC 00/14] The new slab memory controller
Date: Wed, 2 Oct 2019 02:09:11 +0000 [thread overview]
Message-ID: <20191002020906.GB6436@castle.dhcp.thefacebook.com> (raw)
In-Reply-To: <20191001151202.GA6678@blackbody.suse.cz>
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@fb.com> 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!
next prev parent reply other threads:[~2019-10-02 2:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 21:45 [PATCH RFC 00/14] The new slab memory controller Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 01/14] mm: memcg: subpage charging API Roman Gushchin
2019-09-16 12:56 ` Johannes Weiner
2019-09-17 2:27 ` Roman Gushchin
2019-09-17 8:50 ` Johannes Weiner
2019-09-17 18:33 ` Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 02/14] mm: memcg: introduce mem_cgroup_ptr Roman Gushchin
2019-09-05 22:34 ` Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 03/14] mm: vmstat: use s32 for vm_node_stat_diff in struct per_cpu_nodestat Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 04/14] mm: vmstat: convert slab vmstat counter to bytes Roman Gushchin
2019-09-16 12:38 ` Johannes Weiner
2019-09-17 2:08 ` Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 05/14] mm: memcg/slab: allocate space for memcg ownership data for non-root slabs Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 06/14] mm: slub: implement SLUB version of obj_to_index() Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 07/14] mm: memcg/slab: save memcg ownership data for non-root slab objects Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 08/14] mm: memcg: move memcg_kmem_bypass() to memcontrol.h Roman Gushchin
2019-09-05 21:45 ` [PATCH RFC 09/14] mm: memcg: introduce __mod_lruvec_memcg_state() Roman Gushchin
2019-09-05 22:37 ` [PATCH RFC 02/14] mm: memcg: introduce mem_cgroup_ptr Roman Gushchin
2019-09-17 19:48 ` [PATCH RFC 00/14] The new slab memory controller Waiman Long
2019-09-17 21:24 ` Roman Gushchin
2019-09-19 13:39 ` Suleiman Souhlal
2019-09-19 16:22 ` Roman Gushchin
2019-09-19 21:10 ` Suleiman Souhlal
2019-09-19 21:40 ` Roman Gushchin
2019-10-01 15:12 ` Michal Koutný
2019-10-02 2:09 ` Roman Gushchin [this message]
2019-10-02 13:00 ` Suleiman Souhlal
2019-10-03 10:47 ` Michal Koutný
2019-10-03 15:52 ` Roman Gushchin
2019-12-09 9:17 ` [PATCH 00/16] " Bharata B Rao
2019-12-09 11:56 ` Bharata B Rao
2019-12-09 18:04 ` Roman Gushchin
2019-12-10 6:23 ` Bharata B Rao
2019-12-10 18:05 ` Roman Gushchin
2020-01-13 8:47 ` Bharata B Rao
2020-01-13 15:31 ` Roman Gushchin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191002020906.GB6436@castle.dhcp.thefacebook.com \
--to=guro@fb.com \
--cc=Kernel-team@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=longman@redhat.com \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).