Bug 741734

Summary:	FEAT: /sys should provide more accurate current cpu frequency
Product:	Red Hat Enterprise Linux 6	Reporter:	Rob Landry <rlandry>
Component:	kernel	Assignee:	Red Hat Kernel Manager <kernel-mgr>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Evan McNabb <emcnabb>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.2	CC:	gcase, gnichols, jfeeney, riel, salmy
Target Milestone:	beta	Keywords:	FutureFeature
Target Release:	6.3
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-22 23:05:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	767187

Description Rob Landry 2011-09-27 19:19:26 UTC

Description of problem:

Today the cpufreq values provided in sys/devices/system/cpu/cpuX/ may be inaccurate when compared to a aperfmperf values.  During the development of the updated hwcert cpuscaling for v7-1.4 aperfmperf was deemed to be the authoritative source of what speed is the core is actually running at. 


Steps to Reproduce:
1. compare aperfmperf calculation from aperf code provided by mjg to /sys cpuinfo_cur_freq and scaling_cur_freq values.
  
Actual results:
aperf and /sys show different values.

Expected results:
some /sys entry would show the same value as aperf.

Additional info:
TurboBoost/Core for example are not reflected in the current /sys values but appear in the aperf output.

Comment 3 Rik van Riel 2011-11-04 19:52:32 UTC

The CPU frequency can change several times a second with the in-kernel automatic CPU speed governors.

I would not be surprised to see different readings at different times.

Exactly what kind of discrepancies are you seeing?

Comment 4 Rob Landry 2011-11-14 22:22:06 UTC

Example:

This is on my laptop which is performing work (thunderbird, firefox, etc.) not similar to the test environment we should have on a v7 test box.


[root@unused cpufreq]# pwd
/sys/devices/system/cpu/cpu2/cpufreq
[root@unused cpufreq]# cat cpuinfo_cur_freq 
2701000
[root@unused cpufreq]# cat scaling_cur_freq 
800000
[root@unused cpufreq]# ~rlandry/Downloads/aperf 2
Freq: 3.045GHz
[root@unused cpufreq]# cpufreq-aperf 
CPU	Average freq(KHz)	Time in C0	Time in Cx	C0 percentage
000	2511930			00 sec 003 ms	00 sec 996 ms	00
001	3214190			00 sec 931 ms	00 sec 068 ms	93
002	2971100			00 sec 737 ms	00 sec 262 ms	73
003	2917080			00 sec 153 ms	00 sec 846 ms	15

000	2809040			00 sec 571 ms	00 sec 428 ms	57
001	2538940			00 sec 291 ms	00 sec 708 ms	29
002	1458540			00 sec 200 ms	00 sec 799 ms	20
003	1404520			00 sec 227 ms	00 sec 772 ms	22

^C
[root@unused cpufreq]# cat scaling_governor 
userspace
[root@unused cpufreq]# 


Today v7 uses mgj's aperf command as the authoritative value; though it is not part of the OS.

Comment 5 RHEL Program Management 2012-05-03 05:28:53 UTC

Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 7 Rik van Riel 2016-07-22 23:05:42 UTC

This feature has now been obsoleted by new hardware.

The latest CPUs scale the frequency all by themselves, autonomously from the operating system. Statistics on how much of each frequency was used get exported through sysfs.