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]

Message-ID: <56b59905-1d64-dca4-775a-925cbe9e7092@oracle.com>
Date:   Wed, 27 Sep 2017 13:13:15 -0400
From:   Pasha Tatashin <pasha.tatashin@...cle.com>
To:     Dou Liyang <douly.fnst@...fujitsu.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     linux@...linux.org.uk, 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
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early
 in boot

Hi Dou,

This makes sense. The current sched_clock_early() approach does not 
break it because with notsc TSC is used early in boot, and later 
stopped. But, notsc must stay.

Peter,

So, we could either expend sched_clock() with another static branch for 
early clock, or use what I proposed. IMO, the later is better, but 
either way works for me.

Thank you,
Pasha

On 09/27/2017 09:52 AM, Dou Liyang wrote:
> Hi Pasha, Peter
> 
> At 09/27/2017 09:16 PM, Pasha Tatashin wrote:
>> Hi Peter,
>>
>> I am totally happy with removing notsc. This certainly simplifies the
>> sched_clock code. Are there any issues with removing existing kernel
>> parameters that I should be aware of?
>>
> 
> We do not want to do that. Because, we use "notsc" to support Dynamic
> Reconfiguration[1].
> 
> AFAIK, this feature enables hot-add system board which contains CPUs
> and memories. But the CPUs in different board may have different TSCs
> which are not consistent with the TSC from the existing CPUs. If we 
> hot-add a board directly, the machine may happen the inconsistency of
> TSC.
> 
> We make our effort to specify the same TSC value as existing one through
> hardware and firmware, but it is hard. So we recommend to specify
> "notsc" option in command line for users who want to use Dynamic
> Reconfiguration.
> 
> [1] 
> http://www.fujitsu.com/global/products/computing/servers/mission-critical/primequest/technology/availability/dynamic-reconfiguration.html 
>