From: "Michal Koutný" <mkoutny@suse.com>
To: Vasily Averin <vvs@openvz.org>
Cc: Roman Gushchin <roman.gushchin@linux.dev>,
tj@kernel.org, gregkh@linuxfoundation.org, hannes@cmpxchg.org,
kernel@openvz.org, linux-kernel@vger.kernel.org, mhocko@suse.com,
shakeelb@google.com, songmuchun@bytedance.com,
viro@zeniv.linux.org.uk
Subject: Re: [RFC PATCH] memcg: adjust memcg for new cgroup allocations
Date: Wed, 17 Aug 2022 11:17:28 +0200 [thread overview]
Message-ID: <20220817091728.GA23229@blackbody.suse.cz> (raw)
In-Reply-To: <45a04b75-d61b-4c7a-7169-c971995a6049@openvz.org>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Hello.
On Wed, Aug 17, 2022 at 10:42:40AM +0300, Vasily Averin <vvs@openvz.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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-08-17 9:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-31 15:37 [PATCH 0/3] enable memcg accounting for kernfs objects Vasily Averin
2022-08-09 17:31 ` Tejun Heo
2022-08-09 17:49 ` Michal Koutný
2022-08-09 17:56 ` Tejun Heo
2022-08-11 3:19 ` Vasily Averin
2022-08-11 4:58 ` [RFC PATCH] kernfs: enable per-inode limits for all xattr types Vasily Averin
2022-08-12 10:20 ` Christian Brauner
2022-08-13 4:16 ` Vasily Averin
2022-08-16 7:47 ` [PATCH 0/3] enable memcg accounting for kernfs objects Vasily Averin
2022-08-17 7:42 ` [RFC PATCH] memcg: adjust memcg for new cgroup allocations Vasily Averin
2022-08-17 9:17 ` Michal Koutný [this message]
2022-08-17 15:02 ` Vasily Averin
2022-08-17 16:41 ` Tejun Heo
2022-08-23 12:04 ` Vasily Averin
2022-08-23 16:22 ` Tejun Heo
2022-08-18 9:10 ` [RFC PATCH] memcg: adjust memcg used to charge for new simple_xattrs objects Vasily Averin
2022-08-18 12:27 ` Michal Koutný
2022-08-23 8:17 ` Vasily Averin
2022-08-18 9:12 ` [RFC PATCH] simple_xattr: switch from list to rb_tree Vasily Averin
2022-08-18 13:19 ` Christian Brauner
2022-08-23 10:42 ` Vasily Averin
2022-08-09 21:25 ` [PATCH 0/3] enable memcg accounting for kernfs objects 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=20220817091728.GA23229@blackbody.suse.cz \
--to=mkoutny@suse.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=kernel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
--cc=tj@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=vvs@openvz.org \
/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