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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