On 2021/04/06 07:27, Marcus MERIGHI wrote: > Morning! > > scottchel...@gmail.com (Scott Cheloha), 2021.04.05 (Mon) 22:25 (CEST): > > To be clear, userland TSC is disabled on this machine, yes? And this > > is a physical server, not a VM? > > $ sysctl |grep tsc > kern.timecounter.hardware=tsc > > Do you want me to disable this?
This is different and is for the kernel timecounter source. The message "disabling user TSC" relates to using TSC on the CPU currently executing code directly in userland, bypassing the call into the kernel and avoiding some locking. Without userland TSC it calls into the kernel to fetch time, using whatever source the kernel is using (which could be TSC or acpihpet or i8254 etc). I think (but am not 100% sure) that when used as the kernel source, TSC is always queried from the boot processor so it doesn't matter about differences between cores. Whereas from userland it uses the TSC in whichever cpu is running the current process so this is important (a static skew is corrected but if the cpu clocks don't advance in sync with each other that will cause problems and means that this metjod can't bebuswd). > yasuoka@ found a dmesg with > > cpu11: disabling user TSC (skew=240) > cpu11: smt 0, core 3, package 1 > > from this server (on ports@). I do not see such messages in the current > dmesg. If you use the diff with "if (abs(diff) < abs(val))" to change how the skew is calculated, it may well not trigger the "disabling user TSC" so check dmesg with either plain -current, or just the diff to add debug.
