I have been using AMD processors for years but my new systems are Intel Haswell (i5-4770S and i7-4770). With the old systems I can use a gkrellm plugin to display the current frequencies for each CPU. With the new Haswell processors, this is no longer true. The reason is that /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq which is ro0444 is not created. Unfortunately, /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq cannot be used because it is ro0400 and needs access by superuser. This could be viewed as an RFE or as a bug report since it does break some existing code (gkrellm-gkfreq and xfce4-cpufreq-plugin). I do not normally work with kernel code but I am looking at intel_pstate.c to see if I can figure out a patch to add the functionality.
scaling_cur_freq is not created due the type of scaling driver intel_pstate is. For scaling drivers that that implement an internal governor the cpufreq core does not implement this file. I will talk to Rafael to see what we can do here.
It sure would be nice to have a single, common variable which displayed the current freq of a core (thread). I have looked at the output from turbostat running opn i5-4570S and i7-4770 processors and the freq shown by turbostat is not the same as that in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq. After some pilot errors on my part, what I have seen shows me that the frequency adjustment/power manage code is working well for Haswell processors.
For this comment "Unfortunately, /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq cannot be used because it is ro0400 and needs access by superuser." Why doesn't it make the file as ro0444? I always forget to either change it to 0444 or run my script that monitors the frequency as superuser. I can not think of any good reason that the file should default to 0444.
guys, any update on this?
I may have the history a little off here but as I understand it cpuinfo_cur_freq required root privileges due to the fact that forced a direct query to the hardware which could be expensive on some platforms where scaling_cur_freq would return the cached frequency request from the governor. For intel_pstate the answer would always be the same which is the frequency for the most recent sample so there is no reason for the file to need root privileges. Changing it may break other systems or open up a DOS vector.
(In reply to Dirk Brandewie from comment #5) > I may have the history a little off here but as I understand it > cpuinfo_cur_freq > required root privileges due to the fact that forced a direct query to the > hardware which could be expensive on some platforms where scaling_cur_freq > would return the cached frequency request from the governor. Correct.. > For intel_pstate the answer would always be the same which is the frequency > for the most recent sample so there is no reason for the file to need root > privileges. > > Changing it may break other systems or open up a DOS vector. Yeah, so that should stay whatever it is right now but we should make 'scaling_cur_freq' available for all drivers.
commit c034b02e213d271b98c45c4a7b54af8f69aaac1e
3.18-rc2: commit c034b02e213d271b98c45c4a7b54af8f69aaac1e Author: Dirk Brandewie <dirk.j.brandewie@intel.com> Date: Mon Oct 13 08:37:40 2014 -0700 cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers