Overview of the latest power management techniques in the Linux 2.6 kernel

Foreword

This series of articles will combine the energy-saving technologies that have been added to various hardware (including the latest bus standards and peripherals such as CPU, chipset, PCI Express, etc.) in recent years.

From the perspective of how to add support for these innovative energy-saving technologies from the Linux® 2.6 kernel and the entire software stack (including kernel, middleware and various user-mode uTIlity), the reader is introduced to the Linux operating system in terms of power management in recent years. Great progress and future direction.

As the opening of this series of articles, the first thing to introduce to you is cpufreq, which is a new kernel subsystem for the Linux 2.6 kernel to better support the frequency conversion technology that has appeared in various mainstream CPU processors in recent years. .

The origin of Cpufreq

With the promotion of concepts such as energy efficient compuTIng and performance per watt and the development of the Advanced ConfiguraTIon and Power Interface (ACPI) standard, mainstream CPUs on the market now provide support for frequency scaling technology. For example, Enhanced SpeedStep® technology supported by Intel® processors and PowerNow supported by AMD® processors! ® technology, and similar support is available in processors such as the latest PowerPC®, ARM®, SPARC®, and SuperH®. References list the processors with variable frequency technology supported by the current Linux 2.6 kernel. It should be noted that the frequency conversion technology discussed here is two different concepts from the overclocking that we all know before. Overclocking refers to the behavior of the processor operating at a non-standard frequency by means of increasing the core voltage, which often causes serious consequences such as shortened CPU life and reduced system stability.

The frequency conversion technology means that the CPU hardware itself supports running at different frequencies. During the operation, the system can dynamically switch between these different operating frequencies according to the system load conditions that may change at any time, thereby achieving performance and power consumption. To achieve the purpose of both.

Although multiple processor manufacturers have provided support for frequency conversion technology, there are inevitably subtle and even huge differences in hardware implementation and use methods. This makes each processor manufacturer need to add code to the kernel according to its special hardware implementation and usage methods, so that the inverter technology in its own products can be supported and used in Linux. However, the result of this kernel development model is that the implementation code of each manufacturer is scattered in every corner of the Linux kernel code tree. No code is shared between different implementations, which is to maintain the kernel and add it in the future. Support for new products has brought huge overhead and directly led to the birth of the cpufreq core subsystem. In fact, as mentioned earlier, the purpose of the invention of the frequency conversion technology is to enable the system to dynamically adjust the operating frequency of the CPU according to changes in system load at any time during the operation. This matter can be divided into two parts, one is the question of “what to do” and the other is the question of “how to do it”. “What to do” refers to how to select the appropriate operating frequency of the CPU according to the dynamic changes of the system load, and “how to do it” is to set the CPU at the selected time according to the selected operating frequency, so that it really works here. On a frequency. This is also the problem of mechanism mechanism and policy policy that we often encounter in software design, and well-designed software will ensure that the two are clearly isolated and communicate through the interface defined by the specification.

Design and use of Cpufreq

In order to solve the problems mentioned above, a new kernel subsystem - cpufreq came into being. Cpufreq provides a unified design framework for better support of different CPU frequency conversion technologies in the Linux kernel. The software structure is shown in Figure 1.

Figure 1. Software structure of Cpufreq

As shown in Figure 1, cpufreq is mainly divided into the following three modules:

The Cpufreq module (cpufreq module) encapsulates and abstracts how to control the inverter technology supported by various CPUs at the bottom and how to dynamically select the appropriate operating frequency based on the system load in the upper layer, and defines a clear interface between the two. Thus, the separation of the mechanism and policy mentioned in the previous article is completed in design.

At the bottom of the cpufreq module, each CPU manufacturer only needs to provide CPU-specific drivers (CPU-specific drivers) according to the hardware implementation and usage of its inverter technology. For example, Intel needs to provide CPU drivers that support Enhanced SpeedStep technology. AMD needs to provide support for PowerNow! Technical CPU driver.

On the upper level of the cpufreq module, the governor is the decision maker who selects the appropriate target operating frequency, selects the appropriate operating frequency of the CPU at the appropriate time according to certain criteria, and operates the underlying CPU-related variable frequency driver through the interface defined by the cpufreq module. , the CPU settings are run at the selected operating frequency.

