Messages in this thread | | | Date | Wed, 15 Feb 2006 15:46:34 -0800 | From | Andrew Morton <> | Subject | Re: SMP BUG |
| |
Russell King <rmk+lkml@arm.linux.org.uk> wrote: > > On Wed, Feb 15, 2006 at 03:30:13PM -0800, Andrew Morton wrote: > > Linus Torvalds <torvalds@osdl.org> wrote: > > > That said, nobody seemed to comment on this patch by Rik, which seemed to > > > be a nice cleanup regardless of any other issues. > > > > I thought that patch wasn't a good one. The runqueues should be > > initialised in sched_init(). init_idle() is called from fork_idle() which > > is called from the bowels of arch code. I'm not sure that it gets called > > at all if !SMP (which seems strange). > > Wouldn't it make sense to do this initialisation in a CPU_UP_PREPARE > notifier, if not already done? >
Could be - we have a couple of notifier handlers in sched.c already, although they're inside awkward CONFIG_* wrappers.
But architectures need to initialise cpu_possible_map in setup_arch() anyway, because we immediately call setup_per_cpu_areas(), which needs to know which CPUs are possible so it will only allocate memory for them.
Yes, architectures can override the generic setup_per_cpu_areas(), but the same argument applies: they don't want to be allocating memory for !possible CPUs.
So I think it's sanest to say that the arch shalt initialise cpu_possible_map in setup_arch(). - 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/
| |