Bug 73741

Summary:	intel_pstate.c does not support scaling_cur_freq and breaks gkrellm-gkfreq monitor
Product:	Power Management	Reporter:	Gene Czarcinski (gczarcinski)
Component:	intel_pstate	Assignee:	Dirk Brandewie (dirk.brandewie)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	aaron.lu, dsmythies, lenb, rjw, rui.zhang, viresh.kumar
Priority:	P1
Hardware:	Intel
OS:	Linux
Kernel Version:	3.13.8	Subsystem:
Regression:	No	Bisected commit-id:

Description Gene Czarcinski 2014-04-09 15:47:25 UTC

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.

Comment 1 Dirk Brandewie 2014-04-15 15:03:59 UTC

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.

Comment 2 Gene Czarcinski 2014-04-15 18:26:38 UTC

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.

Comment 3 Doug Smythies 2014-04-30 00:15:47 UTC

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.

Comment 4 Zhang Rui 2014-06-03 06:40:36 UTC

guys, any update on this?

Comment 5 Dirk Brandewie 2014-09-09 15:45:53 UTC

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.

Comment 6 Viresh Kumar 2014-09-10 03:50:54 UTC

(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.

Comment 7 Dirk Brandewie 2014-11-06 14:56:19 UTC

commit c034b02e213d271b98c45c4a7b54af8f69aaac1e

Comment 8 Len Brown 2015-07-21 19:22:24 UTC

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