Kevin D. Kissell wrote: > The "for" loop is what used to be there, but if you use it in > a system with "hot-pluggable" CPUs, I could imagine that there > would be problems. While for_each_cpu is pathetically inefficient > as it gets expanded and compiled for MIPS, if your phys_cpu_present_map > (which is by default what gets used in MIPS as cpu_possible_map > for the purposes of sched.c) is being properly initialized and > maintained, the behavior of the two loops should be the same. > Have you double-checked that? Secondary CPUs turn generally > set their bits in that mask in prom_build_cpu_map(). > 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. Rojhalat Ibrahim
