Messages in this thread | | | Date | Fri, 12 Dec 2008 11:03:30 +0100 | From | Heiko Carstens <> | Subject | Re: [PATCH 3/4] cpumask: use maxcpus=NUM to extend the cpu limit as well as restrict the limit |
| |
On Thu, Dec 11, 2008 at 10:19:46AM -0800, Mike Travis wrote: > Heiko Carstens wrote: > > maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using > > maxcpus=2 will only boot 2. You can choose to bring the > > other cpus later online, read FAQ's for more info. > > > > It used to be (implementation wise) that maxcpus doesn't influence the number > > of possible cpus but just indicated how many cpus were brought online at startup > > of the kernel. Which is what cpu-hotplug.txt describes. > > > > Other present cpus would appear offline and could be brought online later. > > > > For s390 I added the possible_cpus kernel parameter back then, since my > > understanding back then was that maxcpus doesn't and shouldn't influence the > > number of possible cpus: > > > > possible_cpus=n [s390 only] use this to set hotpluggable cpus. > > This option sets possible_cpus bits in > > cpu_possible_map. Thus keeping the numbers of bits set > > constant even if the machine gets rebooted. > > Hmm, I hadn't noticed that. For a while the X86 devel kernel had an > "additional_cpus=n" parameter, which was also a bit confusing. Say you > wanted, 64 total, you had to give the increment over how many you already > had [e.g., (want)64 - (have)16 = (additional_cpus=)48.]
Yes, we had the additional_cpus parameter as well. But that was too confusing. Especially if you add a few cpus while the system is running and then reboot it. The result for (want) would vary for each configuration change and reboot.
That's why I added possible_cpus to s390, then you get (want) == possible_cpus.
> I just figured that re-using the same kernel parameter was better than adding > another. But I'm willing to go either way.
Maybe you could go for possible_cpus as well? Having this in sync for several architectures seems not so bad :)
| |