From: Mike Travis <travis@sgi.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Rusty Russell <rusty@rustcorp.com.au>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] cpumask: use maxcpus=NUM to extend the cpu limit as well as restrict the limit
Date: Thu, 11 Dec 2008 10:19:46 -0800 [thread overview]
Message-ID: <494159C2.5020401@sgi.com> (raw)
In-Reply-To: <20081211134131.GB6264@osiris.boeblingen.de.ibm.com>
Heiko Carstens wrote:
> On Thu, Dec 11, 2008 at 03:28:09AM -0800, Mike Travis wrote:
>> Impact: allow adding additional cpus.
>>
>> Use maxcpus=NUM kernel parameter to extend the number of possible cpus as well
>> as (currently) limit them. Any cpus >= number of present cpus will disabled.
>>
>> The ability to HOTPLUG ON cpus that are "possible" but not "present" is
>> dealt with in a later patch.
>
> Hm.. documentation/kernel-parameters.txt says:
>
> maxcpus= [SMP] Maximum number of processors that an SMP kernel
> should make use of. maxcpus=n : n >= 0 limits the
> kernel to using 'n' processors. n=0 is a special case,
> it is equivalent to "nosmp", which also disables
> the IO APIC.
>
> but documentation/cpu-hotplug.txt says:
>
> 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.
>
> Dunno... it all looks like a mess ;)
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.]
I just figured that re-using the same kernel parameter was better than adding
another. But I'm willing to go either way.
Btw, I did alter the Documentation/kernel-parameters.txt file:
maxcpus= [SMP] Maximum number of processors that an SMP kernel
should make use of. maxcpus=n : n >= 0 limits the
kernel to using 'n' processors. n=0 is a special case,
it is equivalent to "nosmp", which also disables
the IO APIC. On [X86] maxcpus can also be used to
extend the number of possible cpus to overcome ACPI
tables that do not indicate disabled cpus, as well as
allow for additional cpus to be HOT PLUGGED in.
Format: <0-NR_CPUS>
In modifying the code, I could not find any arch-specific instances and the only
general case was in the 3 references in init/main.c, so I figured it was pretty
safe to use.
Thanks,
Mike
next prev parent reply other threads:[~2008-12-11 18:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 11:28 [PATCH 0/4] cpumask: fixups and additions Mike Travis
2008-12-11 11:28 ` [PATCH 1/4] x86: fix assign_irq_vector boot up problem Mike Travis
2008-12-12 8:27 ` Rusty Russell
2008-12-12 9:20 ` Ingo Molnar
2008-12-12 18:10 ` Mike Travis
2008-12-12 19:06 ` Mike Travis
2008-12-11 11:28 ` [PATCH 2/4] x86: fix cpu_mask_to_apicid_and to include cpu_online_mask Mike Travis
2008-12-12 11:06 ` Rusty Russell
2008-12-12 16:37 ` Mike Travis
2008-12-13 12:03 ` Rusty Russell
2008-12-11 11:28 ` [PATCH 3/4] cpumask: use maxcpus=NUM to extend the cpu limit as well as restrict the limit Mike Travis
2008-12-11 13:41 ` Heiko Carstens
2008-12-11 18:19 ` Mike Travis [this message]
2008-12-12 10:03 ` Heiko Carstens
2008-12-12 11:41 ` Rusty Russell
2008-12-12 15:38 ` Mike Travis
2008-12-11 11:28 ` [PATCH 4/4] cpumask: add sysfs displays for configured and disabled cpu maps Mike Travis
2008-12-12 11:44 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=494159C2.5020401@sgi.com \
--to=travis@sgi.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox