Debian_SuperUser
Active Member
i5 8350U. Currently on Arch, but noticed it on other distros as well. In normal conditions, Intel P-state is active and I always set the performance governor. When monitoring through i7z and cross verified through turbostat as well, I am running at max frequency.
Note that kernel reported values are always quite unhelpful (mostly when idling actually), and I prefer to use programs which read it from hardware level which are the (mostly) real values.
Now if I suspend (sleep) the system and awaken it, P-state is still active, and the performance governor is still in charge, but I am no longer idling on max frequency. ~800 MHz, then maybe a gigahertz, 2 gigahertz, a bit of load then 3 gigahertz, then back to lower clocks, this is the amount of variation. And the frequency seems to be very asynchronous across all cores if the monitoring is working correctly. Note that I keep nmi_watchdog disabled which is recommended when reading frequency from hardware.
Though, when I actually put a full load, the frequency does ramp all the way up. It's only on the idling.
I have of course tried to re-enable the performance governor, playing with intel_pstate's status (active and passive), and setting pstate to passive and enabling userspace governor and setting the frequency that way, but it still doesn't work. The only way to get my clocks back is by a reboot.
I don't remember how all this is when acpi-cpufreq is on control, but I remember that the clock frequencies are still not all that good when that is active.
One thing that I have noticed is that after suspending the system, a lot of Intel power management stuff and all get reset, for example, my power limits get reset (although RAPL itself doesn't reflect the changes), and this thing also happens on Windows. Throttlestop on Windows also asks me to suspend and resume the system if I change something like Intel Speedstep or whatever.
I have just also noticed that disabling certain C-states and say, running in C1E only also lowers my clocks the same way, but enabling all the C-states back fixes this issue on the spot.
I thought it could be some problem with a module, and I managed to maybe think about Intel powerclamp. But I removed the module on the fly and nothing happened. The idle injection ratios under /sys/class/thermal/cooling_device*/cur_state also seem fine.
Note that kernel reported values are always quite unhelpful (mostly when idling actually), and I prefer to use programs which read it from hardware level which are the (mostly) real values.
Now if I suspend (sleep) the system and awaken it, P-state is still active, and the performance governor is still in charge, but I am no longer idling on max frequency. ~800 MHz, then maybe a gigahertz, 2 gigahertz, a bit of load then 3 gigahertz, then back to lower clocks, this is the amount of variation. And the frequency seems to be very asynchronous across all cores if the monitoring is working correctly. Note that I keep nmi_watchdog disabled which is recommended when reading frequency from hardware.
Though, when I actually put a full load, the frequency does ramp all the way up. It's only on the idling.
I have of course tried to re-enable the performance governor, playing with intel_pstate's status (active and passive), and setting pstate to passive and enabling userspace governor and setting the frequency that way, but it still doesn't work. The only way to get my clocks back is by a reboot.
I don't remember how all this is when acpi-cpufreq is on control, but I remember that the clock frequencies are still not all that good when that is active.
One thing that I have noticed is that after suspending the system, a lot of Intel power management stuff and all get reset, for example, my power limits get reset (although RAPL itself doesn't reflect the changes), and this thing also happens on Windows. Throttlestop on Windows also asks me to suspend and resume the system if I change something like Intel Speedstep or whatever.
I have just also noticed that disabling certain C-states and say, running in C1E only also lowers my clocks the same way, but enabling all the C-states back fixes this issue on the spot.
I thought it could be some problem with a module, and I managed to maybe think about Intel powerclamp. But I removed the module on the fly and nothing happened. The idle injection ratios under /sys/class/thermal/cooling_device*/cur_state also seem fine.
