On Tue, Apr 23, 2019 at 5:08 PM Peter Zijlstra <pet...@infradead.org> wrote: > Well, SKX isn't exactly 'missing'; it would be very good if we can > confirm the new code is still correct under the below mentioned > conditions. > > commit b511203093489eb1829cb4de86e8214752205ac6 > Author: Len Brown <len.br...@intel.com> > Date: Fri Dec 22 00:27:55 2017 -0500 > > x86/tsc: Fix erroneous TSC rate on Skylake Xeon > > The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is > problematic: > > - SKX workstations (with same model # as server variants) use a 24 MHz > crystal. This results in a -4.0% time drift rate on SKX workstations.
Checking http://instlatx64.atw.hu/ there are 11 platforms listed as 00050654 (skylake X), doing the calculations manually: 18-Core Intel Xeon Gold 6154, 3000 MHz: 25000000 2x 16-Core Intel Xeon Gold 6130, 2100 MHz: 25000000 2x 18-Core Intel Xeon Gold 6154, 3000 MHz: 25000000 2x 28-Core Intel Xeon Platinum 8180, 2500 MHz: 25000000 2x HexaCore Intel Xeon Bronze 3106: 25000000 2x OctalCore Intel Xeon Silver 4108, 3000 MHz: 25000000 10-Core Xeon W-2155: 23913043 HexaCore Intel Core i7-7800X: 23972602 10-Core Intel Core i9-7900X, 4000 MHz: 23913043 18-Core Intel Core i9-7980XE: 24074074 28-Core Intel Xeon W-3175X: 25000000 So given that the results include 24MHz and 25MHz crystal clocks calculated on different products then it looks like this variance is correctly accounted for. > - SKX servers subject the crystal to an EMI reduction circuit that > reduces its > actual frequency by (approximately) -0.25%. This results in -1 second > per > 10 minute time drift as compared to network time. > > This issue can also trigger a timer and power problem, on configurations > that use the LAPIC timer (versus the TSC deadline timer). Clock ticks > scheduled with the LAPIC timer arrive a few usec before the time they are > expected (according to the slow TSC). This causes Linux to poll-idle, > when > it should be in an idle power saving state. The idle and clock code do > not > graciously recover from this error, sometimes resulting in significant > polling and measurable power impact. > > Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X. > native_calibrate_tsc() will return 0, boot will run with tsc_khz = > cpu_khz, > and the TSC refined calibration will update tsc_khz to correct for the > difference. It sounds like I should add a condition: if (boot_cpu_data.x86_model != INTEL_FAM6_SKYLAKE_X) setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); so that refined TSC calibration will run on SKYLAKE_X. That does raise another question though. Taking other platforms such as KABYLAKE_MOBILE, the previous code hardcoded a precise 24MHz value, but my new code calculates 23893805Hz. Is that small discrepancy small enough to trigger the timer and power problem as described for SKYLAKE_X above? If so, maybe the logic should instead be: if (CPUID.0x15 provided Crystal Hz, i.e. we didn't have to calculate it) setup_force_cpu_cap(X86_FEATURE_TSC_KNOWN_FREQ); This would enable TSC refinement on all variants of skylake and kabylake. Daniel
