[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YG3i2JF2vBY4CseK@blackbook>
Date: Wed, 7 Apr 2021 18:50:32 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Tejun Heo <tj@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, joel@...lfernandes.org,
chris.hyser@...cle.com, joshdon@...gle.com, mingo@...nel.org,
vincent.guittot@...aro.org, valentin.schneider@....com,
mgorman@...e.de, linux-kernel@...r.kernel.org, tglx@...utronix.de,
Christian Brauner <christian.brauner@...ntu.com>,
Zefan Li <lizefan.x@...edance.com>
Subject: Re: [PATCH 0/9] sched: Core scheduling interfaces
Hello.
IIUC, the premise is that the tasks that have different cookies imply
they would never share a core.
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). The
potential speciality is the possibility to re-tag whole groups of
processes at runtime (but the listed use cases [1] don't require that
and it's not such a good idea given its asynchronicity).
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.
My two cents,
Michal
[1] https://lore.kernel.org/lkml/20200822030155.GA414063@google.com/
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists