From: Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org>
To: Zhaoyang Huang <huangzhaoyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Suren Baghdasaryan
<surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"zhaoyang.huang"
<zhaoyang.huang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Linux MM <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ke Wang <ke.wang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org>,
Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
Roman Gushchin
<roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>,
Muchun Song <songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>
Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited
Date: Wed, 24 Aug 2022 12:27:00 +0200 [thread overview]
Message-ID: <YwX89JCQCKMMYdG9@dhcp22.suse.cz> (raw)
In-Reply-To: <CAGWkznEqX3DwHW_owiK+HuuQ-HsUYK4vKmLhSxgzGn20Vzid2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote:
> On Wed, Aug 24, 2022 at 3:50 PM Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> wrote:
> >
> > On Wed 24-08-22 10:23:14, Zhaoyang Huang wrote:
> > > On Tue, Aug 23, 2022 at 7:51 PM Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> wrote:
> > [...]
> > > > One way to achieve that would be shaping the hierarchy the following way
> > > > root
> > > > / \
> > > > no_memcg[1] memcg[2]
> > > > |||||||| |||||
> > > > app_cgroups app_cgroups
> > > >
> > > > with
> > > > no_memcg.subtree_control = ""
> > > > memcg.subtree_control = memory
> > > >
> > > > no?
> > > According to my understanding, No as there will be no no_memcg. All
> > > children groups under root would have its cgroup.controllers = memory
> > > as long as root has memory enabled.
> >
> > Correct
> >
> > > Under this circumstance, all
> > > descendants group under 'no_memcg' will charge memory to its parent
> > > group.
> >
> > Correct. And why is that a problem? I thought you main concern was a per
> > application LRUs. With the above configuration all app_cgroups which do
> > not require an explicit memory control will share the same (no_memcg)
> > LRU and they will be aged together.
> I can't agree since this indicates the processes want memory free
> depending on a specific hierarchy which could have been determined by
> other subsys.
I really fail to understand your requirements.
> IMHO, charging the pages which out of explicitly memory
> enabled group to root could solve all of the above constraints with no
> harm.
This would break the hierarchical property of the controller. So a
strong no no. Consider the following example
root
|
A
controllers="memory"
memory.max = 1G
subtree_control=""
| | |
A1 A2 A3
althought A1,2,3 do not have their memory controller enabled explicitly
they are still constrained by the A memcg limit. If you just charge to
the root because it doesn't have memory controller enabled explicitly
then you just evade that constrain. I hope you understand why that is a
problem.
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@suse.com>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Suren Baghdasaryan <surenb@google.com>, Tejun Heo <tj@kernel.org>,
Shakeel Butt <shakeelb@google.com>,
"zhaoyang.huang" <zhaoyang.huang@unisoc.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Linux MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>, Ke Wang <ke.wang@unisoc.com>,
Zefan Li <lizefan.x@bytedance.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <songmuchun@bytedance.com>
Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited
Date: Wed, 24 Aug 2022 12:27:00 +0200 [thread overview]
Message-ID: <YwX89JCQCKMMYdG9@dhcp22.suse.cz> (raw)
In-Reply-To: <CAGWkznEqX3DwHW_owiK+HuuQ-HsUYK4vKmLhSxgzGn20Vzid2A@mail.gmail.com>
On Wed 24-08-22 17:34:42, Zhaoyang Huang wrote:
> On Wed, Aug 24, 2022 at 3:50 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Wed 24-08-22 10:23:14, Zhaoyang Huang wrote:
> > > On Tue, Aug 23, 2022 at 7:51 PM Michal Hocko <mhocko@suse.com> wrote:
> > [...]
> > > > One way to achieve that would be shaping the hierarchy the following way
> > > > root
> > > > / \
> > > > no_memcg[1] memcg[2]
> > > > |||||||| |||||
> > > > app_cgroups app_cgroups
> > > >
> > > > with
> > > > no_memcg.subtree_control = ""
> > > > memcg.subtree_control = memory
> > > >
> > > > no?
> > > According to my understanding, No as there will be no no_memcg. All
> > > children groups under root would have its cgroup.controllers = memory
> > > as long as root has memory enabled.
> >
> > Correct
> >
> > > Under this circumstance, all
> > > descendants group under 'no_memcg' will charge memory to its parent
> > > group.
> >
> > Correct. And why is that a problem? I thought you main concern was a per
> > application LRUs. With the above configuration all app_cgroups which do
> > not require an explicit memory control will share the same (no_memcg)
> > LRU and they will be aged together.
> I can't agree since this indicates the processes want memory free
> depending on a specific hierarchy which could have been determined by
> other subsys.
I really fail to understand your requirements.
> IMHO, charging the pages which out of explicitly memory
> enabled group to root could solve all of the above constraints with no
> harm.
This would break the hierarchical property of the controller. So a
strong no no. Consider the following example
root
|
A
controllers="memory"
memory.max = 1G
subtree_control=""
| | |
A1 A2 A3
althought A1,2,3 do not have their memory controller enabled explicitly
they are still constrained by the A memcg limit. If you just charge to
the root because it doesn't have memory controller enabled explicitly
then you just evade that constrain. I hope you understand why that is a
problem.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2022-08-24 10:27 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 11:29 [RFC PATCH] memcg: use root_mem_cgroup when css is inherited zhaoyang.huang
2022-08-19 11:29 ` zhaoyang.huang
2022-08-19 14:29 ` kernel test robot
[not found] ` <1660908562-17409-1-git-send-email-zhaoyang.huang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org>
2022-08-19 16:29 ` Tejun Heo
2022-08-19 16:29 ` Tejun Heo
[not found] ` <Yv+6YjaGAv52yvq9-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-08-19 17:08 ` Shakeel Butt
2022-08-19 17:08 ` Shakeel Butt
[not found] ` <CALvZod7QdLSMdBoD2WztL72qS8kJe7F79JuCH6t19rRcw6Pn1w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-19 17:10 ` Tejun Heo
2022-08-19 17:10 ` Tejun Heo
[not found] ` <Yv/EArPDTcCrGqJh-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-08-22 11:31 ` Michal Hocko
2022-08-22 11:31 ` Michal Hocko
2022-08-23 2:31 ` Zhaoyang Huang
[not found] ` <CAGWkznEB+R0YBaBFBL7dPqs8R=qKC6+ixTWEGCYy2PaczXkaPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-23 5:21 ` Michal Hocko
2022-08-23 5:21 ` Michal Hocko
[not found] ` <YwRjyx6wFLk8WTDe-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-23 6:03 ` Zhaoyang Huang
2022-08-23 6:03 ` Zhaoyang Huang
[not found] ` <CAGWkznGaYTv4u4kOo-rupfyWzDNJXNKTchwP6dbUK-=UXWm47w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-23 8:33 ` Michal Hocko
2022-08-23 8:33 ` Michal Hocko
[not found] ` <YwSQ4APOu/H7lYGL-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-23 9:20 ` Zhaoyang Huang
2022-08-23 9:20 ` Zhaoyang Huang
[not found] ` <CAGWkznGd6mgareABseMKY5p0f1=5dkfVkj=NS7_B6OkXBYSwyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-23 11:51 ` Michal Hocko
2022-08-23 11:51 ` Michal Hocko
[not found] ` <YwS/S9Sd1OWnT81Q-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-23 16:21 ` Suren Baghdasaryan
2022-08-23 16:21 ` Suren Baghdasaryan
[not found] ` <CAJuCfpH+T9+eOVYDfOv9yNSfAvq=pJtMp4ZaoYaM7iMY9XkaUw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-24 7:59 ` Michal Hocko
2022-08-24 7:59 ` Michal Hocko
[not found] ` <YwXaXHRhy51xH4rk-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-24 17:13 ` Suren Baghdasaryan
2022-08-24 17:13 ` Suren Baghdasaryan
2022-08-24 2:23 ` Zhaoyang Huang
2022-08-24 2:23 ` Zhaoyang Huang
[not found] ` <CAGWkznGYLyF+njUB0gFF3JVdThnK9JaNsqxXYFhbdSwEQpCxvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-24 7:50 ` Michal Hocko
2022-08-24 7:50 ` Michal Hocko
[not found] ` <YwXYVjRpXQjQMsxr-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-24 9:34 ` Zhaoyang Huang
2022-08-24 9:34 ` Zhaoyang Huang
[not found] ` <CAGWkznEqX3DwHW_owiK+HuuQ-HsUYK4vKmLhSxgzGn20Vzid2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-24 10:27 ` Michal Hocko [this message]
2022-08-24 10:27 ` Michal Hocko
[not found] ` <YwX89JCQCKMMYdG9-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-25 0:43 ` Zhaoyang Huang
2022-08-25 0:43 ` Zhaoyang Huang
[not found] ` <CAGWkznF+dBjLzAxMMXWYSZ_5q3KA-ou0P7XM7jSYN7JSRp8N0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-25 6:40 ` Michal Hocko
2022-08-25 6:40 ` Michal Hocko
[not found] ` <YwcZctA2S3Sd0LBN-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-25 8:34 ` Zhaoyang Huang
2022-08-25 8:34 ` Zhaoyang Huang
2022-08-25 8:50 ` Michal Hocko
[not found] ` <Ywc34ci5XUMXOSYA-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-25 10:11 ` Zhaoyang Huang
2022-08-25 10:11 ` Zhaoyang Huang
[not found] ` <CAGWkznHL_G3OoAc5gJ+iwxqxonr21-fU+F4T2gkpXH68keLpuQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-25 13:35 ` Johannes Weiner
2022-08-25 13:35 ` Johannes Weiner
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=YwX89JCQCKMMYdG9@dhcp22.suse.cz \
--to=mhocko-ibi9rg/b67k@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=huangzhaoyang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ke.wang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org \
--cc=shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=surenb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=zhaoyang.huang-1tVvrHeaX6nQT0dZR+AlfA@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.