Messages in this thread | | | Date | Wed, 06 Apr 2005 17:49:46 +1000 | From | Nick Piggin <> | Subject | Re: [patch 1/5] sched: remove degenerate domains |
| |
Ingo Molnar wrote: > * Nick Piggin <nickpiggin@yahoo.com.au> wrote: > > >>This is Suresh's patch with some modifications. > > >>Remove degenerate scheduler domains during the sched-domain init. > > > actually, i'd suggest to not do this patch. The point of booting with a > CONFIG_NUMA kernel on a non-NUMA box is mostly for testing, and the > 'degenerate' toplevel domain exposed conceptual bugs in the > sched-domains code. In that sense removing such 'unnecessary' domains > inhibits debuggability to a certain degree. If we had this patch earlier > we'd not have experienced the wrong decisions taken by the scheduler, > only on the much rarer 'really NUMA' boxes. >
True. Although I'd imagine it may be something distros may want. For example, a generic x86-64 kernel for both AMD and Intel systems could easily have SMT and NUMA turned on.
I agree with the downside of exercising less code paths though.
What about putting as a (default to off for 2.6) config option in the config embedded menu?
> is there any case where we'd want to simplify the domain tree? One more > domain level is just one (and very minor) aspect of CONFIG_NUMA - i'd > not want to run a CONFIG_NUMA kernel on a non-NUMA box, even if the > domain tree got optimized. Hm? >
I guess there is the SMT issue too, and even booting an SMP kernel on a UP system. Also small ia64 NUMA systems will probably have one redundant NUMA level.
If/when topologies get more complex (for example, the recent Altix discussions we had with Paul), it will be generally easier to set up all levels in a generic way, then weed them out using something like this, rather than put the logic in the domain setup code.
Nick
-- SUSE Labs, Novell Inc.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |