The other worry was if the threshold of turbo/not turbo frequency is enough. I do not know how to test any final solution thoroughly, as so far I have simply found a good enough problematic example. We have so many years of experience with the convenient multi second NMI forcing lingering high pstate clean up. I'd keep it deciding within it if the TSC stuff needs to be executed or not. Anyway... Base Kernel 5.17-rc3. "stock" : unmodified. "revert" : with commit b50db7095fe reverted "rjw-2" : with this version2 patch added. Test 1 (as before. There is no test 2, yet.): 347 Hertz work/sleep frequency on one CPU while others do virtually no load but enough to increase the requested pstate, but at around 0.02 hertz aggregate. It is important to note the main load is approximately 38.6% @ 2.422 GHz, or 100% at 0.935 GHz. and almost exclusively uses idle state 2 (of 4 total idle states) /sys/devices/system/cpu/cpu7/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu7/cpuidle/state1/name:C1_ACPI /sys/devices/system/cpu/cpu7/cpuidle/state2/name:C2_ACPI /sys/devices/system/cpu/cpu7/cpuidle/state3/name:C3_ACPI Turbostat was used. ~10 samples at 300 seconds per. Processor package power (Watts): Workflow was run for 1 hour each time or 1249201 loops. revert: ave: 3.00 min: 2.89 max: 3.08 ave freq: 2.422 GHz. overruns: 1. max overrun time: 113 uSec. stock: ave: 3.63 (+21%) min: 3.28 max: 3.99 ave freq: 2.791 GHz. overruns: 2. max overrun time: 677 uSec. rjw-2: ave: 3.14 (+5%) min: 2.97 max: 3.28 ave freq: 2.635 GHz overruns: 1042. max overrun time: 9,769 uSec. ... Doug
