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/
This archive was generated by hypermail 2b29 : Fri Jun 07 2002 - 22:00:29 EST