> Not that I can think of. The early_cpu_possible_map will be a superset > of the cpu_possible_map. It might be a bigger superset than we'd like ... I'm not sure if there are any hard rules about how SRAT tables are populated. W.r.t. memory the entries tend to be broad: "If there is any memory in this range, then it belongs to this node". Perhaps cpu entries may exist in the SRAT without much regard to whether than can actually exist on the platform that we are executing on. But perhaps this is enough to solve the worst parts of the problem here. Small platforms will only populate SRAT out as far as they run their product line (32, 64, 128 cpus) ... so a kernel configured for 4096 cpus would at least limit the wasted allocations to this figure ... which is still a giant step forward. > If the machine does not have numa acpi > information, we will default to (currently 4 cpus) and initialize those > on node 0. We will then later only set the actual number in the > cpu_possible_map. There would be nothing (other than the lacking > hardware) which differentiates these processors from ones in the > cpu_possible_map. If you would like to go with the cpu_possible_map, I > will happily do some testing with that over the weekend. > > Could I get some direction on the number of cpus to define when there > are no numa tables? Do you know what the hardware limitation is for > number of processors on a FSB? The entries here are logical cpus, yes? So with Mont{ecito,vale} 4 sockets on the FSB * 2 cores * 2 threads = 16. I'm not sure that I understand the problems if we have too low a figure here. Will we: 1) crash 2) fail to use the cpus extra cpus 3) something else Looking further ahead ... a single node Tukwila will could have four sockets * 4 cores * 2 threads = 32. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |