CN117076137A - CPU dynamic frequency modulation method under virtualization - Google Patents

Abstract

The CPU dynamic frequency regulation method under virtualization includes the following steps: start the CPU frequency regulation system of the management domain; set the frequency regulation policy of the management domain; implement load redirection on the management domain and redirect the load calculation function of the management domain operating system to the hypervisor , so that the virtual CPU load and the actual physical CPU load can be converted in the hypervisor. When the hypervisor returns to the virtual machine, the load calculation result can be written back to the management domain operating system. The present invention solves the need for CPU dynamic frequency modulation function in virtualization scenarios. This enables embedded devices to accurately perceive the actual load of the physical CPU in virtualization scenarios, and perform dynamic frequency modulation based on the load, so that the device operation takes into account performance, real-time, power consumption, heat dissipation and other requirements.

Description

CPU dynamic frequency regulation method under virtualization

Technical field

The present invention relates to the technical field of virtual machine resource scheduling, and specifically relates to a CPU dynamic frequency modulation method under virtualization.

Background technique

With the continuous development of virtualization technology, it has been widely used in the Internet of Things, embedded industrial automation, vehicle systems, network equipment and other fields. Virtualization brings new possibilities and advantages to embedded systems by efficiently utilizing hardware resources and providing more flexible deployment methods. In these non-data center scenarios, CPU frequency modulation technology is particularly important. CPU throttling allows the CPU frequency to be dynamically adjusted, providing benefits in both performance and energy savings. Frequency modulation technology is mainly used to solve the following key problems for embedded devices:

1. Performance improvement:

Use higher frequencies when needed for better performance: CPU Dynamic Scaling enables the CPU frequency to be increased when necessary. This is particularly helpful for "heavy load" use cases, where the application requires more processing power. By using higher frequencies, tasks can be completed faster, thus improving overall system performance.

Speed up the boot process: Increasing the CPU frequency during the boot process can speed up the boot process, making the system become operational faster. This is especially beneficial in devices that require fast boot times.

2. Energy saving:

Use lower frequencies under light loads to improve power efficiency: One of the main advantages of CPU dynamic scaling is the ability to reduce the CPU frequency when the system load is light. This brings energy savings, which is particularly critical in the embedded field of embedded devices. By reducing the frequency, the device's energy consumption can be reduced, thereby extending battery life.

Prevent overheating and extend CPU life: In some cases, CPU Dynamic Scaling can help prevent the CPU from overheating. By lowering the frequency when the load is lower, the CPU generates less heat, which is especially important in devices with limited cooling capabilities. Preventing overheating not only improves power efficiency, it also helps extend the life of your CPU.

The combination of performance optimization and power efficiency makes CPU dynamic tuning a valuable feature in embedded systems. It coincides with resource-constrained device requirements, where striking the right balance between performance and energy consumption is crucial. The role of CPU dynamic frequency scaling has become more important in providing a better user experience and efficient operation of various applications.

Usually there will be a complete implementation of CPU frequency modulation in the operating system, including frequency modulation algorithms, drivers, etc. Taking the Linux system as an example, it includes:

1. Driver support: The Linux kernel contains a variety of CPUFreq drivers to support different CPU architectures and chipsets. These drivers interact with the specific hardware platform to adjust the CPU frequency.

2. Governor (frequency modulation strategy): Each CPUFreq driver supports multiple frequency modulation strategies, also called Governor. Governor is used to select the appropriate frequency based on system load and demand.

3. CPUFreq scheduler interface: The Linux kernel interacts with each Governor through the CPUFreq scheduler interface. When the CPU frequency needs to be adjusted, the scheduler selects the appropriate Governor to handle the frequency adjustment request.

4. User space interface: Linux provides the sysfs interface, allowing users to set and query CPUFreq parameters in user space. Through sysfs, users can choose a different governor or set the frequency manually.

But after the device introduces virtualization technology, CPU frequency regulation becomes very different. As shown in Figure 1, frequency modulation is based on CPU load calculation, which means that if the CPU load is large, a higher frequency is needed to improve the CPU's computing power and real-time performance. When the CPU load is small, the CPU frequency needs to be reduced to reduce energy consumption. After virtualization is turned on (Hypervisor uses Xen as an example), multiple clients will be virtualized on the system. The first one to start the Linux system is called dom0 (it can be called the management domain in Chinese), and other clients can It is called domu (it can be called customer domain in Chinese). Different clients are located in different domains and are isolated from each other. Among them, dom0 is called the privileged domain. It has the hardware resource permissions of the entire system, including the CPU frequency modulation driver and corresponding hardware permissions. Other domu must apply to dom0 to access the hardware. However, the dom0 operating system can only calculate the load of its own virtual machine and cannot sense the load of other virtual machines. If dom0 is allowed to directly perform dynamic CPU frequency modulation, it will not be able to make correct decisions and affect the operation of other clients.

Another idea is to implement the CPU dynamic frequency modulation function in Xen. Because Xen understands the operation of each guest and physical CPU, it makes more correct decisions about CPU frequency scaling. But the main problem is that typical TYPE-I virtual machines like Xen are basically lightweight. It is a thin layer between the hardware and the operating system. And if Xen wants to complete the entire CPU frequency modulation function, it needs to integrate a large number of CPU frequency modulation drivers. Because the CPU frequency modulation drivers of different chips vary widely, and in order to adapt to different hardware, the amount of code is quite huge, and considering the subsequent maintenance, there is also a lot of workload. Porting a large amount of driver code to Xen is obviously not the original intention of the TYPE-I virtual machine.

Contents of the invention

In order to solve the shortcomings of the existing technology, the present invention provides a CPU dynamic frequency modulation method under virtualization, which includes the following steps:

Step S1: Start the CPU frequency modulation system of the management domain;

Step S2: Set the frequency modulation policy of the management domain;

Step S3: Implement load redirection on the management domain, redirect the load calculation function of the management domain operating system to the Hypervisor, and let Hypersivor perform CPU load calculation. During the load calculation process, Hypersivor can compare the load of the virtual CPU with the actual physical CPU. When the hypervisor returns to the management domain, it can write the load calculation results back to the management domain operating system, so that the management domain operating system can complete the frequency regulation work based on the frequency regulation policy;

Among them, the management domain is the first virtual machine started in the virtualization system and is responsible for running and monitoring other virtual machines that are subsequently started. The management domain runs on the hypervisor, and the management domain operating system runs on the first started virtual machine. operating system on.

Among them, by removing the disable_cpufreq() function in arch/arm/xen/enlighten.c of the management domain kernel, the management domain operating system can load the CPU frequency modulation module normally.

In step S2, the frequency modulation strategy of the management domain is Performance, Powersave or Ondemand. The frequency modulation principles of the three frequency modulation strategies are as follows:

Performance: Maintain the highest frequency for optimal performance;

Powersave: Use the lowest frequency to reduce energy consumption;

Ondemand: Dynamically adjust frequency based on load.

In step S2, the frequency modulation policy of the management domain is Ondemand.

Among them, in step S3, load calculation redirection is implemented on the management domain through the following steps:

Step S31: Use the kallsyms_lookup_name function provided by the kernel to find the memory address of dbs_update;

Step S32: Perform instruction replacement on the memory address found in step S31, and replace the dbs_update function with the Xen jump function privcmd_ioctl implemented by the operating system kernel specifically for the management domain; because Xen controls the real CPU hardware resources, thus in the hypervisor Realize the load calculation of the actual physical CPU, and transfer the load calculation result of the load calculation module in the Hypervisor to the management domain operating system when the Hypervisor returns; among them, Xen is an implementation mode of the Hypervisor;

Step S33: The management domain calls the frequency modulation driver according to the calculation result to implement dynamic frequency modulation of the CPU.

Among them, the load calculation module in Xen is implemented as follows:

Step S321: Maintain a VCPU queue for each physical CPU in Xen, and the VCPUs are arranged in the queue in order of decreasing priority;

Step S322: Each physical CPU sets an IDLE VCPU as the lowest priority VCPU task and schedules it when the CPU is idle. The IDLE VCPU is responsible for tracking the status of the VCPU and the corresponding running time, thereby obtaining the running time of the IDLE VCPU;

Step S323: Calculate the load of all physical CPUs cyclically according to the following formula, select the maximum load and pass it to the management domain as the decision parameter of the Ondemand policy:

;

Among them, the sampling period is the time period involved in load calculation in the physical CPU run queue.

Among them, the running time of IDLE VCPU is the idle time of the entire physical CPU.

The CPU dynamic frequency modulation method under virtualization of the present invention solves the need for CPU dynamic frequency modulation function in virtualization scenarios. This enables embedded devices to accurately perceive the actual load of the physical CPU in virtualization scenarios, and perform dynamic frequency modulation based on the load, so that the device operation takes into account performance, real-time, power consumption, heat dissipation and other requirements.

Description of the drawings

Figure 1: Comparison diagram of CPU frequency modulation logic between existing technologies without virtualization and after virtualization.

