linux-kernel - [v2 0/9] Early boot time stamps for x86

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:   Fri, 24 Mar 2017 11:21:30 -0400
From:   Pavel Tatashin <pasha.tatashin@...cle.com>
To:     x86@...nel.org, linux-kernel@...r.kernel.org, mingo@...hat.com,
        peterz@...radead.org, tglx@...utronix.de, hpa@...or.com
Subject: [v2 0/9] Early boot time stamps for x86

changelog
---------
v1 - v2
	In patch "x86/tsc: tsc early":
	- added tsc_adjusted_early()
	- fixed 32-bit compile error use do_div()

Adding early boot time stamps support for x86 machines.
SPARC patch see here:
http://www.spinics.net/lists/sparclinux/msg17372.html

sample output
-------------
Before:
https://hastebin.com/zofiqazuze.scala

After:
https://hastebin.com/otayoliruc.scala

example why early time is crucial
---------------------------------
Here is boot log on x86 machine with 8 E7-8895 CPUs, and 1T of memory:
https://hastebin.com/ebidosafic.pas

We want to improve boot time, by deferring vmemmap initialization to when
the secondary CPUs are online:
https://hastebin.com/migajadiju.pas

We see in the log that struct pages are initialized in parallel:
[   19.446609] node 0 initialised, 31980145 pages in 530ms
...

But, we have no idea if we saved overall boot time or not by enabling this
feature, because the total boot time as shown currently has not changed
much, and is actually increased from: 18.99s to 19.52s

Now, with this feature we would see right away that the time is actually
decreased:
Before:	https://hastebin.com/ivobehahud.pas
After:	https://hastebin.com/uvifasohon.pas

Boot time reduced from 40.68s to 31.41s, we saved 30% by enabling deferred
page initialization feature, great.

However, now, we have early boot time stamps, and we can analyze even
further, and see that we still spend a lot of time in this interval:
[    0.009071] kexec_core: crashkernel: memory value expected
[   11.255710] Zone ranges:

And, this is where this fix comes handy:
https://lkml.org/lkml/2017/3/23/864

The final boot time on this machine is this:
https://hastebin.com/anodiqaguj.pas

So, 20.7 seconds vs. 40.68s before, and we can show it with the early boot
time stamps, and avoid future regressions by having this data always
available to us.

Pavel Tatashin (9):
  sched/clock: broken stable to unstable transfer
  sched/clock: interface to allow timestamps early in boot
  x86/cpu: determining x86 vendor early
  x86/tsc: early MSR-based CPU/TSC frequency discovery
  x86/tsc: disable early messages from quick_pit_calibrate
  x86/tsc: use cpuid to determine TSC frequency
  x86/tsc: use cpuid to determine CPU frequency
  x86/tsc: tsc early
  x86/tsc: use tsc early

 arch/x86/include/asm/processor.h |   1 +
 arch/x86/include/asm/tsc.h       |   5 ++
 arch/x86/kernel/cpu/common.c     |  36 ++++++++
 arch/x86/kernel/head64.c         |   1 +
 arch/x86/kernel/time.c           |   1 +
 arch/x86/kernel/tsc.c            | 186 ++++++++++++++++++++++++++++++++++-----
 arch/x86/kernel/tsc_msr.c        |  38 +++++---
 include/linux/sched/clock.h      |   4 +
 kernel/sched/clock.c             |  70 ++++++++++++++-
 9 files changed, 304 insertions(+), 38 deletions(-)

-- 
1.8.3.1