linux-kernel - Re: [v3 1/2] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 15 Aug 2017 17:27:12 +0800
From:   Dou Liyang <douly.fnst@...fujitsu.com>
To:     Pasha Tatashin <pasha.tatashin@...cle.com>, <x86@...nel.org>,
        <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
        <peterz@...radead.org>, <tglx@...utronix.de>, <hpa@...or.com>
Subject: Re: [v3 1/2] sched/clock: interface to allow timestamps early in boot

Hi Pasha,

At 08/14/2017 11:44 PM, Pasha Tatashin wrote:
> Hi Dou,
>
> Thank you for your comments:
>
>>>  {
>>>      x86_init.timers.timer_init();
>>>      tsc_init();
>>> +    tsc_early_fini();
>>
>> tsc_early_fini() is defined in patch 2, I guess you may miss it
>> when you split your patches.
>
> Indeed, I will move it to patch 2.
>
>>> +static DEFINE_STATIC_KEY_TRUE(__use_sched_clock_early);
>>> +static bool __read_mostly sched_clock_early_running;
>>> +
>>
>> In my opinion, these two parameters are repetitive, I suggest remove
>> one.
>>
>> eg. remove sched_clock_early_running like below
>> First, static DEFINE_STATIC_KEY_FALSE(__use_sched_clock_early);
>
> We can't change the static branches before jump_label_init() is called,
> and we start early boot timestamps before that
>

I understood, I was wrong, thanks for your explanation.

Thanks
	dou.

> This is why having two booleans is appropriate: one that can be changed
> early in boot, and another to patch the hotcode in order to keep good
> performance after boot.
>
> I will update comment before __use_sched_clock_early explaining the
> reason why we need two of them.
>
> Thank you,
> Pasha
>
>
>