The CPU frequency figures may show incorrect (or unnecessarily "N/A") values for CPU cores if some CPUs or cores have been taken logically offline.
The way I read it, the code currently sums the number of CPUs from /proc/stat, and then proceeds to read the frequencies for CPUs 0..N-1 (for N total CPUs as determined from the stat file) either from CPUfreq information in sysfs, or by parsing /proc/cpuinfo if frequency information from CPUfreq is unavailable or too slow to read.
This works correctly if all CPUs from 0 to N-1 are online.
However, if, say, on a quad-core system (CPUs 0..3), cores 1 and 3 have been taken logically offline, the total number of CPUs that appear in /proc/stat is 2, and the code attempts to read the frequencies for cores 0..1 rather than 0 and 2, although CPU 1 is offline with no valid frequency information available, and the second online core is actually number 2.
On my system, the frequency read from CPUfreq for CPU 1 would then appear to be some fixed value that's incorrect for the actual second online core. If the frequencies are read from /proc/cpuinfo instead, the frequency reported in htop for the second core would appear to be "N/A" instead.
This may be a bit of a weird corner case, but I've seen it when taking every second core offline to soft-disable SMT, so I thought I'd report it. I don't know how the entries in /sys/devices/system/cpu/ change if CPUs are disabled in a system with actual CPU hotplug, but I suppose this might affect some such systems as well.
I've been working on this a bit but I don't have a fix yet.
The CPU frequency figures may show incorrect (or unnecessarily "N/A") values for CPU cores if some CPUs or cores have been taken logically offline.
The way I read it, the code currently sums the number of CPUs from /proc/stat, and then proceeds to read the frequencies for CPUs 0..N-1 (for N total CPUs as determined from the stat file) either from CPUfreq information in sysfs, or by parsing /proc/cpuinfo if frequency information from CPUfreq is unavailable or too slow to read.
This works correctly if all CPUs from 0 to N-1 are online.
However, if, say, on a quad-core system (CPUs 0..3), cores 1 and 3 have been taken logically offline, the total number of CPUs that appear in /proc/stat is 2, and the code attempts to read the frequencies for cores 0..1 rather than 0 and 2, although CPU 1 is offline with no valid frequency information available, and the second online core is actually number 2.
On my system, the frequency read from CPUfreq for CPU 1 would then appear to be some fixed value that's incorrect for the actual second online core. If the frequencies are read from /proc/cpuinfo instead, the frequency reported in htop for the second core would appear to be "N/A" instead.
This may be a bit of a weird corner case, but I've seen it when taking every second core offline to soft-disable SMT, so I thought I'd report it. I don't know how the entries in /sys/devices/system/cpu/ change if CPUs are disabled in a system with actual CPU hotplug, but I suppose this might affect some such systems as well.
I've been working on this a bit but I don't have a fix yet.