On Wed, 15 Feb 2006, Andrew Morton wrote:
>
> 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).
sched_init() calls init_idle for the current CPU.
Perhaps more importantly, every _single_ CPU that comes up must call
init-idle pretty much by definition. It's really what starts the whole
scheduling thing - the scheduler itself very much depends on the "idle"
task for each CPU.
So the reason I thought that Rik's patch was a cleanup was not because it
was needed (initializing cpu_possible_map early should fix up the
problems), but because it would actually be a very natural thing to do to
to initialize the scheduler data structures as part of init-idle. The
scheduler really isn't initialized until it has an idle thread anyway.
init_idle() already does part of the scheduler initializations, a pretty
fundamental part, in fact:
rq->curr = rq->idle = idle;
and the fact that "sched_init()" does some _other_ part of scheduler data
structure initialization is actually just ugly.
So I like Rik's patch, but I don't feel _too_ strongly about it. The
people who actually work on the scheduler should be the ones to sign off
(or not) on it.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
