Messages in this thread | | | Date | Mon, 11 Aug 2008 11:40:00 -0700 | From | Max Krasnyansky <> | Subject | Re: [PATCH] Resurect proper handling of maxcpus= kernel option |
| |
Ingo Molnar wrote: > * Max.Krasnyansky@qualcomm.com <Max.Krasnyansky@qualcomm.com> wrote: > >> From: Max Krasnyansky <maxk@qualcomm.com> >> >> For some reason we had redundant parsers registered for maxcpus=. One >> in init/main.c and another in arch/x86/smpboot.c So I nuked the one in >> arch/x86. >> >> Also 64-bit kernels used to handle maxcpus= as documented in >> Documentation/cpu-hotplug.txt. CPUs with 'id > maxcpus' are >> initialized but not booted. 32-bit version for some reason ignored >> them even though all the infrastructure for booting them later is >> there. >> >> In the current mainline both 64 and 32 bit versions are broken. I'm >> too lazy to look through git history but I'm guessing it happened as >> part of the i386 and x86_64 unification. > > yes in essence. 32-bit always had maxcpus as a hard restriction in the > number of CPUs. This got extended to 64-bit as well, via commit > 89b08200ad: > > x86: make x86_64 accept the max_cpus parameter > > in v2.6.25. Two major kernel releases and nobody noticed - it's a rarely > used option.
btw I think it's rarely used because many people do not realize it's there. There are at least a couple of use cases that came up recently. - Busted cpu. You can boot the machine with maxcpus=1 and then bring up cpus one by one to see which one is busted. - Recently reported regression that 16cpu box booted fine with NRCPUS=8 but failed with NRCPUS=16. Again we can boot with maxcpus=8 and bring other cpus later to see when/where we fail.
Things like that.
Max
| |