Re: Reducing time of smpboot

[Thomas Gleixner]

Paul,

On Thu, 5 Apr 2018, Paul Menzel wrote:
> Looking at the Linux 4.16 messages and the time stamps on the ASRock E350M1,
> there is the 100 ms jump below.
> 
> ```
> [    0.024000] Freeing SMP alternatives memory: 24K
> [    0.132000] smpboot: CPU0: AMD E-350D APU with Radeon(tm) HD Graphics
> (family: 0x14, model: 0x2, stepping: 0x0)
> [â]
> [    0.132000] smp: Bringing up secondary CPUs ...
> [    0.132000] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
> [    0.157950] CPU 1 irqstacks, hard=afb6c892 soft=83b5a704
> [    0.157956] x86: Booting SMP configuration:
> [    0.157959] .... node  #0, CPUs:      #1
> [    0.004000] Initializing CPU#1
> [    0.160213] smp: Brought up 1 node, 2 CPUs
> [    0.160213] smpboot: Max logical packages: 1
> [    0.160213] smpboot: Total of 2 processors activated (6400.34 BogoMIPS)
> ```
> 
> Also, the time stamp of the second CPU is out of order. Is that expected?

Kinda. It has not yet set up the proper infrastructure for printing correct
time stamps. That's a chicken and egg problem ...

> Are there debug options to figure out, what is happening in the 100 ms,
> without having to sprinkle print statements throughout the code?
> 
> Also, can the time be reduced? The firmware, coreboot in this case, should
> already set up the CPUs. So, can the second SMP init be avoided?

There is a difference between setup and bringup. The secondary CPU is
brought up via a special IPI or NMI and then it takes a break in the micro
code to prepare itself before magically making an appearance in the
kernel. There is not much we can do about that.

Thanks,

	tglx