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.

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.

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

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

Figure 1: In Monitor mode, auto-cpufreq outputs information about the clock speed and the governor but does not change anything on the system.

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.

Figure 2: Enabled as a service, auto-cpufreq handles the task of setting the governor. As soon as the system load increases, the program switches to performance mode.

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.

Figure 3: In powersave mode, the system shuts down clocks far faster than Ubuntu does in the default configuration.

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.