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
*/
On Sat, 2002-10-26 at 13:42, [email protected] 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
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
> 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).
Dave Jones <[email protected]> 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
>> 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.
>>> 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.
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
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