Figure 2: Principle diagram of load redirection of the present invention.

Figure 3: Principle diagram of Xen's CPU load calculation of the present invention.

Detailed ways

In order to have a further understanding of the technical solutions and beneficial effects of the present invention, the technical solutions of the present invention and the beneficial effects thereof will be described in detail below with reference to the accompanying drawings.

Theoretically speaking, the hypervisor has higher management rights over the hardware, and the hardware resources controlled by the client are virtualized or pass-through by the hypervisor. From this point of view, the Hypervisor is more suitable to complete the task of CPU frequency regulation. But it will undoubtedly be a huge undertaking. First, the frequency modulation algorithm needs to be implemented independently, and secondly, the CPU frequency modulation driver needs to be heavily integrated into the hypervisor. The idea of the present invention is to use the existing functions of the client operating system as much as possible. Taking the Linux system as an example, a relatively complete CPU frequency modulation algorithm has been formed, and based on the strong ecological characteristics of the Linux system, it can adapt to most CPU frequency modulation drivers.

If you want to use the operating system's own CPU frequency regulation system, the most important thing is to solve the problem that the Host client cannot sense other clients and the actual CPU load. The idea of the present invention is to redirect the load calculation function of the operating system to the hypervisor through the method of function piling. Convert the load of the virtual CPU and the load of the actual physical CPU in the hypervisor. When the hypervisor returns to the virtual machine, the load calculation results are written back to the operating system. In this way, the guest operating system is transparent to CPU frequency regulation and does not need to make any modifications. At the same time, only relatively few changes need to be made in the hypervisor to realize the dynamic CPU frequency regulation function of the entire system.

A preferred embodiment of the present invention is based on the ARMv8 architecture, the virtualization software uses the Xen 4.17.0 version, and the HOST client is the Linux 5.0 kernel. The specific steps to implement the above concept are as follows:

1. Enable the CPU frequency modulation system of dom0.

In the Xen architecture, in order to prevent the Linux client from performing incorrect CPU frequency modulation operations. Generally, the Linux frequency modulation module is disabled. Therefore, the first step of the present invention is to enable the frequency modulation module of dom0. Remove the disable_cpufreq() function in arch/arm/xen/enlighten.c of the dom0 kernel, so that Linux will load the cpu frequency modulation module normally, thereby enabling the CPU dynamic frequency modulation function of dom0.

In a system without virtualization, the system consists of hardware and operating system software. After the introduction of virtualization, a layer of software is inserted between the hardware and the operating system, which we call a hypervisor (Chinese: virtual machine monitor). In this way, multiple virtual machines can be run on the hypervisor. The most special of these virtual machines is the first started virtual machine, which we can call dom0, and its Chinese name is called the management domain. The subsequent started virtual machines are ordinary virtual machines, called domu. Dom0 is a special virtual machine running the Xen virtual machine monitor (Hypervisor) and is responsible for managing and monitoring other virtual machines (DomU). Dom0 typically has direct access to physical hardware resources, including control of device drivers, and is responsible for the configuration and maintenance of the entire virtualized environment. DomU represents a normal virtual machine, usually running different operating systems and applications. DomUs are called "unprivileged domains" or "guest domains" because they do not have direct access to physical hardware resources, but rely on Dom0 to provide these resources. Multiple DomUs can be created based on the number of virtual machines required. The management domain is a special virtual machine that can run Linux or other operating systems. In the present invention, the management domain operating system is the Linux system running in the management domain.

2. Set the frequency modulation policy of dom0 to Ondemand.

Currently, there are three main frequency modulation strategies in Xen:

Performance: Maintain the highest frequency for best performance.

Powersave: Use the lowest frequency to reduce energy consumption.

Ondemand: Dynamically adjust frequency based on load.

However, since Xen does not have FM drivers for all chips, its application is relatively limited. It only implements frequency modulation related algorithms and strategies, and real hardware driver support requires users to implement it.

In the present invention, the method of "dom0 proxy, load calculation redirection" is used to realize the frequency modulation function of xen. Among them, Performance and Powersave are relatively simple and do not involve complex load calculations. They only need to set the maximum frequency and minimum frequency according to the user's needs. For most systems, the Ondemand throttling policy provides the best balance between thermal dissipation, power consumption, performance, and manageability. When the system is busy during certain times of the day, the Ondemand frequency regulation policy automatically switches between maximum and minimum frequencies based on load without further intervention. Therefore, this invention mainly describes the implementation method of the Ondemand policy. In the Linux system of dom0, it can be set through the cpufrequtils tool. The specific command is: cpufreq-set -r -g ondemand. In addition, you can also modify the current CPU frequency regulation strategy through the /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor system interface.

3. dom0 proxy, implementation of load calculation redirection

Ondemand will detect the CPU load periodically (usually every once in a while). Load can be measured through various metrics such as CPU utilization, ready queue length, etc. The regulator dynamically adjusts frequency within the supported frequency range based on load conditions. This means it can adapt to different workloads in real time based on system needs. The present invention mainly modifies the load calculation result of Ondemand through function piling, so that the load calculation can reflect the load situation of the entire physical CPU, not just the load of the dom0 system itself. The specific implementation method is as follows:

(1) Key instruction detection

As shown in Figure 2, in the code segment of the dom0 Linux kernel, Ondemand calls the od_dbs_update function through the selected governor to perform regular load detection and frequency adjustment. Among them, od_dbs_update calls the od_update function, and calls the real load calculation function dbs_update in od_update (dbs_update is the function responsible for load calculation in the drivers/cpufreq/cpufreq_governor.c file under the Linux kernel), and then calls the frequency modulation driver based on the load calculation result, and finally changes CPU hardware frequency. So the function we need to pile here is dbs_update. Use the kallsyms_lookup_name function provided by the kernel to find the memory address of dbs_update. This function uses the kallsyms function in the kernel. The kernel stores the function symbols and addresses used in the system in the proc file system, and then uses the kallsyms_lookup_name function to find the corresponding relationship between the kernel symbols (that is, the dbs_update function symbols) and the addresses.

In Figure 2, bl and ret are assembly instructions of arm64. BL is a branch instruction (Branch with Link), usually used for function calls. The function of the BL instruction is to jump to the specified function and save the return address (the address of the next instruction) in the link register (LR) so that after the function is executed, it can be returned to the place where it was called. ret is a return instruction that jumps to the address stored in the link register (LR) to implement function return.

(2) Load calculation redirection

Perform instruction substitution at this address and replace the function with privcmd_ioctl. privcmd_ioctl is a xen jump function specially implemented by the Linux kernel for dom0. Its essence is the HVC instruction of ARMv8. This function can be used to fall into the Xen code in EL2 mode. Since real CPU hardware resources are mastered in Xen, we can implement actual physical CPU load calculation here. The load calculation module in Xen passes the calculation results to dom0 when the virtualization layer returns (returning to the previous mode through the eret instruction). dom0 calls the frequency modulation driver based on the calculation results to implement dynamic frequency modulation of the CPU. Ondemand will periodically adjust the CPU frequency based on the sampling frequency, and each frequency adjustment will be triggered into Xen. Although the frequency modulation system of dom0 is borrowed, the actual decision-making parameters (load) are provided by Xen, which ensures that dom0 can objectively complete the frequency modulation work.

4. Implementation of load calculation module in Hypervisor

CPU load refers to the size of the CPU workload, usually expressed as a percentage. In a system without virtualization, the CPU load is the result of algorithm calculation of all processes under the CPU, such as IO load, memory load, network load, etc. However, with virtualization, the load calculation of the virtual machine is virtual and does not represent the load on the actual physical CPU. Therefore, the hypervisor is used here to complete the workload statistics of the physical CPU. In the hypervisor, the VCPU queue is hung under the physical CPU. It can be understood that each VCPU is a task in a non-virtualization system, as shown in Figure 3. At this time, VCPU can actually be regarded as the load object of the physical CPU.

Xen maintains a VCPU queue for each physical CPU, and the VCPUs are arranged in the queue in descending order of priority. At the same time, each physical CPU also has an IDLE VCPU (as shown in Figure 3), which is the lowest priority VCPU task and is scheduled when the CPU is idle. The IDLE VCPU is responsible for tracking the status of the VCPU and the corresponding running time, thus obtaining the IDLE VCPU's operation hours. The running time of IDLE VCPU is the idle time of the entire physical CPU, that is, the state the CPU enters when there is no task running, so we can know the idle state time of the physical CPU through the VCPU information.

The load calculation reflects the average number of tasks in the run queue over a period of time (that is, a percentage obtained by the previous formula). This average is calculated by sampling the run queue over a period of time, and the length of this sampling period can be 1 minute, 5 minutes, and 15 minutes. These three values represent the average load conditions in different time ranges. In actual load calculation algorithms, this value usually changes dynamically.

Xen needs to cyclically calculate the load of all physical CPUs, and select the maximum load (that is, the load corresponding to the physical CPU with the least idle CPU running time) to be passed to dom0 as the decision parameter of the Ondemand policy.

