Messages in this thread | | | Subject | Re: CONFIG_SMP_CPUS | From | Dimitris Michailidis <> | Date | 10 Jul 2000 01:37:55 -0700 |
| |
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/
| |