Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH] percpu data: only iterate over possible CPUs | Date | Fri, 10 Feb 2006 11:13:12 +0100 |
| |
[putting some Xen people into cc]
On Friday 10 February 2006 11:05, Heiko Carstens wrote: > > > > powerpc/ppc64, for instance, determines the number of possible cpus > > > > from information exported by firmware (and I'm mystified as to why > > > > other platforms don't do this). So it's typical to have a kernel an a > > > > pSeries partition with NR_CPUS=128, but cpu_possible_map = 0xff. > > > > > > Simply because there is no such interface on s390. The only thing we know > > > for sure is that if we are running under z/VM the user is free to > > > configure up to 63 additional virtual cpus on the fly... > > > > x86-64 had the same problem, but we now require that you > > boot with additional_cpus=... for how many you want. Default is 0 > > (used to be half available CPUs but that lead to confusion) > > So introducing the additional_cpus kernel parameter seems to be the way > to go (for XEN probably too). Even though it seems to be a bit odd if the > user specifies both maxcpus=... and additional_cpus=...
With additional_cpus you don't need maxcpus. They are added together.
Also for Xen it's probably not needed by default, but the hypervisor can somehow pass it (it doesn't make sense to have more vcpus than real cpus and that should be relatively small number, so the memory waste shouldn't be that bad).
On x86-64 there is also a new firmware way to specify it, but current machines don't support that yet.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |