Kevin D. Kissell wrote:
The behavior of the two loops is not the same because sched_init
is called long before smp_prepare_cpus. Therefore for_each_cpu
only loops once for CPU 0. I know this is not a great fix.
I simply reverted the code to what's worked before.
It's certainly the code that I'm still using! ;o) So prom_build_cpu_map
needs to be called earlier (as in maybe from smp_prepare_boot_cpu?).
OK, when I wrote the above, I was blinded by the fact that I'm personally
doing my SMP (SMTC) work on a downrev development tree, where prom_build_cpu_map()
is still invoked explicitly from smp_prepare_cpus(), just before prom_prepare_cpus().
In those sources, I was able to do what I describe and have the for_each_cpu()
in sched_init() work fine.
But apparently current sources no longer even invoke prom_build_cpu_map(),
having merged that functionality with prom_prepare_cpus(). It looks to me
as if calling prom_prepare_cpus() from smp_prepare_boot_cpu() as in the
patch below, should do the right thing in all current cases, but it *is*
standing the SMP startup logic a bit on its head. Maybe this is why
prom_build_cpu_map() had a separate existence in the first place...
Regards,
Kevin K.
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 5e18986..7ec9579 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -236,7 +236,6 @@ void __init smp_prepare_cpus(unsigned in
init_new_context(current, &init_mm);
current_thread_info()->cpu = 0;
smp_tune_scheduling();
- prom_prepare_cpus(max_cpus);
}
/* preload SMP state for boot cpu */
@@ -251,6 +250,8 @@ void __devinit smp_prepare_boot_cpu(void
cpu_set(0, phys_cpu_present_map);
cpu_set(0, cpu_online_map);
cpu_set(0, cpu_callin_map);
+ /* This is done early to populate phys_cpu_present_map for sched_init */
+ prom_prepare_cpus(max_cpus);
}
/*
