Re: [PATCHSET RFC cgroup/for-4.6] cgroup, sched: implement resource group and PRIO_RGRP
From: Mike Galbraith <hidden>
Date: 2016-04-14 06:07:56
Also in:
cgroups, lkml
From: Mike Galbraith <hidden>
Date: 2016-04-14 06:07:56
Also in:
cgroups, lkml
On Wed, 2016-04-13 at 11:59 -0400, Tejun Heo wrote:
Hello, Mike. On Wed, Apr 13, 2016 at 09:43:01AM +0200, Mike Galbraith wrote:quoted
quoted
The cost is part aesthetical and part practical. While less elegant than tree of uniform objects, it seems a stretch to call internal / leaf node distinction broken especially given that the model is natural to some controllers.That justifies prohibiting proper usages of three controllers, cpu, cpuacct and cpuset?Neither cpuacct or cpuset loses any capability from the constraint as there is no difference between tasks being in an internal cgroup or a leaf cgroup nested under it. The only practical impact is that we lose the ability to let internal tasks compete against sibling cgroups for proportional control.
I'm not getting it. A. entity = task[s] | cgroup[s] B. entity = task[s] ^ cgroup[s] A I get, B I don't, but you seem to be saying B, else we get the task competes with sibling cgroup business. Let /foo be an exclusive cpuset containing exclusive subset bar. How can any task acquire set foo affinity if B really really applies? My box calls me a dummy if I try to create a "proper" home for tasks, one with both no snobby neighbors and proper affinity. -Mike