linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Thu, 5 Apr 2018 22:46:00 +0200
From:   Paul Menzel <pmenzel+linux-x86@...gen.mpg.de>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Reducing time of smpboot

Dear Linux folks,

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?

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?

In my case, the configuration will never change, and always the same CPU 
will be used. Can the time be reduced by knowing about the configuration?

Kind regards,

Paul

View attachment "20180405–asrock_e350m1–dmesg.txt" of type "text/plain" (115758 bytes)