linux-kernel - Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

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

Date:   Wed, 27 Sep 2017 20:11:40 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Pavel Tatashin <pasha.tatashin@...cle.com>, schwidefsky@...ibm.com,
        heiko.carstens@...ibm.com, john.stultz@...aro.org,
        sboyd@...eaurora.org, x86@...nel.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
        douly.fnst@...fujitsu.com
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early
 in boot

On Wed, Sep 27, 2017 at 03:45:06PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote:
> > In Linux printk() can output timestamps next to every line.  This is very
> > useful for tracking regressions, and finding places that can be optimized.
> > However, the timestamps are available only later in boot. On smaller
> > machines it is insignificant amount of time, but on larger it can be many
> > seconds or even minutes into the boot process.
> 
> The sched_clock work I did for ARM could be setup really early at boot,
> from setup_arch().  I tried to encourage platforms to do that, but all
> my encouragement fell on deaf ears - most people setup the sched_clock
> source along side the time initialisation on ARM.
> 
> I don't think we need yet another "early" mechanism to solve this problem,
> we just need people to use the existing mechanism to register their
> sched_clock implementation earlier.

x86 is a bit 'special' in the whole sched_clock department. But yes, we
should very much make the regular sched_clock() happen earlier.