linux-kernel - Re: Reducing time of smpboot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1804262308140.1596@nanos.tec.linutronix.de>
Date:   Thu, 26 Apr 2018 23:11:23 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paul Menzel <pmenzel+linux-x86@...gen.mpg.de>
cc:     Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        x86@...nel.org, linux-kernel@...r.kernel.org
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