Thread (50 messages) 50 messages, 6 authors, 2016-04-15

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

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help