On Wed, Mar 03, 2021 at 10:51:31PM +0800, Thomas Gleixner wrote: > On Tue, Mar 02 2021 at 10:52, Feng Tang wrote: > > There are cases that tsc clocksource are wrongly judged as unstable by > > clocksource watchdogs like hpet, acpi_pm or 'refined-jiffies'. While > > there is hardly a general reliable way to check the validity of a > > watchdog, and to protect the innocent tsc, Thomas Gleixner proposed [1]: > > > > "I'm inclined to lift that requirement when the CPU has: > > > > 1) X86_FEATURE_CONSTANT_TSC > > 2) X86_FEATURE_NONSTOP_TSC > > 3) X86_FEATURE_NONSTOP_TSC_S3 > > 4) X86_FEATURE_TSC_ADJUST > > 5) At max. 4 sockets > > > > After two decades of horrors we're finally at a point where TSC seems > > to be halfway reliable and less abused by BIOS tinkerers. TSC_ADJUST > > was really key as we can now detect even small modifications reliably > > and the important point is that we can cure them as well (not pretty > > but better than all other options)." > > > > So implement it with slight change as discussed in the thread, and be > > more defensive to use maxim of 2 sockets. > > Can you please explain the slight change in the changelog? Sorry for the late response. Just found this mail in my "Junk Mail" folder with 3 copies, interesting mail sever filters!
I will add "As feature #3 X86_FEATURE_NONSTOP_TSC_S3 only exists on several generations of Atom processor, and is always coupled with X86_FEATURE_CONSTANT_TSC and X86_FEATURE_NONSTOP_TSC, skip checking it" to the commit log. Thanks, Feng > Thanks, > > tglx
