`/proc/cpuinfo` has wrong cpu frequencies

[RagnarGrootKoerkamp]

On my Intel Nuc (CPU: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz), /proc/cpuinfo always shows 2400.000 MHz for most of the cores:

cpu MHz         : 1100.063
cpu MHz         : 1148.182
cpu MHz         : 2400.000
cpu MHz         : 2400.000
cpu MHz         : 2400.000
cpu MHz         : 2400.000
cpu MHz         : 2400.000
cpu MHz         : 2400.000

/sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq gives accurate values instead:

cat /sys/devices/system/cpu*/cpufreq/scaling_cur_freq
1156558
1101168
1108234
1200081
1200379
1200496
1201186
1201895

It turns out that on newer intel processors, /proc/cpuinfo does not report actual cpu frequencies anymore, reading this.

The PR implementing this notes that scaling_cur_freq can be slow, but at least on this CPU, that seems to be the only place to get the correct value.

[fasterit]

This seems like a bug that should go upstream to the Linux kernel. Because if your sample reading of /proc/cpuinfo is what you always get, it has the correct CPU frequency for one core and it wrong for the three others. NB: constant_tsc as per the linked Red Hat bug report is not a good indicator. It is present on a 7-gen Core as well and there reading the CPU frequency with our logic works fine.

[RagnarGrootKoerkamp]

Yeah maybe it should. But I don't know anything about TSC. Maybe that is lower for some cores some of the time (unlikely though)? There is also the nonstop_tsc feature which is set for my CPU.

My laptop (i7-10750H) has the same behaviour:

cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 2600.000
cpu MHz		: 893.481
cpu MHz		: 885.600
cpu MHz		: 891.814
cpu MHz		: 2600.000
cpu MHz		: 2600.000

To clarify: each time I do cat /proc/cpuinfo, a few (1 to 3) random/different cpus show an actual frequency (which is some number close to 900M in this case), while all other cpus show the exact value of their base frequency.

[gary094]

This exact behaviour happens on my i5 1135G7 as well. However it wasn't always the case. I believe after some update a few months ago (arch linux) I noticed these wrong frequencies as well. I tried to find the changes here on htop but couldn't find any indication of this being changed. I gave up then

[serfreeman1337]

With KDE I can get correct frequency reporting in htop by adding widget:

• Add Widgets -> Total Cpu Use -> Configure Total Cpu Use -> Sensors Details -> Text-Only Sensors -> [Group] CPU -> [Group] Clock frequency -> OK

Then htop process needs to be restarted. After that I can remove widget and will still get correct frequency reporitng on htop, although /proc/cpuinfo stays same all time.

Would like to know what's triggering htop to show actual frequency after adding monitor widget.

[bmwiedemann]

From reading https://www.reddit.com/r/openSUSE/comments/wtu2ft/cpu_frequency_is_not_minimal_in_idle_state/ my guess is that /proc/cpuinfo MHz values are only updated when a process is scheduled on a core

The best way to solve this would be to read /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq instead. It is even easier to parse - just 1 integer.

[BenBE]

The best way to solve this would be to read /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq instead. It is even easier to parse - just 1 integer.

It's just one integer, but several files to open/read/close, which causes the number of syscalls to increase. This might not look like an issue at first glance, but as each context switch to kernel space is kinda costly, it's usually cheaper to read one file and parse (even slightly more complicated data) than to open several files across various directories (which you might even have to locate first).

[CodeMonkey80s]

For my 13th Gen Intel(R) Core(TM) i7-13700K there is no such file like this one:

/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory

But current frequency seems to be stored in:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
3400000

[trr]

Can't tell you why it's different on my system, but I had to find the above in:

cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq

Have a Ivy Bridge 4 core 8 thread processor and the frequency of the 8th "cpu" is shown as wrong most of the time (edit: in /proc/cpuinfo). In scaling_cur_freq it appears to be a real figure.

I'd concur with above notes that it may be triggered when nothing is being scheduled on that CPU at the time, and that it just instead pretends it's running at some default multiplier (in my case, the maximum turbo frequency)