Re: [PATCH] fix init_idle() locking problem
From: Ingo Molnar
Date: Tue May 11 2004 - 04:38:08 EST
* Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
> When starting up secondary CPUs, most architectures do something like
> do_boot_cpu(int cpu)
> idle = fork_by_hand();
> init_idle(idle, cpu);
> init_idle() removes "idle" from its runqueue, but there's a window
> between looking up the runqueue and locking it, where another CPU can
> move "idle" to a different runqueue, i.e., via load_balance().
the sched-domains patches that are now in BK solve this problem in a
cleaner way: the rule is that no cross-CPU balancing is allowed until
all CPUs have booted up.
This is enforced by having a boot-time sched-domains tree (initialized
very early on, prior setting up any IRQ sources, in sched_init()), that
isolates each and every CPU from each other - so load_balance() cannot
balance away an idle task. Once all CPUs have booted up the arch can
'cross-connect' all the CPUs and scheduling will begin for real.
this two-phase approach enabled us to reduce alot of the early-boot
[ btw., your patch does not seem to be correct anyway - if an online CPU
'steals' the new idle task then it will also most likely run it - and
that is disastrous for any CLONE_IDLETASK task. (e.g. on x86 the EIP has
random content, most likely crashing that CPU.) ]
the hotplug CPU code of course must be (and is) extra careful about
installing the new idle task.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/