On Thu, Feb 4, 2021 at 5:54 AM Peter Zijlstra <pet...@infradead.org> wrote: > > On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote: > > From: Peter Zijlstra <pet...@infradead.org> > > I'm thinking this is too much credit, I didn't write much of this. > > > Marks all tasks in a cgroup as matching for core-scheduling. > > > > A task will need to be moved into the core scheduler queue when the cgroup > > it belongs to is tagged to run with core scheduling. Similarly the task > > will need to be moved out of the core scheduler queue when the cgroup > > is untagged. > > > > Also after we forked a task, its core scheduler queue's presence will > > need to be updated according to its new cgroup's status. > > > > Use stop machine mechanism to update all tasks in a cgroup to prevent a > > new task from sneaking into the cgroup, and missed out from the update > > while we iterates through all the tasks in the cgroup. A more complicated > > scheme could probably avoid the stop machine. Such scheme will also > > need to resovle inconsistency between a task's cgroup core scheduling > > tag and residency in core scheduler queue. > > > > We are opting for the simple stop machine mechanism for now that avoids > > such complications. > > > > Core scheduler has extra overhead. Enable it only for core with > > more than one SMT hardware threads. > > Very little actual words on the desired and implemented semantics of the > interface, while the patch contains much non-obvious complication.
Ack to both, will fix in the next posting.