Tony, My laziness keeps making me want to just set it to 32 and call it good.
At the same time, I have a nagging feeling we should really rework this considerably. I don't see a compelling reason to pre-allocate anything except the boot cpus per_cpu area. The others, I would guess, could be alloc_bootmem_node allocations on the cpu's node at per_cpu_init time. We could maintain an array of pre-nulled per_cpu_data pointers, seed with the reservation on node 0, and then alloc_bootmem_node and init whenever per_cpu_init finds a NULL. I have not looked at this too closely. I would guess it is far too invasive for this point in the release cycle anyway. I don't think I could have this done and tested within a week. Would you mind putting in the patch as it was with 32? If so, would you want that as a #define? We could come back to the alloc_bootmem_node idea when we have more time to think it over. Either way, I would not think it is significantly worse than the extreme space wasting we see as NR_CPUS increases. Thanks, Robin - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
