cpufreq depends on scheduler

[h1z1]

Hi

Not sure how you want to handle it but scaling_cur_freq is not guaranteed to exist. When it doesn't the console scrolls with errors

cat: /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq: No such file or directory
cat: /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq: No such file or directory
cat: /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq: No such file or directory

Using acpi_idle for example:

/sys/devices/system/cpu/cpuidle/current_driver:acpi_idle
/sys/devices/system/cpu/cpuidle/current_governor_ro:menu

s'pose as a fallback you could parse cpuinfo, kinda messy either way.

[MatthiasSchinzel]

Hi

Thanks for the information! Then, we should definitively test if scaling_cur_freq exists!

Just for documentation: Problem with cpuinfo is that it does not show boost clock. It will stay at the maximum base frequency. So in this case I would prefer not showing any information at all, rather than potentially wrong data.

[h1z1]

Tracking things like boost clocks would be ...a nightmare no? XFR, AFR, CPR... Maybe a simpler idea is track the running maximum? Should make it pretty clear which CPUs are hitting per core XFR for example.