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/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:11 EST