Re: boot cgroup questions
From: Max Krasnyanskiy
Date: Wed Mar 12 2008 - 16:09:14 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/