Messages in this thread | | | Date | Wed, 19 Nov 2008 14:33:40 -0600 | From | Dimitri Sivanich <> | Subject | Re: RT sched: cpupri_vec lock contention with def_root_domain and no load balance |
| |
On Wed, Nov 19, 2008 at 03:25:15PM -0500, Gregory Haskins wrote: > It sounds like the problem with my code is that "null sched domain" > translates into "default root-domain" which is understandably unexpected > 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 cpuset > with one member, but that is somewhat beyond the scope of the
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.
> 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. > 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 > to get there. > > There are certainly other ways to solve the problem as well. But seeing > 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 > its proven to me otherwise. >
Agreed.
| |