On Fri, Jun 05, 2026, Thomas Gleixner wrote: > On Fri, May 29 2026 at 07:43, Sean Christopherson wrote: > > Don't re-calibrate the TSC frequency if the TSC is known to run at a fixed > > frequency. > > That's misleading because fixed frequency means that the frequency does > not change, i.e. X86_FEATURE_CONSTANT_TSC is set. But > X86_FEATURE_CONSTANT_TSC does not imply that the frequency can be read > from CPUID/MSRs.
Sorry, "if the TSC runs at a known, fixed frequency" would be a better way to phrase this. > > In practice, this is likely one big nop, as re-calibration is > > used only for SMP=n kernels, and only for hardware that is 20+ years old, > > i.e. is extremely unlikely to collide with TSC_KNOWN_FREQ. > > recalibrate_cpu_khz() is only invoked from Intel P4 and AMD K7 CPU > frequency drivers, which means that's absolutely not interesting and > neither X86_FEATURE_CONSTANT_TSC nor X86_FEATURE_TSC_KNOWN_FREQ can be > set on those systems. It _shouldn't_ be set on those systems, but in the world of virtualization it's not completely impossible. > IOW, this patch is pointless voodoo ware. Would y'all be opposed to adding a WARN? I don't actually care about P4 or K7 CPUs, but without any reference to X86_FEATURE_TSC_KNOWN_FREQ in recalibrate_cpu_khz(), the code _looks_ wrong, and so is very confusing for readers that don't already know that in practice, it's limited to ancient CPUs. In other words, the point is to document expectations and mutual exclusion, not to "fix" anything.
