[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47D83858.4030806@qualcomm.com>
Date: Wed, 12 Mar 2008 13:08:56 -0700
From: Max Krasnyanskiy <maxk@...lcomm.com>
To: Paul Jackson <pj@....com>
CC: menage@...gle.com, mingo@...e.hu, a.p.zijlstra@...llo.nl,
linux-kernel@...r.kernel.org
Subject: Re: boot cgroup questions
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists