From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC][PATCH] powerpc: respect how command line nr_cpus is set
Date: Thu, 05 May 2011 12:25:02 +1000 [thread overview]
Message-ID: <1304562302.2513.418.camel@pasglop> (raw)
In-Reply-To: <1304540257-19831-1-git-send-email-galak@kernel.crashing.org>
On Wed, 2011-05-04 at 15:17 -0500, Kumar Gala wrote:
> We should utilize nr_cpus as the max # of CPUs that we can have present
> instead of NR_CPUS. This way we actually respect how nr_cpus is set on
> the command line rather than ignoring it.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> I think this is what we should be doing, but would like someone else to take
> a look.
The main question I have is should max_cpus absolutely limit the number
of possible CPUs or should it limit the number that get automatically
onlined at boot, potentially letting us bring the rest online later on ?
Cheers,
Ben.
> - k
>
> arch/powerpc/kernel/setup-common.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index 21f30cb..fedf813 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -424,7 +424,7 @@ void __init smp_setup_cpu_maps(void)
>
> DBG("smp_setup_cpu_maps()\n");
>
> - while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < NR_CPUS) {
> + while ((dn = of_find_node_by_type(dn, "cpu")) && cpu < nr_cpu_ids) {
> const int *intserv;
> int j, len;
>
> @@ -443,7 +443,7 @@ void __init smp_setup_cpu_maps(void)
> intserv = &cpu; /* assume logical == phys */
> }
>
> - for (j = 0; j < nthreads && cpu < NR_CPUS; j++) {
> + for (j = 0; j < nthreads && cpu < nr_cpu_ids; j++) {
> DBG(" thread %d -> cpu %d (hard id %d)\n",
> j, cpu, intserv[j]);
> set_cpu_present(cpu, true);
> @@ -483,12 +483,12 @@ void __init smp_setup_cpu_maps(void)
> if (cpu_has_feature(CPU_FTR_SMT))
> maxcpus *= nthreads;
>
> - if (maxcpus > NR_CPUS) {
> + if (maxcpus > nr_cpu_ids) {
> printk(KERN_WARNING
> "Partition configured for %d cpus, "
> "operating system maximum is %d.\n",
> - maxcpus, NR_CPUS);
> - maxcpus = NR_CPUS;
> + maxcpus, nr_cpu_ids);
> + maxcpus = nr_cpu_ids;
> } else
> printk(KERN_INFO "Partition configured for %d cpus.\n",
> maxcpus);
next prev parent reply other threads:[~2011-05-05 2:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 20:17 [RFC][PATCH] powerpc: respect how command line nr_cpus is set Kumar Gala
2011-05-05 2:25 ` Benjamin Herrenschmidt [this message]
2011-05-05 11:38 ` Kumar Gala
2011-05-05 22:29 ` Benjamin Herrenschmidt
2011-05-12 0:26 ` [RFC] " Milton Miller
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=1304562302.2513.418.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=galak@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.