Messages in this thread |  | | Date | Thu, 26 Apr 2018 23:11:23 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: Reducing time of smpboot |
| |
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 |  |