[PATCH] Double x86 initialise fix.

[PATCH] Double x86 initialise fix.

[davej]

For many moons, we've been executing identify_cpu()
on the boot processor twice on SMP kernels.
This is harmless, but has a few downsides..
- Extra cruft in bootlog/dmesg
- Spawns one too many timers for the mcheck handler
- possibly other wasteful things..

This seems to do the right thing here..

diff -urpN --exclude-from=/home/davej/.exclude bk-linus/arch/i386/kernel/smpboot.c linux-2.5/arch/i386/kernel/smpboot.c
--- bk-linus/arch/i386/kernel/smpboot.c	2002-10-20 20:21:24.000000000 -0100
+++ linux-2.5/arch/i386/kernel/smpboot.c	2002-10-25 15:39:26.000000000 -0100
@@ -118,7 +118,8 @@ static void __init smp_store_cpu_info(in
 	struct cpuinfo_x86 *c = cpu_data + id;
 
 	*c = boot_cpu_data;
-	identify_cpu(c);
+	if (id!=0)
+		identify_cpu(c);
 	/*
 	 * Mask B, Pentium, but not Pentium MMX
 	 */

Re: [PATCH] Double x86 initialise fix.

[Alan Cox]

On Sat, 2002-10-26 at 13:42, davej@codemonkey.org.uk wrote:
> For many moons, we've been executing identify_cpu()
> on the boot processor twice on SMP kernels.
> This is harmless, but has a few downsides..
> - Extra cruft in bootlog/dmesg
> - Spawns one too many timers for the mcheck handler
> - possibly other wasteful things..
> 
> This seems to do the right thing here..

How do you know the boot CPU is CPU#0

Re: [PATCH] Double x86 initialise fix.

[Dave Jones]

On Sat, Oct 26, 2002 at 02:56:20PM +0100, Alan Cox wrote:
 > > For many moons, we've been executing identify_cpu()
 > > on the boot processor twice on SMP kernels.
 > > This is harmless, but has a few downsides..
 > > - Extra cruft in bootlog/dmesg
 > > - Spawns one too many timers for the mcheck handler
 > > - possibly other wasteful things..
 > > 
 > > This seems to do the right thing here..

Isn't this always the case on x86 ?
/me waits to hear gory details of some IBM monster.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk

Re: [PATCH] Double x86 initialise fix.

[Alan Cox]

> Isn't this always the case on x86 ?
> /me waits to hear gory details of some IBM monster.

It isnt. The boot CPU may be any number. In addition you can strap dual
pentium boxes to arbitrate for who is boot cpu (this is used for fault
tolerance).

Re: [PATCH] Double x86 initialise fix.

[Martin J. Bligh]

>> Isn't this always the case on x86 ?
>> /me waits to hear gory details of some IBM monster.
> 
> It isnt. The boot CPU may be any number. In addition you can strap dual
> pentium boxes to arbitrate for who is boot cpu (this is used for fault
> tolerance).

Eh? I don't understand this, and I think Dave is right for all the
IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
numbers are dynamically assigned as we boot, so the boot CPU will
always get 0, surely?

M.

Re: [PATCH] Double x86 initialise fix.

[Martin J. Bligh]

>>> Isn't this always the case on x86 ?
>>> /me waits to hear gory details of some IBM monster.
>> 
>> It isnt. The boot CPU may be any number. In addition you can strap dual
>> pentium boxes to arbitrate for who is boot cpu (this is used for fault
>> tolerance).
> 
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?

Indeed cscope indicates these are acutally hardcoded into the calls:

1 smpboot.c smp_callin    418 smp_store_cpu_info(cpuid);
2 smpboot.c smp_boot_cpus 989 smp_store_cpu_info(0);

The only thing that does smp_callin is a secondary ... so the boot
CPU has this hardcoded to 0 ... I think Dave's fine.

M.

Re: [PATCH] Double x86 initialise fix.

[Alan Cox]

On Sat, 2002-10-26 at 16:00, Martin J. Bligh wrote:
> >> Isn't this always the case on x86 ?
> >> /me waits to hear gory details of some IBM monster.
> > 
> > It isnt. The boot CPU may be any number. In addition you can strap dual
> > pentium boxes to arbitrate for who is boot cpu (this is used for fault
> > tolerance).
> 
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?

Ok its a logical ID - so yes

Re: [PATCH] Double x86 initialise fix.

[Zwane Mwaikambo]

On 26 Oct 2002, Alan Cox wrote:

> > Eh? I don't understand this, and I think Dave is right for all the
> > IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> > numbers are dynamically assigned as we boot, so the boot CPU will
> > always get 0, surely?
> 
> Ok its a logical ID - so yes

<pedantic> kernel logical ID ;)  </pedantic>

-- 
function.linuxpower.ca

Re: [PATCH] Double x86 initialise fix.

[Eric W. Biederman]

Dave Jones <davej@codemonkey.org.uk> writes:

> On Sat, Oct 26, 2002 at 02:56:20PM +0100, Alan Cox wrote:
>  > > For many moons, we've been executing identify_cpu()
>  > > on the boot processor twice on SMP kernels.
>  > > This is harmless, but has a few downsides..
>  > > - Extra cruft in bootlog/dmesg
>  > > - Spawns one too many timers for the mcheck handler
>  > > - possibly other wasteful things..
>  > > 
>  > > This seems to do the right thing here..
> 
> Isn't this always the case on x86 ?
> /me waits to hear gory details of some IBM monster.

If it is the logical cpu id yes, then id 0 is always the bootstrap
cpu.

For apic id #0 to not be the bootstrap cpu you don't need an IBM
monster, there are several SMP machines with that property.

Eric