linux-kernel - Re: [PATCH 0/9] x86: TSC calibration update

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

Date:	Fri, 10 Jun 2016 15:20:29 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Len Brown <lenb@...nel.org>
cc:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] x86: TSC calibration update

Len,

On Thu, 31 Mar 2016, Len Brown wrote:

> cpu_khz and tsc_khz initialization can be unreliable and expensive.
> They are initialized in tsc_init()/native_calibrate_tsc(), which prints:
> 
> pr_info("Detected %lu.%03lu MHz processor\n", cpu_khz...)
> 
> native_calibrate_cpu() first tries quick_pit_calibrate(),
> which can take over 50.0M cycles to succeed,
> or as few as 2.4M cycles to fail.
> 
> On failure, pit_calibrate_tsc() is attempted, which can succeed
> in as few as 20M cycles, but may consume over 240M cycles
> before it fails.
> 
> By comparison, on many processors, tsc frequency can be discovered by
> table and MSR or CPUID in under 0.002M cycles.

I found this in my backlog. Sorry for missing it. 

The series does not apply anymore and the hardcoded family constants want to
be replaced by the new model defines.

Could you please resend?

Thanks,

	tglx