From: Tejun Heo <tj@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Michal Koutný" <mkoutny@suse.com>,
joel@joelfernandes.org, chris.hyser@oracle.com,
joshdon@google.com, mingo@kernel.org, vincent.guittot@linaro.org,
valentin.schneider@arm.com, mgorman@suse.de,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
"Christian Brauner" <christian.brauner@ubuntu.com>,
"Zefan Li" <lizefan.x@bytedance.com>
Subject: Re: [PATCH 0/9] sched: Core scheduling interfaces
Date: Mon, 19 Apr 2021 07:30:18 -0400 [thread overview]
Message-ID: <YH1pygTubJHh3R9m@slm.duckdns.org> (raw)
In-Reply-To: <YG37MBLBIXIPVv7u@hirez.programming.kicks-ass.net>
Hello,
Sorry about late reply.
On Wed, Apr 07, 2021 at 08:34:24PM +0200, Peter Zijlstra wrote:
> > Given the existence of prctl and clone APIs, I don't see the reason to
> > have a separate cgroup-bound interface too (as argued by Tejun).
>
> IMO as long as cgroups have that tasks file, you get to support people
> using it. That means that tasks joining your cgroup need to 'inherit'
This argument doesn't really make sense to me. We don't just add things to
make interfaces orthogonal. It can be a consideration but not the only or
even one of the most important ones. There are many cases we say to not
shoot oneself in the foot and also many interfaces which are fading away or
in the process of being deprecated.
I'm not planning to deprecate the dynamic migration interfaces given the
history and usefulness in testing but the usage model of cgroup2 is clearly
defined and documented in this regard - whether the initial population of
the cgroup happens through CLONE_INTO_CGROUP or migration, for resource
tracking and control purposes, cgroup2 does not support dynamic migration
with the exception of migrations within threaded domains.
Anything is a possibility but given how this requirement is intertwined with
achieveing comprehensive resource control, a core goal of cgroup2, and
widely adopted by all the new fangled things as you put it, changing this
wouldn't be easy. Not just because some people including me are against it
but because there are inherent technical challenges and overheads to
supporting dynamic charge migration for stateful controllers and the
cost-benefit balance doesn't come out in favor.
So, the current "policy" is something like this:
* cgroupfs interface is for cgroup core features of organizing cgroups and
processes and configuring resource configurations which preferably follow
one of the control models defined in the doc.
* The hierarchical organization is semi-static in the sense that once a
cgroup is populated tasks shouldn't be moved in or out of the cgroup with
the exception of threaded domains.
* Non-resource control usages can hook into cgroup for identification /
tagging purposes but should use the originating interface for
interactions.
This has been consistently applied over the years now. There of course can
be exceptions but I haven't seen anything outstanding in this round of
discussion so am pretty skeptical. The actual use cases don't seem to need
it and the only argument for it is it'd be nice to have it and involves
violating the usage model.
My suggestion is going ahead with the per-process interface with cgroup
extension on mind in case actual use cases arise. Also, when planning cgroup
integration, putting dynamic migration front and center likely isn't a good
idea.
Thanks.
--
tejun
next prev parent reply other threads:[~2021-04-19 11:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 13:10 [PATCH 0/9] sched: Core scheduling interfaces Peter Zijlstra
2021-04-01 13:10 ` [PATCH 1/9] sched: Allow sched_core_put() from atomic context Peter Zijlstra
2021-04-01 13:10 ` [PATCH 2/9] sched: Implement core-sched assertions Peter Zijlstra
2021-04-01 13:10 ` [PATCH 3/9] sched: Trivial core scheduling cookie management Peter Zijlstra
2021-04-01 20:04 ` Josh Don
2021-04-02 7:13 ` Peter Zijlstra
2021-04-01 13:10 ` [PATCH 4/9] sched: Default core-sched policy Peter Zijlstra
2021-04-21 13:33 ` Peter Zijlstra
2021-04-21 14:31 ` Chris Hyser
2021-04-01 13:10 ` [PATCH 5/9] sched: prctl() core-scheduling interface Peter Zijlstra
2021-04-07 17:00 ` Peter Zijlstra
2021-04-18 3:52 ` Joel Fernandes
2021-04-01 13:10 ` [PATCH 6/9] kselftest: Add test for core sched prctl interface Peter Zijlstra
2021-04-01 13:10 ` [PATCH 7/9] sched: Cgroup core-scheduling interface Peter Zijlstra
2021-04-02 0:34 ` Josh Don
2021-04-01 13:10 ` [PATCH 8/9] rbtree: Remove const from the rb_find_add() comparator Peter Zijlstra
2021-04-01 13:10 ` [PATCH 9/9] sched: prctl() and cgroup interaction Peter Zijlstra
2021-04-03 1:30 ` Josh Don
2021-04-06 15:12 ` Peter Zijlstra
2021-04-04 23:39 ` [PATCH 0/9] sched: Core scheduling interfaces Tejun Heo
2021-04-05 18:46 ` Joel Fernandes
2021-04-06 14:16 ` Tejun Heo
2021-04-18 1:35 ` Joel Fernandes
2021-04-19 9:00 ` Peter Zijlstra
2021-04-21 13:35 ` Peter Zijlstra
2021-04-21 14:45 ` Chris Hyser
2021-04-06 15:32 ` Peter Zijlstra
2021-04-06 16:08 ` Tejun Heo
2021-04-07 18:39 ` Peter Zijlstra
2021-04-07 16:50 ` Michal Koutný
2021-04-07 18:34 ` Peter Zijlstra
2021-04-08 13:25 ` Michal Koutný
2021-04-08 15:02 ` Peter Zijlstra
2021-04-09 0:16 ` Josh Don
2021-04-19 11:30 ` Tejun Heo [this message]
2021-04-20 1:17 ` Josh Don
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=YH1pygTubJHh3R9m@slm.duckdns.org \
--to=tj@kernel.org \
--cc=chris.hyser@oracle.com \
--cc=christian.brauner@ubuntu.com \
--cc=joel@joelfernandes.org \
--cc=joshdon@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).