Re: [patch] CONFIG_NR_CPUS

[Tom Rini <trini@kernel.crashing.org>]

On Thu, Jun 06, 2002 at 08:26:52AM -0700, Robert Love wrote:

> On Thu, 2002-06-06 at 03:15, David S. Miller wrote:
>  
> > Nice.  While you're at it can you fix the value on 64-bit
> > platforms when CONFIG_NR_CPUS is not specified?  (it should
> > be 64, not 32)
> 
> I agree, this is good.  I often am toying with some debugging aid that
> is an array of NR_CPUS and waste a lot of memory with NR_CPUS stuck at
> 32... no reason my kernels should not be set to 2 or whatever I need.
> 
> I have attached a patch that is Andrew's + your request, Dave.  Since
> what really determines the maximum number of CPUs is the size of
> unsigned long, I used that.  Cool?

Here's a (compile) tested version for PPC.  arch/ppc/kernel/smp.c makes
much less use of max_cpus, so this should be all that's needed. BTW, on
x86 max_cpus could become __initdata if someone cares..

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


===== arch/ppc/config.in 1.36 vs edited =====
--- 1.36/arch/ppc/config.in	Fri May 24 04:15:43 2002
+++ edited/arch/ppc/config.in	Thu Jun  6 09:30:39 2002
@@ -172,6 +172,7 @@
 bool 'Symmetric multi-processing support' CONFIG_SMP
 if [ "$CONFIG_SMP" = "y" ]; then
    bool '  Distribute interrupts on all CPUs by default' CONFIG_IRQ_ALL_CPUS
+   int  '  Maximum number of CPUs (2-32)' CONFIG_NR_CPUS 32
 fi
 if [ "$CONFIG_SMP" != "y" ]; then
    bool 'Preemptible Kernel' CONFIG_PREEMPT
===== arch/ppc/Config.help 1.10 vs edited =====
--- 1.10/arch/ppc/Config.help	Fri May 24 03:38:05 2002
+++ edited/arch/ppc/Config.help	Thu Jun  6 09:31:04 2002
@@ -14,6 +14,14 @@
 
   If you don't know what to do here, say N.
 
+CONFIG_NR_CPUS
+  This allows you to specify the maximum number of CPUs which this
+  kernel will support.  The maximum supported value is 32 and the
+  mimimum value which makes sense is 2.
+
+  This is purely to save memory - each supported CPU adds
+  approximately eight kilobytes to the kernel image.
+
 CONFIG_PREEMPT
   This option reduces the latency of the kernel when reacting to
   real-time or interactive events by allowing a low priority process to