Dimitri Sivanich wrote:
quoted text
> On Wed, Nov 19, 2008 at 03:25:15PM -0500, Gregory Haskins wrote:
>  =20
>> It sounds like the problem with my code is that "null sched domain"
>> translates into "default root-domain" which is understandably unexpect=
ed
quoted text
>> by Dimitri (and myself).  Really I intended root-domains to become
>> associated with each exclusive/disjoint cpuset that is created.  In a
>> way, non-balanced/isolated cpus could be modeled as an exclusive cpuse=
t
quoted text
>> with one member, but that is somewhat beyond the scope of the
>>    =20
>
> Actually, at one time, that is how things were setup.  Setting the
> cpu_exclusive bit on a single cpu cpuset would isolate that cpu from
> load balancing.
>  =20

Re-reading my post made me realize what I said above was confusing.  The
"that" in "but that is somewhat beyond the scope" was meant to be
"explicit/direct support for the no-balance flag".  However, it perhaps
sounded like I was talking about exclusive cpusets with singleton
membership.  Exclusive cpusets are the original raison-d'etre for
root-domains. ;)

Therefore I agree that the exclusive cpuset portion should work (but
seems to be broken, thus the bug report).  My primary goal is to fix
this issue.  However, I would also like to *add* support for the
no-balance flag as a secondary goal.  Its just that this is new feature
from my perspective, so may it take some additional work to figure out
what needs to be done.  HTH and sorry for the confusion.

-Greg
quoted text
>  =20
>> root-domain code as it stands today.  My primary concern was that
>> Dimitri reports that even creating a disjoint cpuset per cpu does not
>> yield an isolated root-domain per cpu.  Rather they all end up in the
>> default root-domain, and this is not what I intended at all.
>>
>> However, as a secondary goal it would be nice to somehow directly
>> support the "no-load-balance" option without requiring explicit
>> exclusive per-cpu cpusets to do it.  The proper mechanism (IMHO) to
>> scope the scheduler to a subset of cpus (including only "self") is
>> root-domains so I would prefer to see the solution based on that.=20
>> However, today there is a rather tight coupling of root-domains and
>> cpusets, so this coupling would likely have to be relaxed a little bit=

quoted text
>> to get there.
>>
>> There are certainly other ways to solve the problem as well.  But seei=
ng
quoted text
>> as how I intended root-domains to represent the effective partition
>> scope of the scheduler, this seems like a natural fit in my mind until=

quoted text
>> its proven to me otherwise.
>>
>>    =20
>
> Agreed.=20
>  =20