Re: [patch] CONFIG_NR_CPUS

Thomas 'Dent' Mirlacher (dent@cosy.sbg.ac.at)
Thu, 6 Jun 2002 23:49:46 +0200 (MET DST)


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.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/