CPU clock rate can be displayed in meter instead of CPU load percentage

[aleksei-udalov]

Modern CPU can change frequency in wide range. I think it may be useful just to see the freq in htop.

This feature is disabled by default and can be enabled in setup->display options. This commit affected only text in meter. Bar keeps show CPU load. Tested on Linux only.

[hishamhm]

Hi! Thanks for the PR!

This is a great idea. I have toyed around with how to display the CPU rate info but it didn't occur to me to simply replace the percentages. Not something to be on by default, but an interesting design option.

I'm concerned about having clockRate as a field in the generic Meter structure, though. I think this should be redesigned (possibly using a Platform_getClockRate function in CPUMeter). A new flag value like Platform_hasClockRate could also be used in Settings to hide that option in platforms that do not (yet) support it.

[Explorer09]

Could I suggest that, instead of replacing the percentage (CPU time) in the CPUMeters, make clock rates a separate set of meters, with corresponding average?

[shawnl]

I like this patch, but agree with the feedback, as it is important to hide this on not just platforms, but also architectures that do not support it.

bash-4.4$ cat /proc/cpuinfo 
Processor	: ARMv7 Processor rev 2 (v7l)
processor	: 0
BogoMIPS	: 13.53

processor	: 1
BogoMIPS	: 13.53

processor	: 2
BogoMIPS	: 13.53

processor	: 3
BogoMIPS	: 13.53

Features	: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
CPU implementer	: 0x51
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0x06f
CPU revision	: 2

Hardware	: QCT APQ8064 MAKO
Revision	: 000b
Serial		: 0000000000000000

[MichaIng]

Want to push this PR, would be really great to have current CPU freqs within htop, also the way the PR suggests as replacement for usage % makes sense. Could be also added additionally (besides current usage). Perhaps 2-3 different options how/where to show it would be handy long term, since this depends on screen size as well.

This PR uses /proc/cpuinfo to read out the frequencies. I suggest to use /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq either instead or as alternative, if the other one is not available. If those files exist (one each CPU), you can be sure that the CPU freq is contained, different than in case of /proc/cpuinfo, where sometimes freqs are inside, sometimes not, and you need to scrape the right values first. /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq work very reliable at least during my tests. But jep, a test on startup and hide of the option/revert of the setting makes sense.

It's luckily a different case than CPU temperatures, where the read out interfaces vary veeery much between platforms/systems 😞.

[Arnavion]

New PR since I would like this feature too: https://github.com/hishamhm/htop/pull/932