[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220817091728.GA23229@blackbody.suse.cz>
Date: Wed, 17 Aug 2022 11:17:28 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Vasily Averin <vvs@...nvz.org>
Cc: Roman Gushchin <roman.gushchin@...ux.dev>, tj@...nel.org,
gregkh@...uxfoundation.org, hannes@...xchg.org, kernel@...nvz.org,
linux-kernel@...r.kernel.org, mhocko@...e.com, shakeelb@...gle.com,
songmuchun@...edance.com, viro@...iv.linux.org.uk
Subject: Re: [RFC PATCH] memcg: adjust memcg for new cgroup allocations
Hello.
On Wed, Aug 17, 2022 at 10:42:40AM +0300, Vasily Averin <vvs@...nvz.org> wrote:
> However, now we want to enable accounting for some other cgroup-related
> resources called from cgroup_mkdir. We would like to guarantee that
> all new accounted allocation will be charged to the same memory cgroup.
Here's my point -- the change in the referenced patch applied to memory
controller hierarchies. This extension applies to any hierarchy that can
create groups, namely, a hierarchy without memory controller too. There
mem_cgroup_from_cgroup falls back to the root memcg (on a different
hierarchy).
If the purpose is to prevent unlimited creation of cgroup objects, the
root memcg is by principle unlimited, so it's just for accounting.
But I understand the purpose is to have everything under one roof,
unless the object lifetime is not bound to that owning memcg. Should
memory-less hierarchies be treated specially?
> +static inline struct mem_cgroup *mem_cgroup_from_cgroup(struct cgroup *cgroup)
[...]
> + css = cgroup_get_e_css(cgroup, &memory_cgrp_subsys);
> +
> + if (css)
> + memcg = container_of(css, struct mem_cgroup, css);
Nit: mem_cgroup_from_css
Regards,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists