lkml.org 
[lkml]   [2000]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: CONFIG_SMP_CPUS
From
Date
Ingo Molnar <mingo@elte.hu> writes:

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

A better solution is to group the various per-cpu data into a single
structure instead of having them scattered as they are now, and then allocate
as many of these structures as there are CPUs. This allocation can be done
automatically by the CPU detection and boot-up code, you don't have to
specify manually the number of CPUs. This also allows the same compiled
kernel to be used on machines with different numbers of CPUs. Have a look at
my PDA patch at http://reality.sgi.com/dimitris_engr/pda_patch-2.4.0-1 for
how this can be done.

--
Dimitris Michailidis dimitris@engr.sgi.com

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.025 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site