> On Feb 2, 2022, at 13:29, Stuart Henderson <s...@spacehopper.org> wrote: > > Thanks for testing. > >> On 2022/02/02 13:51, Dave Voutila wrote: >> >> Jason McIntyre <j...@kerhand.co.uk> writes: >> >>> On Wed, Feb 02, 2022 at 04:52:40PM +0000, Stuart Henderson wrote: >>>> This definitely wants testing on Ryzen ThinkPads (e.g. >>>> E485/E585/X395/T495s) >>>> or Inspiron 5505, I see user TSC disabled on a lot of those in dmesglog. >>>> >>>> >>> >>> hi. >>> >>> here are the results from a 5505. was the timecounter meant to switch >>> from tsc? >>> >>> jmc >>> >>> $ sysctl kern.timecounter >>> kern.timecounter.tick=1 >>> kern.timecounter.timestepwarnings=0 >>> kern.timecounter.hardware=i8254 >>> kern.timecounter.choice=i8254(0) tsc(-1000) acpihpet0(1000) acpitimer0(1000) >>> >> >> I'm seeing the same issue...switching to i8254 pit where before it was >> using tsc. :( > > There are two separate related things, one is the kernel choice, and the > other is whether TSC can be used directly from userland for gettimeofday > and friends without a syscall. Does the dmesg without the diff say "user > TSC disabled"? If so then it was only using it in the kernel. > > From reading the diff, I do expect that tsc priority is dropped if the > measurements indicate problems, but I wonder why it falls back to i8254 > even though acpihpet/acpitimer are available and higher priority..
Because we drop the TSC quality after adding it as the active timecounter. This violates assumptions in kern_tc.c. If i8254 is added last, i8254 has a higher quality than the TSC and is made the active counter. The other counters don't factor in because the code assumed the active counter is the highest quality counter. ... which woulf be true if we weren't changing the quality after calling tc_init().
