From: Peter Zijlstra <firstname.lastname@example.org> To: "Michal Koutný" <email@example.com> Cc: Tejun Heo <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Christian Brauner <firstname.lastname@example.org>, Zefan Li <email@example.com> Subject: Re: [PATCH 0/9] sched: Core scheduling interfaces Date: Wed, 7 Apr 2021 20:34:24 +0200 [thread overview] Message-ID: <YG37MBLBIXIPVv7u@hirez.programming.kicks-ass.net> (raw) In-Reply-To: <YG3i2JF2vBY4CseK@blackbook> On Wed, Apr 07, 2021 at 06:50:32PM +0200, Michal Koutný wrote: > Hello. > > IIUC, the premise is that the tasks that have different cookies imply > they would never share a core. Correct. > On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote: > > The cgroup interface now uses a 'core_sched' file, which still takes 0,1. It is > > however changed such that you can have nested tags. The for any given task, the > > first parent with a cookie is the effective one. The rationale is that this way > > you can delegate subtrees and still allow them some control over grouping. > > 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' cgroup properties. That's not something covered by either prctl or clone. > The potential speciality is the possibility to re-tag whole groups of > processes at runtime (but the listed use cases  don't require that > and it's not such a good idea given its asynchronicity). That seems to be the implication of having that tasks file. Tasks can join a cgroup, so you get to deal with that. You can't just say, don't do that then. > Also, I would find useful some more explanation how the hierarchical > behavior is supposed to work. In my understanding the task is either > allowed to request its own isolation or not. The cgroups could be used > to restrict this privilege, however, that doesn't seem to be the case > here. Given something like: R / \ A B / \ C D B group can set core_sched=1 and then all its (and its decendants) tasks get to have the same (group) cookie and cannot share with others. If however B is a delegate and has a subgroup D that is security sensitive and must not share core resources with the rest of B, then it can also set D.core_sched=1, such that D (and its decendants) will have another (group) cookie. On top of this, say C has a Real-Time tasks, that wants to limit SMT interference, then it can set a (task/prctl) cookie on itself, such that it will not share the core with the rest of the tasks of B. In that scenario the D subtree is a restriction (doesn't share) with the B subtree. And all of B is a restriction on all its tasks, including the Real-Time task that set a task cookie, in that none of them can share with tasks outside of B (including system tasks which are in R), irrespective of what they do with their task cookie.
next prev parent reply other threads:[~2021-04-07 18:35 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-01 13:10 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 [this message] 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 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=YG37MBLBIXIPVv7u@hirez.programming.kicks-ass.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH 0/9] sched: Core scheduling interfaces' \ /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
This is a public inbox, see mirroring instructions on how to clone and mirror all data and code used for this inbox