[RFC][PATCH] powerpc: respect how command line nr_cpus is set

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 <redacted>
---
I think this is what we should be doing, but would like someone else to take
a look.

- 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);

-- 
1.7.3.4

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 <redacted>
---
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.

On May 4, 2011, at 9:25 PM, Benjamin Herrenschmidt wrote:

On Wed, 2011-05-04 at 15:17 -0500, Kumar Gala wrote:

quoted

We should utilize nr_cpus as the max # of CPUs that we can have =

present

quoted

instead of NR_CPUS.  This way we actually respect how nr_cpus is set =

on

quoted

the command line rather than ignoring it.
=20
Signed-off-by: Kumar Gala <redacted>
---
I think this is what we should be doing, but would like someone else =

to take

quoted

a look.

=20
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 =

?

=20
Cheers,
Ben.

=46rom Documentation/kernel-parameters.txt:

        nr_cpus=3D        [SMP] Maximum number of processors that an SMP =
kernel
                        could support.  nr_cpus=3Dn : n >=3D 1 limits =
the kernel to
                        supporting 'n' processors. Later in runtime you =
can not
                        use hotplug cpu feature to put more cpu back to =
online.
                        just like you compile the kernel NR_CPUS=3Dn

Which makes me think we should have max_cpus be an absolute limit.

- k=

From Documentation/kernel-parameters.txt:

        nr_cpus=        [SMP] Maximum number of processors that an SMP kernel
                        could support.  nr_cpus=n : n >= 1 limits the kernel to
                        supporting 'n' processors. Later in runtime you can not
                        use hotplug cpu feature to put more cpu back to online.
                        just like you compile the kernel NR_CPUS=n

Which makes me think we should have max_cpus be an absolute limit.

Ok, looks like I've been confusing nr_cpus= vs. max_cpus= or something
like that.

I'll have a look at your patch later today.

Cheers,
Ben.

On Wed, 04 May 2011 around 10:17:37 -0000, 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 <redacted>

---
I think this is what we should be doing, but would like someone else to take
a look.

- k

 arch/powerpc/kernel/setup-common.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

This looks very similar to my patch at
http://patchwork.ozlabs.org/patch/95080/ except I also updated the
comment. Also, the variable is nr_cpu_ids while the parameter
is nr_cpus=, the first instance in in the changelog is referring to
the variable while the second is the parameter.

Sorry I took me so long get that part of my series tested and posted.

milton