Xen periodically checks the load on each physical CPU and the needs of the virtual machine. This can be a dynamic process, and both the virtual machine's needs and the load on the physical CPU can change over time. If Xen finds that one physical CPU is under high load and other physical CPUs are under low load, it can consider live migration. This means that Xen can migrate a virtual machine's vCPU from one physical CPU to another physical CPU to achieve load balancing.

Therefore, through the method provided by the present invention, the dom0 Linux system can complete the CPU frequency modulation function in a virtualization scenario without any modification, because in today's era of full virtualization, modification of the guest operating system is not allowed in many cases. self.

At the same time, the present invention makes full use of the ecology of the dom0 Linux system, so that it can be fully adapted to the chip hardware that supports the Linux system, without the need to implement separate drivers for different hardware, and saves a lot of driver transplantation and hardware adaptation. Work.

Although the present invention has been described using the above preferred embodiments, they are not intended to limit the scope of the present invention. Any person skilled in the art can make various changes relative to the above embodiments without departing from the spirit and scope of the present invention. and modifications still fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims (7)

1. The CPU dynamic frequency modulation method under virtualization is characterized by comprising the following steps:

step S1: starting a CPU frequency modulation system of a management domain;

step S2: setting a frequency modulation strategy of a management domain;

step S3: the load redirection is realized on the management domain, the load calculation function of the management domain operating system is redirected to the Hypervisor, the Hypervisor carries out CPU load calculation, the Hypervisor can convert the load of the virtual CPU and the load of the actual physical CPU in the load calculation process, and when the Hypervisor returns to the management domain, the load calculation result can be written back to the management domain operating system, so that the management domain operating system completes the frequency modulation work based on the frequency modulation strategy;

the management domain is a first started virtual machine in the virtualized system and is responsible for running and monitoring other virtual machines started later, the management domain runs on the Hypervisor, and the management domain operating system is an operating system running on the first started virtual machine.

2. The method according to claim 1, wherein in step S1, the management domain operating system is enabled to load the CPU frequency modulation module normally by removing the disable_cpu freq () function from the arch/arm/xen/enlight.c of the management domain kernel.

3. The method for dynamic frequency modulation of CPU under virtualization according to claim 1, wherein in step S2, the frequency modulation policy of the management domain is Performance, powersave or Ondemand, and the frequency modulation principles of the three frequency modulation policies are as follows:

performance: maintaining the highest frequency for optimal performance;

powersave: the lowest frequency is used to reduce energy consumption;

ondemand: the frequency is dynamically adjusted according to the load.

4. The method for dynamic frequency modulation of CPU under virtualization according to claim 3, wherein in step S2, the frequency modulation policy of the management domain is Ondemand.

5. The method for dynamically tuning a CPU under virtualization according to claim 4, wherein in step S3, load calculation redirection is implemented on a management domain by:

step S31: finding a memory address of dbs_update by using a kallsyms_lookup_name function provided by a kernel;

step S32: performing instruction replacement on the memory address found in the step S31, and replacing the dbs_update function with a Xen jump function privcmd_ioctl which is specially realized by the kernel of the operating system for the management domain; because the real CPU hardware resource is mastered in Xen, the load calculation of the actual physical CPU is realized in the Hypervisor, and the load calculation result of the load calculation module in the Hypervisor is transmitted to the management domain operating system when the Hypervisor returns; wherein Xen is one mode of implementation of Hypervisor;

step S33: and the management domain calls the frequency modulation drive according to the calculation result to realize the dynamic frequency modulation of the CPU.

6. The method for dynamically tuning CPU frequency under virtualization according to claim 5, wherein the load calculation module in Xen is implemented as follows:

step S321: maintaining a queue of VCPUs for each physical CPU in Xen, wherein the VCPUs are sequentially arranged in the queue according to the descending order of priority;

step S322: each physical CPU is provided with an IDLE VCPU which is used as a VCPU task with the lowest priority and is scheduled when the CPU is IDLE, and the IDLE VCPU is responsible for tracking the state and the corresponding running time of the VCPU, so that the running time of the IDLE VCPU is obtained;

step S323: and circularly calculating the loads of all physical CPUs according to the following formula, and selecting the maximum load from the loads to be transmitted to a management domain as a decision parameter of an Ondemand strategy:

；

the sampling period is a time period involved in load calculation of the physical CPU running queue.

7. The method for dynamically tuning a CPU under virtualization according to claim 6, wherein the IDLE VCPU has a run time of the entire physical CPU.