[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <a93a1222-cd94-3129-7a11-59fce1af12a5@molgen.mpg.de>
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)
Powered by blists - more mailing lists