From: Tejun Heo <tj@kernel.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.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: Thu, 13 Feb 2020 11:57:11 -0500 [thread overview]
Message-ID: <20200213165711.GJ88887@mtj.thefacebook.com> (raw)
In-Reply-To: <20200213163636.GH31689@dhcp22.suse.cz>
Hello,
On Thu, Feb 13, 2020 at 05:36:36PM +0100, Michal Hocko wrote:
> AFAIK systemd already offers knobs to configure resource controls [1].
Yes, it can set up the control knobs as directed but it doesn't ship
with any material resource configurations or has conventions set up
around it.
> Besides that we are talking about memcg features which are available only
> unified hieararchy and that is what systemd is using already.
I'm not quite sure what the above sentence is trying to say.
> > You gotta
> > change the layout to configure resource control no matter what and
> > it's pretty easy to do. systemd folks are planning to integrate higher
> > level resource control features, so my expectation is that the default
> > layout is gonna change as it develops.
>
> Do you have any pointers to those discussions? I am not really following
> systemd development.
There's a plan to integrate streamlined implementation of oomd into
systemd. There was a thread somewhere but the only thing I can find
now is a phoronix link.
https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Facebook-OOMD
systemd recently implemented DisableControllers so that upper level
slices can have authority over what controllers are enabled below it
and in a similar vein there were discussions over making it
auto-propagate some of the configs down the hierarchy but kernel doing
the right thing and maintaining consistent semantics across
controllers seems to be the right approach.
There was also a discussion with a distro. Nothing concrete yet but I
think we're more likely to see more resource control configs being
deployed by default in the future.
> Anyway, I am skeptical that systemd can do anything much more clever
> than placing cgroups with a resource control under the root cgroup. At
> least not without some tagging which workloads are somehow related.
Yeah, exactly, all it needs to do is placing scopes / services
according to resource hierarchy and configure overall policy at higher
level slices, which is exactly what the memory.low semantics change
will allow.
> That being said, I do not really blame systemd here. We are not making
> their life particularly easy TBH.
Do you mind elaborating a bit?
Thanks.
--
tejun
next prev parent reply other threads:[~2020-02-13 16:57 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 [this message]
[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
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=20200213165711.GJ88887@mtj.thefacebook.com \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.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.