Robin Holt wrote: > On Wed, Feb 06, 2008 at 12:50:11PM +0900, Hidetoshi Seto wrote: >> Hidetoshi Seto wrote: >>> Then, I suppose we need a CPU_UP_PREPARE callback to allocate memory >>> before hot-added CPU enters cpu_init(). >> Ah, we cannot allocate bootmem later, so it would be better to make >> the callback to return NOTIFY_BAD if (!__per_cpu_mca[hcpu]). > > bootmem is only used for the first cpu. The other cpus use regular > allocations. So we should be able to do a CPU_UP_PREPARE. OK, it's my suggestion. > Comparing the severity of allocating a ton of extra memory with the > chance that we fail on an allocation and given that there are likely > other things in the cpu_init path which are not checked, do you see the > lack of check as a show-stopper for this patch or would you accept this > patch with the plan being fixup the cpu_init path later? Which other stuff in the cpu_init path would cause a panic on hot-added CPU? The per-cpu pages are ready for NR_CPUS. ia64_setreg(), ia64_set_kr() and kin would be work properly... I'm afraid that for hot-added CPU there might be nothing dangerous than this allocation in the path. That's why I want to hire a CPU_UP_PREPARE at least for this allocation. Thanks, H.Seto - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Wed Feb 06 23:40:21 2008
This archive was generated by hypermail 2.1.8 : 2008-02-06 23:40:35 EST