[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <453735D8.5040100@yahoo.com.au>
Date: Thu, 19 Oct 2006 18:22:48 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Paul Jackson <pj@....com>
CC: holt@....com, suresh.b.siddha@...el.com, dino@...ibm.com,
menage@...gle.com, Simon.Derr@...l.net,
linux-kernel@...r.kernel.org, mbligh@...gle.com,
rohitseth@...gle.com, dipankar@...ibm.com
Subject: Re: exclusive cpusets broken with cpu hotplug
Paul Jackson wrote:
>>Paul Jackson wrote:
>>
>>>Nick wrote:
>>>
>>>
>>>>(we simply shouldn't allow
>>>>situations where we put a partition in the middle of a cpuset).
>>>
>>>
>>>Could you explain to me what you mean by "put a partition in the
>>>middle of a cpuset?"
>>>
>>
>>Your example, if a partition is created for each of the sub cpusets.
>
>
> The thing "we simply shouldn't allow", then, is the bread and
> butter of cpusets.
No. They can put a cpuset there all they like. But the cpuset code
should *not* put a partition there. That is all.
>
> I am convinced that we are trying to pound nails with toothpicks.
>
> The cpu_exclusive flag was the wrong flag to overload to define
> sched domains.
Well it is the correct flag if we only create the domain for the
oldest ancestor with the cpu_exclusive flag set. From the documentation:
"A cpuset may be marked exclusive, which ensures that no other
cpuset (except direct ancestors and descendents) may contain
any overlapping CPUs or Memory Nodes."
It is this non overlapping property that we can take advantage of, and
partition the scheduler. Obviously, the exception (from the POV of the
oldest ancestor) is its descendents, which can be overlapping. So just
don't create partitions for those guys.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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