3

I have a program that provides benchmarks, but its OS agnostic and does not know how to read CPU frequencies. The test program is driven through a script. If I provide the CPU frequency, then the program can calculate throughput of operations.

I thought I would provide the current CPU frequency (for the most accurate reading), but it appears the value is read-only for root and no access for others:

$ ls -Al /sys/devices/system/cpu/cpu0/cpufreq/
total 0
-r--r--r-- 1 root root 4096 Jan 27 23:19 affected_cpus
-r-------- 1 root root 4096 Jan 27 23:19 cpuinfo_cur_freq
-r--r--r-- 1 root root 4096 Jan 27 23:19 cpuinfo_max_freq
-r--r--r-- 1 root root 4096 Jan 27 23:19 cpuinfo_min_freq
...
-rw-r--r-- 1 root root 4096 Jan 27 23:19 scaling_max_freq
-rw-r--r-- 1 root root 4096 Jan 27 23:19 scaling_min_freq
-rw-r--r-- 1 root root 4096 Jan 27 23:19 scaling_setspeed

As ls -l shows, cpuinfo_cur_freq is the only object with that particular ACL. The other entries are mostly 0444 (0644 for some).

Why is current CPU frequency read-only for root and no access for others?

4
  • does the file /sys/devices/system/cpu/cpu0/online exist? if not, then your system doesn't support certain actions on that particular core (some architectures have dependencies on cpu0, so you cannot take it offline, etc). see the yellowbox warning here: cyberciti.biz/faq/debian-rhel-centos-redhat-suse-hotplug-cpu/… . If the permissions are more lenient on cpu1 then it is very likely that the issue is specific to that core. – Frank Thomas Jan 28 '16 at 4:55
  • @Frank - it appears the file does not exist: cat: /sys/devices/system/cpu/cpu0/online: No such file or directory. – jww Jan 28 '16 at 6:37
  • then that implies that the core is locked, and the system won't let anyone change it. For the most part the files in /sys/devices/ are barely files, in that they read data from the running state of the box, but don't generally control them. – Frank Thomas Jan 29 '16 at 2:47
  • Still have the issue? I'm seeing it in Debian stable (stretch), but sudo chmod a+r changes permissions ok. Also seeing scaling_cur_freq values randomly bouncing around -+10% or more, while cpuinfo_cur_freq & /proc/cpuinfo & cpufreq_info are all steady & apparently correct. – Xen2050 Mar 10 '19 at 14:51
3

You should be able to read

scaling_cur_freq

To answer the question:

It seems that reading

cpuinfo_cur_freq

communicates directly with the hardware or - depending on implementation - the firmware which obviously shouldn't be allowed unprivileged.

Source

5
  • Thanks @Hydranix. The machine I am testing on has EFI, and not BIOS. The other machines I frequently test on are IoT gadgets, like BananaPi's and BeagleBone's. Some of them are producing incorrect results with scaling_cur_freq. For example, my LeMaker HiKey (ARM64), with dual Cortex-A53s (eight cores) running at 1.2 GHz, is producing a value of 432000. And my BananaPi Pro, with a Cortext-A7 running at 1 GHz, is producing a value of 600000. – jww Jan 28 '16 at 6:57
  • @jww: Doesn't matter if it's BIOS or EFI or OFW. The point is that the value is obtained from firmware, rather than set up to be sent to the firmware. – user1686 Jan 28 '16 at 8:11
  • Edited to reduce misinterpretations. – Hydranix Jan 28 '16 at 9:08
  • Thanks again @Hydranix. Trying to use the scaling value is producing horrible results. They are totally disconnected from the advertised CPU speed these processors are sold under. Even scaling_max_freq makes no sense. To make matters worse, there's no man page for cpuinfo or cpufreq, so I'm not sure how the value is supposed to be used. All my searching leads back to, "just do X and use scaling factor" (and the scaling factor is not explained). – jww Jan 28 '16 at 19:46
  • 2
    cpufreq - kernel.org/doc/Documentation/cpu-freq – Hydranix Jan 29 '16 at 4:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.