On Sun, 9 Jul 2000 willy@thepuffingroup.com wrote:
> we have a lot of arrays which are declared as being NR_CPUS elements
> large. this is clearly suboptimal on the majority of SMP machines
> which have only 2 CPUs. i therefore believe this should be a config
> option. what do you think to this patch?
i've been doing this for a long time on dual systems, so there is no
stability problem with this at all.
The only ugly thing that kept me from not submitting a patch for this is
the fact that if there are *more* CPUs than NR_CPUS, then we crash in very
subtle ways. It once took me a couple of hours to find out ... So i'd
propose to add the attached patch as well, to make CONFIG_NR_CPUS truly
safe and 'fool proof' ;-) [And you also want to consider that AFAIR
Sparc64 can have 64 CPUs, so the 1-32 range is not universial.]
Ingo
--- linux/arch/i386/kernel/smpboot.c.orig Sun Jul 9 14:36:37 2000
+++ linux/arch/i386/kernel/smpboot.c Sun Jul 9 14:38:16 2000
@@ -49,7 +49,7 @@
static int smp_b_stepping = 0;
/* Setup configured maximum number of CPUs to activate */
-static int max_cpus = -1;
+static unsigned int max_cpus = NR_CPUS;
/* Total count of live CPUs */
int smp_num_cpus = 1;
@@ -93,6 +93,8 @@
static int __init maxcpus(char *str)
{
get_option(&str, &max_cpus);
+ if (max_cpus > NR_CPUS)
+ max_cpus = NR_CPUS;
return 1;
}
@@ -952,7 +954,7 @@
if (!(phys_cpu_present_map & (1 << apicid)))
continue;
- if ((max_cpus >= 0) && (max_cpus <= cpucount+1))
+ if (cpucount > max_cpus)
continue;
do_boot_cpu(apicid);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:10 EST