Re: boot cgroup questions

[Max Krasnyanskiy <maxk@qualcomm.com>]

Paul Jackson wrote:
> Max wrote:
>> I was talking about running on the _cpus_ that belong to the "sets A and B but 
>> not C" and not that a task must belong to more than one cpuset.
> 
> This doesn't make sense to me.
> 
> If a task is to run on the CPUs in both sets A and B, then it has to be
> in both those cpusets, which isn't allowed, or in some super set of both
> A and B (that is, in this example, in the top cpuset), which doesn't
> restrict the task to just A or B or their union.
> 
> I have no idea what distinction you are seeing between what _cpus_ a task
> can run on, and what cpuset it belongs to.

Paul, we are in 100% agreement here about the tasks. All I'm saying is that 
the same exact thing applies to the irqs. Again let me try your example.

Suppose we have
	/dev/cpuset/A
	/dev/cpuset/B
	/dev/cpuset/C

Now suppose that for whatever reason I must run task1 on the cpus that belong 
to sets A and B but not C. The only way to do that with cpusets is

	/dev/cpuset/X
         	  |-- A
	          `-- B
	/dev/cpuset/C

i.e. create parent cpuset X and assign task1 into cpuset X.
Of course if A and B are not cpu_exclusive then X does not have to be their 
parent.

Makes sense so far ?

Now the same exact thing can be said about the irqs. If I need to assign irq1 
to the cpus in sets A and B but not C I have to create set X that is the union 
of A and B, and assign irq1 to the set X.

This is what I meant by "deeper hierarchies" in the earlier emails.

Did I do a better job explaining this time :) ?

Max