Optimize battery life and computing power with auto-cpufreq
Clock Speed
In Linux, the governor controls the CPU clock speed and power management. A tool called auto-cpufreq switches governors automatically to optimize battery runtime and computing power.
Modern CPU cores do not run constantly at the maximum possible clock speed, but instead, are capable of scaling the computing power up or down in defined steps as needed in order to save energy. On Linux, this task is performed by the CPU Frequency Scaling system (cpufreq) [1], which is built into the kernel.
Several different approaches or philosophies exist for how to accelerate the system. Is it better to immediately ramp up the clock speed to the max for a computing task, or should the system gradually increase the computing power? The CPU needs a large amount of energy at the highest clock speed, but, when it is running at a high speed, it completes the computing task more quickly, so that the CPU can go back to sleep. In contrast, the system often works more efficiently in power-saving mode, which reduces the heat loss, but the CPU has to compute for a longer time and can't go to sleep until the task is complete.
Linux deals with the conflicting goals of balancing computing performance, efficient power-saving functions, and comfortable responsiveness using six different cpufreq governors. Each of these governors uses a different algorithm for managing the CPU frequency. The governor decides when the CPU runs at what speed and sets a maximum limit. The governor options include:
- Performance – operates at the highest possible frequency, within the
scaling_max_freq
policy limit - Powersave – operates at the lowest possible frequency, within the
scaling_min_freq policy
limit - Userspace – allows the CPU frequency to be set in user space
- Ondemand – varies the frequency based on CPU load
- Conservative – varies the frequency based on CPU load (like the ondemand governor) but changes the frequency in relatively small steps, which is more efficient for some hardware and use cases
- Schedutil – accesses the CPU scheduler data directly to set the frequency based on CPU utilitization
The question of which governor to put in charge is left to the distribution developer. Of course, a higher frequency means the system runs faster, which is typically the best option as long as the computer is plugged in, but for a laptop or other portable devices running on battery power, the situation is a bit more complicated. Most Linux systems don't have a built-in solution for switching between governors on the fly. For example, in our lab, a freshly installed system with Ubuntu 20.10 on a Dell XPS 9570 always used the performance governor, regardless of whether the system was connected to the power supply or on battery power.
The Linux environment supports several tools to assist with optimizing battery life (see the box entitled "TLP"), but until recently, the system has lacked an efficient, automated tool for switching between governors based on system load and battery status. The recent utility called auto-cpufreq [3] attempts to address this need.
TLP
To manage a mobile computer's hunger for power, TLP [2] has established itself as a sort of standard in recent years. The program enables different CPU profiles as a function of the operating mode or turns off unneeded USB devices, Bluetooth, and WLAN where appropriate. The auto-cpufreq program provides some features that aren't available with TLP, such as the ability to change the governor automatically based on CPU load or battery status. According to the developer, auto-cpufreq is compatible with TLP and can be used on the same system.
Auto-cpufreq checks the system load and charge state (mains or battery) to decide which governor to enable. For battery operation in idle mode, or if the CPU load is low, auto-cpufreq enables the powersave governor. As soon as the load increases, the program switches to performance mode. When the computer is connected to the power supply, on the other hand, auto-cpufreq always leaves the system in the hands of the performance governor and enables the CPU's turbo mode, if available, so that the maximum computing power is always available.
Installation
The still quite young auto-cpufreq is not yet available from the package sources of the major distributions. However, the developer provides a cross-distribution snap package in the Snap Store [4]. Alternatively, you will find installation scripts for Debian, Red Hat, and their derivatives. Currently, the script route is recommended, because users report increased system load when installing the Snap package [5].
Use the commands in Listing 1 to set up auto-cpufreq on a freshly configured Ubuntu system. The s-tui
, stress
, and i7z
tools are not needed by auto-cpufreq itself; however, they do help you to check the system state and the computing load later on.
Listing 1
Install on Ubuntu
$ sudo apt install git s-tui stress i7z $ git clone https://github.com/AdnanHodzic/auto-cpufreq.git $ cd auto-cpufreq $ sudo ./auto-cpufreq-installer
Users of Arch Linux can pick up the program from the Arch User Repository (AUR). Unlike the installation script, the Arch recipe automatically sets up a systemd service, which you only need to enable and start after installation (Listing 2). The --install
option described later in this article is not necessary on Arch.
Listing 2
Install on Arch Linux
$ yay -S auto-cpufreq s-tui stress i7z $ sudo systemctl enable --now auto-cpufreq $ auto-cpufreq --log
Configuration
On an Ubuntu system, the install script simply injects the program into the system. For the configuration you then call auto-cpufreq
, and then the program will explain its options. The application needs administrative privileges. The following command:
sudo auto-cpufreq -monitor
initially only monitors the system and shows what the program would do differently. For example, in Figure 1, the program determines that the system is regulating the CPU with the performance governor, although it is not connected to the power supply and would therefore be better off running in powersave mode.
The following command
sudo auto-cpufreq -live
lets auto-cpufreq take over the control of the CPU – but only until you abort the program again with Ctrl+C. The tool does not permanently change anything in the system with this configuration. You can now easily check the functionality with the s-tui
command-line tool (Figure 2). If you switch to Stress mode (see the option in the middle column in Figure 2), the tool runs a stress test on all CPU cores, forcing the processor cores to speed up and the system to transition to Turbo Boost mode if it is available [6]. Turbo Boost mode overclocks Intel CPUs for a short time, as long as the system stays within defined limits for current and temperature. The AMD counterpart is known as Turbo Core.
To see the differences in operation between auto-cpufreq and the default configuration, launch auto-cpufreq with the --monitor
option. The idea is to check which governor the system uses when it is running on battery power only and which one it uses when it is on AC power. Test this once with the stress test and once without. Then exit Monitor mode, fire up auto-cpufreq with the --live
option, and repeat the stress test with and without the power supply. The system should now idle in powersave mode during battery operation and only switch to performance mode under load.
If you are suitably impressed by the results in live mode, build auto-cpufreq permanently into the system with a call to sudo auto-cpufreq --install
. This command sets up auto-cpufreq to activate automatically at boot time. If necessary, you an undo this step later with the --remove
option. As a service, auto-cpufreq runs completely in the background; if needed, you can keep a log of the program by typing sudo auto-cpufreq --log
. The Ctrl+C keyboard shortcut terminates the output, but the service remains active.
In Operation
In our lab with a freshly installed Ubuntu 20.10 and a proven Arch Linux, auto-cpufreq proved to be very solid. The Ubuntu system generally always works with the performance governor out of the box. Auto-cpufreq, on the other hand, immediately switches to the powersave governor as soon as the computer is unplugged from the power supply. This directly affects the CPU's clock speed. While it stays at 2.8 GHz in Ubuntu's default configuration even after unplugging, the CPU immediately ramps down if auto-cpufreq is enabled and fluctuates dynamically afterwards this depending on the kind of action the system is seeing.
In Figure 3, (1) shows the powersave governor in battery mode, (2) shows the clock speeds, and (3) shows the details of the CPU read out by i7z
. After enabling the stress test in s-tui
(bottom right in Figure 3), auto-cpufreq immediately switches to the performance governor even in battery mode and also enables turbo mode. Instead of a maximum of 2.8GHz, the computer's CPU then temporarily runs at 3.4GHz. The default configuration in Ubuntu, on the other hand, completely ignored the CPU's turbo mode in our test, and the cores ran constantly at a maximum speed of 2.8GHz.
Arch Linux is known to leave the system configuration completely up to the user. When we tested an Arch system, a quick check of the clock speeds during the stress test showed that the system ignores the CPU's Turbo Boost mode in the current configuration. Regardless of whether it is attached to the power supply unit or supplied with power via the battery, the CPU runs at a maximum of 2.8GHz. The performance governor always remains enabled, unless you configure TLP via /etc/tlp.conf
. Auto-cpufreq immediately integrates harmoniously with the system without any further configuration. The installation in Arch is even slightly easier thanks to the AUR. As on Ubuntu, auto-cpufreq handles the task of setting the governor and enables Intel's Turbo Boost option. Since TLP does not automatically control the governor, the two programs complement each other without getting in each other's way. However, if you plan to use TLP with auto-cpufreq, you should make sure that you have not already enabled the corresponding CPU_SCALING_GOVERNOR_ON_AC
and CPU_SCALING_GOVERNOR_ON_BAT
functions in the TLP configuration in /etc/tlp.conf
.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.
-
Fedora 41 Released with New Features
If you're a Fedora fan or just looking for a Linux distribution to help you migrate from Windows, Fedora 41 might be just the ticket.
-
AlmaLinux OS Kitten 10 Gives Power Users a Sneak Preview
If you're looking to kick the tires of AlmaLinux's upstream version, the developers have a purrfect solution.
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.