1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Linux's "Ondemand" Governor Is No Longer Fit

Linux Kernel

Published on 17 May 2013 01:58 PM EDT
Written by Michael Larabel in Linux Kernel
60 Comments

By default the Linux kernel uses the "ondemand" CPU frequency governor for achieving maximum clock frequency when system load is high and a lower clock frequency when the system is idle. However, it turns out that for at least modern Intel CPUs, this is likely no longer the case. This default kernel choice may lead to poor battery life and performance for modern Linux systems.

Theodore Ts'o, the well known Linux kernel developer and EXT4 file-system maintainer, wrote a Google+ post to Arjan van de Ven, one of the Intel OTC Linux developers. "Some folks internally have been arguing (and with data that appears to support their thesis) that with modern Intel processors, the ondemand CPU governor is actually counterproductive because waking up to decide whether the CPU is idle keeps it from entering the deepest sleep states, and so (somewhat counterintuitively) the performance governor will actually result in the best battery life."

Arjan responded that the findings are correct and that the ondemand cpufreq algorithm dates back to about a decade ago. Arjan also says the Linux kernel's cpufreq is also a problem. In working to address this problem, the recent Linux 3.9 kernel introduced the Intel P-State driver, as previously covered on Phoronix.

About the new Intel P-State option for the Linux kernel, Arjan explained:
First of all, we use the enumeration of the hardware capabilities that Intel processors provide, which means we're not limited by what ACPI can express (ACPI is a bit too limiting on anything modern).
We also, and I realize this might be controversial, combine the control algorithm with the cpu driver in one. The reality is that such control algorithms are CPU specific, the notion of a generic "for all cpus" governors is just outright flawed; hardware behavior is key to the algorithm in the first place....

The algorithm also, and we'll be tuning this for a while still, much more in line with modern hardware behavior.... we are seeing very significant power/performance improvements with the 3.9/3.10rc code over using ondemand, and a much smaller performance gap with the "performance" governor in terms of performance.

the 3.9/3.10-rc1 code right now only supports SNB cpus, but the CPU ID of IVB is about to added as well.
In a later Google+ comment, Arjan says he hopes the Ivy Bridge P-State support will still be added to the Linux 3.10 kernel as it's just changing around one line of code. Needless to say, I will be running a bunch of benchmarks very shortly from Sandy Bridge (and then Ivy Bridge) hardware to see how the new Intel P-State situation changes the power/performance of the latest Intel hardware on Linux. Separately I'll also deliver some new cpufreq governor benchmarks from various processors. Other test requests for Phoronix can be delivered to the forums or my Twitter feed. I will be starting this new Linux power/performance examination this weekend.

On a similar note, going back to earlier this month, Phoronix readers in the forums have been discussing the ondemand governor slowing down the Mesa/Gallium3D drivers with noticeably better performance when turning to the cpufreq performance governor. Stay tuned for some exciting tests!

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Articles & Reviews
  1. OS X 10.10 vs. Ubuntu 15.04 vs. Fedora 21 Tests: Linux Sweeps The Board
  2. The New Place Where Linux Code Is Constantly Being Benchmarked
  3. 18-GPU NVIDIA/AMD Linux Comparison Of BioShock: Infinite
  4. Phoronix Test Suite 5.6 Adds New Phoromatic Enterprise Benchmarking Features
  5. OpenGL Threaded Optimizations Responsible For NVIDIA's Faster Performance?
  6. Big Graphics Card Comparison Of Metro Redux Games On Linux
Latest Linux News
  1. Git 2.4.0-rc0 Does A Ton Of Polishing
  2. The Most Common, Annoying Issue When Benchmarking Ubuntu On Many Systems
  3. Mesa Is At Nearly 1,500 Commits This Year
  4. Gestures & Other GTK3 Features For LibreOffice
  5. It's Now Easier To Try PHP 7 On Fedora & RHEL
  6. BQ Is Cleaning Up Their Aquaris E4.5 Ubuntu Kernel
  7. Allwinner Continues Jerking Around The Open-Source Community
  8. NVIDIA Linux 349.12 Beta Has Improved G-SYNC & VDPAU Features
  9. Canonical Just Made It Even Easier To Benchmark Ubuntu Linux In The Cloud
  10. NVIDIA GeForce GTX TITAN X Linux Testing Time
Most Viewed News This Week
  1. Introducing The Library Operating System For Linux
  2. AMD Is Hiring Two More Open-Source Linux GPU Driver Developers
  3. New SecureBoot Concerns Arise With Windows 10
  4. GNOME Shell & Mutter 3.16.0 Released
  5. GNU Nano 2.4.0 Brings Complete Undo System, Linter Support & More
  6. Systemd Change Allows For Stateless Systems With Tmpfs
  7. GCC 5 Compiler Is Getting Close To Being Released
  8. Red Hat Is Rolling Out A VirtIO DRM/KMS GPU Driver
%%CLICK_URL_UNESC%%