Currently, the latest Linux kernels provide performance, powersave, userspace, conservaTIve and ondemand for users to choose. They use different CPU standards when selecting the appropriate operating frequency of the CPU and are suitable for different application scenarios. Users can only select one of the governors to use at the same time, but they can switch to another governor depending on the application needs during system operation.

The benefit of this design is that the development of the governor and CPU-related variable frequency drivers can be done independently of each other, and the code reuse can be maximized. The kernel developers will not fall into a certain time when writing and testing the new governor. The hardware implementation details of the specific CPU-based inverter technology, and the CPU manufacturer only needs to provide a relatively simpler driver when adding code that supports its specific CPU conversion technology to the Linux kernel, regardless of the driver. How to choose the appropriate operating frequency in a variety of different application scenarios.

The cpufreq subsystem in the kernel provides a user interface to the upper layer application via the sysfs file system. For each CPU in the system, the cpfreq sysfs user interface is located in the /sys/devices/system/cpu/cpuX/cpufreq/ directory. , where X stands for processor id and corresponds to the information in /proc/cpuinfo. Take cpu0 as an example, users generally observe the following files in this directory:

$ ls -F /sys/devices/system/cpu/cpu0/cpufreq/

Affected_cpus

Cpuinfo_cur_freq

Cpuinfo_max_freq

Cpuinfo_min_freq

Ondemand/

Scaling_available_frequencies

Scaling_available_governors

Scaling_cur_freq

Scaling_driver

Scaling_governor

Scaling_max_freq

Scaling_min_freq

Stats/

All of these readable files can be read using the cat command, and all writable files can be written using the echo command. Where cpuinfo_max_freq and cpuinfo_min_freq give the maximum operating frequency and minimum operating frequency supported by the CPU hardware, respectively, cpuinfo_cur_freq reads the current operating frequency of the CPU from the CPU hardware registers. Although the CPU hardware supports a variety of different operating frequencies, in some cases the user can choose to use only one of these subsets. This control is done by scaling_max_freq and scaling_min_freq. When selecting the appropriate operating frequency, Governor will only select within the frequency range determined by scaling_max_freq and scaling_min_freq, which is what scaling_available_frequencies displays. Unlike cpuinfo_cur_freq, scaling_cur_freq returns the current running frequency of the CPU cached by the cpufreq module, without checking the CPU hardware registers. Scaling_available_governors tells the user which managers are currently available to the user, and scaling_driver shows the variable drivers used by the CPU. Statistics on the various operating frequencies of the CPU are given in the Stats directory, such as the runtime of the CPU at various frequencies and the number of conversions between various frequencies. The Ondemand directory is related to the ondemand governor and will be described later.

Through the above introduction, everyone has a general understanding of how to use cpufreq through the user interface provided by sysfs, but for most users, operating these files one by one is laborious and time consuming. Therefore, Dominik et al. developed the cpufrequtils toolkit [2], which provides users with an easier interface to the kernel cpufreq subsystem. Through the output of cpufreq-info, the reader can clearly see the contents of each file in the /sys/devices/system/cpu/cpuX/cpufreq/ directory just described above.

$ cpufreq-info

Cpufrequtils 002: cpufreq-info (C) Dominik Brodowski

2004-2006

Report errors and bugs to , please.

Analyzing CPU 0:

Driver: acpi-cpufreq

CPUs which need to switch frequency at the same time:

0 1

Hardware limits: 1000 MHz - 1.67 GHz

Available frequency steps: 1.67 GHz, 1.33 GHz, 1000

MHz

Available cpufreq governors: userspace, conservative,

Ondemand, powersave, performance

Current policy: frequency should be within 1000 MHz

And 1.67 GHz.

The governor “ondemand” may decide which

Speed ​​to use

Within this range.

Current CPU frequency is 1000 MHz.

Analyzing CPU 1:

Driver: acpi-cpufreq

CPUs which need to switch frequency at the same time:

0 1

Hardware limits: 1000 MHz - 1.67 GHz

