mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Vasily Averin <vvs@openvz.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	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 06:41:22 -1000	[thread overview]
Message-ID: <Yv0aMqMIafD7cOQX@slm.duckdns.org> (raw)
In-Reply-To: <20220817091728.GA23229@blackbody.suse.cz>

Hello,

On Wed, Aug 17, 2022 at 11:17:28AM +0200, Michal Koutný wrote:
> 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?

At least from my POV, as long as cgroup1 is not being regressed, we want to
make decisions which make the best long term sense. We surely can
accommodate cgroup1 as long as the added complexity is minimal but the bar
is pretty high there. cgroup1 has been in maintenance mode for years now and
even the basic delegation model isn't well established in cgroup1, so if we
end up accounting everything in the root cgroup for most of cgroup1
hierarchies, that sounds fine to me.

Thanks.

-- 
tejun

  parent reply	other threads:[~2022-08-17 16:41 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ý
2022-08-17 15:02               ` Vasily Averin
2022-08-17 16:41               ` Tejun Heo [this message]
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=Yv0aMqMIafD7cOQX@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kernel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=songmuchun@bytedance.com \
    --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

all inboxes | Powered by JetHome®