Bug 697273

Summary: Unable to set ondemand governor on Atom-based server
Product: Red Hat Enterprise Linux 6 Reporter: Lukas Zapletal <lzap>
Component: powertopAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED ERRATA QA Contact: Jeff Bastian <jbastian>
Severity: low Docs Contact:
Priority: low    
Version: 6.0CC: azelinka, ddumas, emcnabb, jbastian, jskarvad, lzap, ovasik
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: powertop-2.3-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: The upstream code doesn't take into account whether the ondemand governor is usable on the platform. Consequence: The powertop could suggest ondemand governor even if it is not possible to use it on the platform. Fix: The code was patched and two checks were added. The ondemand governor is additionally not suggested if it is not in the list of available governors (this means there is no kernel support - the driver is either not compiled for the kernel or there is no implementation for the platform) or if the CPU transition time from one frequency to another is above the maximal limit allowed by the ondemand governor. Result: The ondemand governor is no longer suggested in the tuning suggestions if it cannot be activated on the current kernel / HW.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 07:52:40 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:
Attachments:
Description Flags
Proposed patch
none
powertop-2.X: proposed fix none

Description Lukas Zapletal 2011-04-17 12:04:27 UTC 
Description of problem:

Hello, got a Atom-based server disc array and there's a problewm when setting ondemand or conservative governor. 

Version-Release number of selected component (if applicable):

Red Hat Enterprise Linux Server release 6.0 (Santiago)

Intel(R) Atom(TM) CPU D410   @ 1.66GHz

Linux box 2.6.32-71.18.2.el6.i686 #1 SMP Wed Mar 2 14:38:52 EST 2011 i686 i686 i386 GNU/Linux

tried also on 2.6.32-71.24.1.el6

How reproducible:

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Actual results:

# dmesg
ondemand governor failed, too long transition latency of HW, fallback to performance governor

Additional info:

Not a fatal error. Low prio.
Comment 3 Jaroslav Škarvada 2011-04-17 21:28:05 UTC 
This CPU seems not to have the Enhanced Intel SpeedStep (http://ark.intel.com/Product.aspx?id=43517), thus the kernel is probably right because the high transition latency can affect the CPU performance under ondemand governor. AFAIK you should be able to use the userspace governor and control the frequencies by hand or by user space daemon.
Comment 4 Jaroslav Škarvada 2011-04-17 21:45:32 UTC 
Please, what is your:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency

The PowerTOP could be patched not to suggest ondemand in such cases.
Comment 5 RHEL Program Management 2011-04-18 06:00:11 UTC 
Since RHEL 6.1 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 6 Lukas Zapletal 2011-04-18 07:25:19 UTC 
@Jaroslav:

Which userspace daemon should I use then?

Here is the output:

[root@xxx ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
ondemand conservative userspace performance 

[root@xxx ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency 
10000001


[root@box ~]# cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D410   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.670
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3332.96
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 28
model name	: Intel(R) Atom(TM) CPU D410   @ 1.66GHz
stepping	: 10
cpu MHz		: 1666.670
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips	: 3332.83
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

Thanks for helping me out.
Comment 7 Jaroslav Škarvada 2011-04-18 09:48:40 UTC 
Created attachment 492841 [details]
Proposed patch

With the attached patch it shouldn't suggest ondemand governor if it is not supported or the cpu transition latency is higher than the ondemand governor max_transition_latency (10ms).

Please test this patch, the experimental build with this patch applied:
https://brewweb.devel.redhat.com/taskinfo?taskID=3264418

For cpufreq switching on your system you can use e.g. cpuspeed daemon:
# yum install cpuspeed
# chkconfig cpuspeed on
And change your default governor in /etc/sysconfig/cpuspeed to:
GOVERNOR=userspace
Comment 8 Lukas Zapletal 2011-04-18 12:00:54 UTC 
I just installed i686 version of your RPM and I can confirm this helped.

Your patch works just great.

ps - the cpuspeed runs fine too

Many thanks :-)
Comment 17 Jaroslav Škarvada 2013-06-28 12:20:45 UTC 
Created attachment 766551 [details]
powertop-2.X: proposed fix

It doesn't seem to be fixed in powertop-2.X. Proposed fix sent upstream.
Comment 21 Lukas Zapletal 2013-07-04 16:25:55 UTC 
I can confirm it does work now, although I see some floods with this message over powertop screen sometimes:

timer_expire_entry event returned no function value?

This is another story, perhaps. Thanks for help! :-D
Comment 22 Jaroslav Škarvada 2013-07-04 22:11:41 UTC 
(In reply to Lukas Zapletal from comment #21)
> I can confirm it does work now, although I see some floods with this message
> over powertop screen sometimes:
> 
> timer_expire_entry event returned no function value?
> 
> This is another story, perhaps. Thanks for help! :-D

Thanks for testing. You need updated kernel, this is tracked by bug 881030.
Comment 24 errata-xmlrpc 2013-11-21 07:52:40 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1575.html