Available frequency steps: 1.67 GHz, 1.33 GHz, 1000

MHz

Available cpufreq governors: userspace, conservative,

Ondemand, powersave, performance

Current policy: frequency should be within 1000 MHz

And 1.67 GHz.

The governor “ondemand” may decide which

Speed ​​to use

Within this range.

Current CPU frequency is 1000 MHz.

The origin of the Ondemand governor and its implementation Just now we can see in the output of cpufreq-info that the cpufreq subsystem provides a total of five governors for users to choose from, which are userspace, conservative, ondemand, powersave and performance. In the latest kernel, if the user does not make additional settings, ondemand will be used as the default governor. In order to understand what is causing this situation, we are here to lead the reader to review the development history of the governor in the cpufreq subsystem in the kernel.

As a subsystem, Cpufreq was first included in the Linux kernel with only three governors, namely performance, powersave, and userspace. When the user chooses to use the performance governor, the CPU will work fixed at the highest operating frequency it supports; when the user chooses to use the powersave governor, the CPU will work fixed at the minimum operating frequency it supports. Therefore, both of these governors belong to the static governor, that is, the CPU's operating frequency will not be dynamically adjusted according to the change of the system runtime load when using them. These two kinds of governors correspond to two extreme application scenarios. The performance governor is the pursuit of the highest performance of the system, and the powersave governor is the biggest pursuit of low power consumption. While these two application requirements do exist, most users need a more flexible frequency conversion strategy most of the time. The earliest cpufreq subsystem provided this flexibility to users through the userspace governor. As its name suggests, when using the userspace governor, the system passes the decision-making power of the frequency-conversion policy to the user-mode application and provides a corresponding interface for the user-mode application to adjust the CPU operating frequency. By setting the userspace to the governor used by the cpufreq subsystem by using cpufreq-set in the cpufrequtils toolkit, we can see that there is more in the /sys/devices/system/cpu/cpuX/cpufreq/ directory than before. A file called scaling_setspeed, which is the special user interface provided by the userspace governor. The user can set the CPU to run at this frequency by writing to the file the run frequency supported in any of the scaling_available_frequencies.

# cpufreq-set -g userspace

# cat cpuinfo_cur_freq

1000000

# cat scaling_available_frequencies

1667000 1333000 1000000

# echo 1333000 》scaling_setspeed

# cat cpuinfo_cur_freq

1333000

Just mentioned that when using the userspace governor, the system gives the decision-making power of the frequency conversion policy to the user-mode application. The user mode application is generally a daemon program that collects system information at regular intervals and dynamically adjusts the operating frequency of the CPU using the scaling_setspeed interface provided by the userspace governor according to the load of the system. As a daemon program, powersaved or cpuspeed was used in several major Linux distributions at the time. These two daemon programs generally count the load of the CPU during this sampling period every few seconds, and adjust the operating frequency of the CPU according to the statistical results. This kind of userspace governor plus user-side daemon program's variable frequency method provides users with some flexibility, but the feedback obtained through the extensive use of the open source community has gradually exposed two serious flaws of this method. The first is a performance issue. For example, powersaved performs a sample analysis of the system load every five seconds, we can analyze the user experience in the application scenario given below. Assume that the sample analysis of powersaved has just ended, and because the system load is low during the sampling period just ended, the CPU is set to run at the lowest frequency. At this time, if the user opens a program such as Firefox® that requires a relatively high CPU computing power, powersaved will have to observe the need to increase the CPU operating frequency at the next sampling point - about five seconds later. In other words, the CPU's computing power is not fully utilized within five seconds of Firefox's startup, which will undoubtedly compromise the user experience. The second is the accuracy of the sampling analysis of the system load situation. It is actually unreasonable to hand over the task of monitoring system load and judging the performance requirements of future CPUs to a user-mode program. On the one hand, it is difficult for a user-mode program to collect all the required information completely because Most of this information is stored in the kernel space; on the other hand, if a user-mode program wants to collect such system information, it must necessarily perform data interaction between the user state and the kernel state, and between the frequent user state and the kernel state. Data interaction can have a negative impact on system performance.