search

MatthiasSchinzel / sysmon

Graphical system monitor for linux, including information about CPU, GPU, Memory, HDD/SDD and your network connections. Similar to windows task manager.
GNU General Public License v3.0
294 stars 25 forks source link

cpufreq depends on scheduler #14

Open h1z1 opened 3 years ago

h1z1 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.