lkml.org 
[lkml]   [2018]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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
\
 
 \ /
  Last update: 2018-04-26 23:12    [W:0.073 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site