Re: [patch] CONFIG_NR_CPUS

[Thomas 'Dent' Mirlacher]

On Thu, 6 Jun 2002, Dave Jones wrote:

> On Thu, Jun 06, 2002 at 11:23:11PM +0200, Thomas 'Dent' Mirlacher wrote:
>  > > and then go edit every SMP-capable arch's config.in/Config.help
>  > > files.  But the arch maintainers should test one case please - x86
>  > > was locking up at boot on quad CPU with NR_CPUS=2.  Others may do
>  > > the same.
>  > 
>  > well, what you need to do is make sure smp_num_cpu <= NR_CPUS,
>  > otherwise the kernel will go ballistic on several places within
>  > the code.
> 
> *nod*, relying on the user to get it right may not be as simple
> as it seems. Quite a few people were pleasantly surprised when
> their 2-way P4 Xeon become a 4-way HT P4 box.

:)

you could allocate all the cpu-nr dependend structures during startup,
but then you're limited to the nr of cpus present at startup time
(and use smp_num_cpus instead of NR_CPUS)

- which means:

	1) no recompilation when you upgrade your (already smp) box
	2) no chance for cpu hotplugging

or the other choice, as it seems to be vafoured right now:

let the user pick, and blame the user if he/she did something wrong. 

and a question: is current_thread_info()->cpu a logical cpu#, or 
	a harwired one.

if it's a logical one, the easiest solution for not crashing the
kernel (on bootup - not talking about adding a cpu during runtime),
would be to restrict mac_cpus to NR_CPUS.
if it's a harwired one, well, the user has to live with the consequences
of a compilation time error.

just my $0.02

	tm

-- 
in some way i do, and in some way i don't.