lkml.org 
[lkml]   [2020]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] x86/tsc: Add tsc_guess flag disabling CPUID.16h use for tsc calibration
Date
Krzysztof Piecuch <piecuch@protonmail.com> writes:

> Changing base clock frequency directly impacts tsc hz but not CPUID.16h
> values. An overclocked CPU supporting CPUID.16h and partial CPUID.15h
> support will set tsc hz according to "best guess" given by CPUID.16h
> relying on tsc_refine_calibration_work to give better numbers later.
> tsc_refine_calibration_work will refuse to do its work when the outcome is
> off the early tsc hz value by more than 1% which is certain to happen on an
> overclocked system.

The above sets the context which is great, but it does not explain what the
solution is.

> + tsc_guess= [X86,INTEL] Don't use data provided by CPUID.16h during
> + early tsc calibration. Disabling this may be useful for
> + CPUs with altered base clocks.
> + Format: <bool> (1/Y/y=enable, 0/N/n=disable)
> + default: enabled

That's really a misnomer. CPUID.16h is way more than a guess. It's
pretty accurate except for the case you describe. This command line
option should clearly tell what it is about, i.e. overclocking.

Aside of that we have to be careful because on quite some modern systems
CPUID 16h is the only way to calibrate TSC and local APIC because PIT
and HPET are either not exposed or disfunct. So disabling CPUID.16h
should be prominently noted in dmesg.

Thanks,

tglx

\
 
 \ /
  Last update: 2020-01-15 22:47    [W:0.053 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site