From: Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Roman Gushchin <guro-b10kYP2dOMg@public.gmane.org>,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-team-b10kYP2dOMg@public.gmane.org
Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection
Date: Mon, 17 Feb 2020 09:41:00 +0100 [thread overview]
Message-ID: <20200217084100.GE31531@dhcp22.suse.cz> (raw)
In-Reply-To: <20200214165311.GA253674-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
On Fri 14-02-20 11:53:11, Johannes Weiner wrote:
[...]
> The proper solution to implement the kind of resource hierarchy you
> want to express in cgroup2 is to reflect it in the cgroup tree. Yes,
> the_workload might have been started by user 100 in session c2, but in
> terms of resources, it's prioritized over system.slice and user.slice,
> and so that's the level where it needs to sit:
>
> root
> / | \
> system.slice user.slice the_workload
> / | |
> cron journal user-100.slice
> |
> session-c2.scope
> |
> misc
>
> Then you can configure not just memory.low, but also a proper io
> weight and a cpu weight. And the tree correctly reflects where the
> workload is in the pecking order of who gets access to resources.
I have already mentioned that this would be the only solution when the
protection would work, right. But I am also saying that this a trivial
example where you simply _can_ move your workload to the 1st level. What
about those that need to reflect organization into the hierarchy. Please
have a look at http://lkml.kernel.org/r/20200214075916.GM31689-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org
Are you saying they are just not supported? Are they supposed to use
cgroup v1 for the organization and v2 for the resource control?
--
Michal Hocko
SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <guro@fb.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection
Date: Mon, 17 Feb 2020 09:41:00 +0100 [thread overview]
Message-ID: <20200217084100.GE31531@dhcp22.suse.cz> (raw)
In-Reply-To: <20200214165311.GA253674@cmpxchg.org>
On Fri 14-02-20 11:53:11, Johannes Weiner wrote:
[...]
> The proper solution to implement the kind of resource hierarchy you
> want to express in cgroup2 is to reflect it in the cgroup tree. Yes,
> the_workload might have been started by user 100 in session c2, but in
> terms of resources, it's prioritized over system.slice and user.slice,
> and so that's the level where it needs to sit:
>
> root
> / | \
> system.slice user.slice the_workload
> / | |
> cron journal user-100.slice
> |
> session-c2.scope
> |
> misc
>
> Then you can configure not just memory.low, but also a proper io
> weight and a cpu weight. And the tree correctly reflects where the
> workload is in the pecking order of who gets access to resources.
I have already mentioned that this would be the only solution when the
protection would work, right. But I am also saying that this a trivial
example where you simply _can_ move your workload to the 1st level. What
about those that need to reflect organization into the hierarchy. Please
have a look at http://lkml.kernel.org/r/20200214075916.GM31689@dhcp22.suse.cz
Are you saying they are just not supported? Are they supposed to use
cgroup v1 for the organization and v2 for the resource control?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2020-02-17 8:41 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-19 20:07 [PATCH v2 0/3] mm: memcontrol: recursive memory protection Johannes Weiner
2019-12-19 20:07 ` [PATCH v2 1/3] mm: memcontrol: fix memory.low proportional distribution Johannes Weiner
2020-01-30 11:49 ` Michal Hocko
2020-02-03 21:21 ` Johannes Weiner
[not found] ` <20200203212136.GC6380-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-03 21:38 ` Roman Gushchin
2020-02-03 21:38 ` Roman Gushchin
2019-12-19 20:07 ` [PATCH v2 2/3] mm: memcontrol: clean up and document effective low/min calculations Johannes Weiner
2020-01-30 12:54 ` Michal Hocko
[not found] ` <20191219200718.15696-3-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-21 17:10 ` Michal Koutný
2020-02-21 17:10 ` Michal Koutný
[not found] ` <20200221171024.GA23476-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-25 18:40 ` Johannes Weiner
2020-02-25 18:40 ` Johannes Weiner
2020-02-26 16:46 ` Michal Koutný
[not found] ` <20200226164632.GL27066-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-26 19:40 ` Johannes Weiner
2020-02-26 19:40 ` Johannes Weiner
2019-12-19 20:07 ` [PATCH v2 3/3] mm: memcontrol: recursive memory.low protection Johannes Weiner
[not found] ` <20191219200718.15696-4-hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-01-30 17:00 ` Michal Hocko
2020-01-30 17:00 ` Michal Hocko
[not found] ` <20200130170020.GZ24244-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-03 21:52 ` Johannes Weiner
2020-02-03 21:52 ` Johannes Weiner
[not found] ` <20200203215201.GD6380-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-10 15:21 ` Johannes Weiner
2020-02-10 15:21 ` Johannes Weiner
2020-02-11 16:47 ` Michal Hocko
2020-02-11 16:47 ` Michal Hocko
[not found] ` <20200211164753.GQ10636-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-12 17:08 ` Johannes Weiner
2020-02-12 17:08 ` Johannes Weiner
[not found] ` <20200212170826.GC180867-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-13 7:40 ` Michal Hocko
2020-02-13 7:40 ` Michal Hocko
2020-02-13 13:23 ` Johannes Weiner
[not found] ` <20200213132317.GA208501-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-13 15:46 ` Michal Hocko
2020-02-13 15:46 ` Michal Hocko
2020-02-13 17:41 ` Johannes Weiner
[not found] ` <20200213174135.GC208501-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-13 17:58 ` Johannes Weiner
2020-02-13 17:58 ` Johannes Weiner
[not found] ` <20200213175813.GA216470-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-14 7:59 ` Michal Hocko
2020-02-14 7:59 ` Michal Hocko
[not found] ` <20200213074049.GA31689-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-13 13:53 ` Tejun Heo
2020-02-13 13:53 ` Tejun Heo
2020-02-13 15:47 ` Michal Hocko
[not found] ` <20200213154731.GE31689-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-13 15:52 ` Tejun Heo
2020-02-13 15:52 ` Tejun Heo
[not found] ` <20200213155249.GI88887-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-13 16:36 ` Michal Hocko
2020-02-13 16:36 ` Michal Hocko
2020-02-13 16:57 ` Tejun Heo
[not found] ` <20200213165711.GJ88887-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-14 7:15 ` Michal Hocko
2020-02-14 7:15 ` Michal Hocko
[not found] ` <20200214071537.GL31689-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-14 13:57 ` Tejun Heo
2020-02-14 13:57 ` Tejun Heo
[not found] ` <20200214135728.GK88887-146+VewaZzwNjtGbbfXrCEEOCMrvLtNR@public.gmane.org>
2020-02-14 15:13 ` Michal Hocko
2020-02-14 15:13 ` Michal Hocko
[not found] ` <20200214151318.GC31689-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-14 15:40 ` Tejun Heo
2020-02-14 15:40 ` Tejun Heo
2020-02-14 16:53 ` Johannes Weiner
2020-02-14 17:17 ` Tejun Heo
[not found] ` <20200214165311.GA253674-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-17 8:41 ` Michal Hocko [this message]
2020-02-17 8:41 ` Michal Hocko
[not found] ` <20200217084100.GE31531-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-18 19:52 ` Johannes Weiner
2020-02-18 19:52 ` Johannes Weiner
[not found] ` <20200218195253.GA13406-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-21 10:11 ` Michal Hocko
2020-02-21 10:11 ` Michal Hocko
[not found] ` <20200221101147.GO20509-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2020-02-21 15:43 ` Johannes Weiner
2020-02-21 15:43 ` Johannes Weiner
2020-02-25 12:20 ` Michal Hocko
2020-02-25 18:17 ` Johannes Weiner
[not found] ` <20200225181755.GB10257-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-26 17:56 ` Michal Hocko
2020-02-26 17:56 ` Michal Hocko
2020-02-21 17:12 ` Michal Koutný
2020-02-21 17:12 ` Michal Koutný
[not found] ` <20200221171256.GB23476-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-21 18:58 ` Johannes Weiner
2020-02-21 18:58 ` Johannes Weiner
[not found] ` <20200221185839.GB70967-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-25 13:37 ` Michal Koutný
2020-02-25 13:37 ` Michal Koutný
[not found] ` <20200225133720.GA6709-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-25 15:03 ` Johannes Weiner
2020-02-25 15:03 ` Johannes Weiner
[not found] ` <20200225150304.GA10257-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-26 13:22 ` Michal Koutný
2020-02-26 13:22 ` Michal Koutný
[not found] ` <20200226132237.GA16746-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-26 15:05 ` Johannes Weiner
2020-02-26 15:05 ` Johannes Weiner
[not found] ` <20200226150548.GD10257-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2020-02-27 13:35 ` Michal Koutný
2020-02-27 13:35 ` Michal Koutný
[not found] ` <20200227133544.GA20690-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2020-02-27 15:06 ` Johannes Weiner
2020-02-27 15:06 ` Johannes Weiner
2019-12-19 20:22 ` [PATCH v2 0/3] mm: memcontrol: recursive memory protection Tejun Heo
2019-12-20 4:06 ` Roman Gushchin
2019-12-20 4:29 ` Chris Down
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=20200217084100.GE31531@dhcp22.suse.cz \
--to=mhocko-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=guro-b10kYP2dOMg@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@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.