Hypervisor-based dynamic frequency modulation method and electronic device

Abstract

The present disclosure relates to a method and electronic device for dynamic frequency modulation based on Hypervisor, wherein multiple client operating systems Guest OS run on a virtual machine monitor Hypervisor, and the method comprises: counting the current load of the core where each Guest OS is located; judging whether the current load matches the current operating frequency of the core; if not, initiating a vote to each Guest OS and receiving the current number of votes returned by each Guest OS; wherein the current number of votes is used to indicate the number of target services on each Guest OS; and performing frequency modulation according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located. The above scheme is used to solve the technical problem that the multi-system environment based on Hypervisor in the prior art requires each Guest OS to perform corresponding dynamic frequency modulation by itself, which is relatively complex to implement. The present scheme can reasonably and intelligently perform frequency modulation to achieve both power consumption and performance, thereby more reasonably performing frequency modulation on the entire CPU.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a hypervisor-based dynamic frequency modulation method and electronic equipment. Background Art

[0002] Hypervisor is called Virtual Machine Monitor (VMM), which is an operating system that runs other operating systems. Hypervisor runs as an intermediate operating system between physical hardware and operating systems, allowing multiple operating systems and applications to share a set of basic physical hardware. The operating system running on the Hypervisor is called the guest operating system (Guest OS).

[0003] Hypervisor has been used in the server field before, but with the development of embedded systems, it is considered to be the next frontier of embedded systems to solve the decision-making difficulties of the limited resources of embedded systems in the increasingly complex application scenarios. Hypervisor provides the flexibility to carry heterogeneous operating systems on the same multi-core processor, and it implements good reliability and fault control mechanisms to ensure the safe separation between mission-critical, hard real-time applications and general-purpose, untrusted user applications. For example, the current smart cockpit of a car uses Hypervisor technology to realize the full LCD instrument display and the central control entertainment system display on a single board at the same time, where the full LCD instrument runs on the Guest OS using Linux or QNX (Quick UNIX), and the central control entertainment system runs on the Guest OS using Android.

[0004] Currently, common Guest OSs provide dynamic frequency modulation methods in the operating system itself. However, since Guest OS currently runs on top of Hypervisor, it cannot obtain the actual load. Hypervisor is required to perform physical load calculation to obtain the actual physical load situation. In a multi-system environment based on Hypervisor, each Guest OS needs to perform corresponding dynamic frequency modulation itself, which is more complicated to implement. Summary of the invention

[0005] The purpose of the present disclosure is to provide a hypervisor-based dynamic frequency modulation method and electronic device, which are used to solve the technical problem that in the prior art, a multi-system environment based on a hypervisor requires each Guest OS to perform corresponding dynamic frequency modulation itself, which is relatively complex to implement.

[0006] In order to achieve the above object, the first aspect of the present disclosure provides a Hypervisor-based dynamic frequency modulation method, wherein multiple client operating systems Guest OS run on a virtual machine monitor Hypervisor, and the method comprises:

[0007] Count the current load of each core where the Guest OS is located;

[0008] Determining whether the current load matches the current operating frequency of the core;

[0009] If there is no match, a vote is initiated to each Guest OS, and the current number of votes returned by each Guest OS is received; wherein the current number of votes is used to indicate the number of target services on each Guest OS;

[0010] Frequency adjustment is performed according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located.

[0011] Optionally, frequency adjustment is performed according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located, including:

[0012] If multiple Guest OSs are running on different cores in the same cluster, the maximum value of the current votes returned by the multiple Guest OSs is taken;

[0013] The cluster is frequency-adjusted according to the maximum value of the current number of votes.

[0014] Optionally, frequency adjustment is performed according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located, including:

[0015] Obtaining a preset load table; the load table includes operating frequency ranges corresponding to different loads;

[0016] According to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located, the load table is queried to obtain the frequency range corresponding to the current load, and the frequency is modulated within the frequency range corresponding to the current load.

[0017] Optionally, determining whether the current load matches the current operating frequency of the core includes:

[0018] Querying the load table to determine whether the current operating frequency of the core is within the operating frequency range corresponding to the current load;

[0019] If so, the current load matches the current operating frequency; if not, they do not match.

[0020] Optionally, the target service on the Guest OS includes a high-priority process running on the Guest OS or an external wake-up source received on the Guest OS; wherein the external wake-up source includes one or more of a real-time clock RTC, an external interrupt or a modem service.

[0021] Optionally, the method further includes:

[0022] The current load of each core where the Guest OS is located is counted in real time or periodically.

[0023] A second aspect of the present disclosure provides a hypervisor-based dynamic frequency modulation device, wherein a plurality of client operating systems Guest OS run on the hypervisor, and the device comprises:

[0024] A statistics module, used to count the current load of each core where the Guest OS is located;

[0025] A determination module, used to determine whether the current load matches the current operating frequency of the core;

[0026] A voting module, used for initiating voting to each Guest OS when there is no match, and receiving the current number of votes returned by each Guest OS; wherein the current number of votes is used to indicate the number of target services on each Guest OS;

[0027] The frequency modulation module is used to perform frequency modulation according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located.

[0028] A third aspect of the present disclosure provides a non-temporary computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0029] A fourth aspect of the present disclosure provides an electronic device, including:

[0030] a memory having a computer program stored thereon;

[0031] A processor is used to execute the computer program in the memory to implement the steps of the method described in the first aspect.

[0032] Through the above technical solution, when multiple Guest OSes are running on a Hypervisor, the operating frequency of the core where the Guest OS is located is determined by calculating the current load of the core and the voting mechanism, so as to obtain and evaluate the number of target services in the Guest OS, thereby effectively performing dynamic frequency modulation on multiple Guest OSes running on the Hypervisor. This solves the technical problem in the prior art that, in a multi-system environment based on a Hypervisor, each Guest OS needs to perform corresponding dynamic frequency modulation itself, which is relatively complex to implement. In the process of dynamic frequency modulation, this solution can reasonably and intelligently perform frequency modulation to achieve both power consumption and performance, thereby more reasonably modulating the frequency of the entire CPU.

[0033] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present disclosure but do not constitute a limitation of the present disclosure. In the accompanying drawings:

[0035] Figure 1 is a flow chart of a hypervisor-based dynamic frequency modulation method according to an exemplary embodiment;

[0036] Figure 2 is another flow chart of a method for dynamic frequency modulation based on a Hypervisor according to an exemplary embodiment;

[0037] Figure 3 is a block diagram of a dynamic frequency modulation device according to an exemplary embodiment;

[0038] Figure 4 It is a block diagram of an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION

[0039] The specific implementation of the present disclosure is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described herein is only used to illustrate and explain the present disclosure, and is not used to limit the present disclosure.

[0040] In the disclosed embodiment, the Hypervisor creates several Guest OSes according to the user configuration, and the multiple Guest OSes run on the Hypervisor. Since each CPU may be divided into multiple clusters, and each cluster represents a different core, such as a small core like A55 or a large core like A72, each cluster may run one or more Guest OSes in multiple scenarios.

[0041] In the disclosed embodiment, the operating frequency of the core where the Guest OS is located is determined by calculating the current load of the core and a voting mechanism, thereby acquiring and evaluating the number of target services in the Guest OS, thereby effectively dynamically adjusting the frequency of multiple Guest OSes running on the Hypervisor.

[0042] In order to achieve the above purpose, Figure 1 As shown, the technical solution adopted by the present disclosure to solve the technical problem includes the following steps.

[0043] Step 101, counting the current load of each core where the Guest OS is located.

[0044] The current load of the core refers to the utilization rate of the core in the CPU. Since the Guest OS currently runs on the Hypervisor, it cannot obtain the real load and needs the Hypervisor to perform physical load calculation. Therefore, during the dynamic frequency modulation process, the current load of each core where the Guest OS is located is counted in real time or periodically through the Hypervisor.

[0045] Step 102, determining whether the current load matches the current operating frequency of the core.

[0046] In the embodiment of the present disclosure, the corresponding relationship between the load and the operating frequency can be preset, so as to determine whether the current load matches the current operating frequency according to the corresponding relationship. If they match, return to step 101 to continue to count the core load. If they do not match, execute step 103.

[0047] Step 103: If there is no match, a vote is initiated to each of the Guest OSes, and a current number of votes returned by each of the Guest OSes is received; wherein the current number of votes is used to indicate the number of target services on each of the Guest OSes.

[0048] The Hypervisor will ask each Guest OS whether it needs to be frequency-adjusted. Correspondingly, each Guest OS will receive a voting request, start to detect whether it is running the target business and the number of running businesses, and send the current number of votes to the Hypervisor.

[0049] Step 104: frequency adjustment is performed according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located.

[0050] The Hypervisor dynamically adjusts the frequency based on the current load and the current number of votes returned by each Guest OS to ensure that the entire system is in the most appropriate frequency state, thereby reducing power consumption and ensuring performance.

[0051] In the disclosed embodiment, after the Hypervisor starts the Guest OS, it enters the Guest OS to run and execute the corresponding business. First, the Hypervisor will calculate the load of the large core and small core on the physical machine regularly or in real time, and then query the load table according to the load situation to determine whether the load matches the frequency and whether a vote needs to be initiated. The performance loss in this process is extremely small, and the corresponding power consumption loss is negligible.

[0052] In a possible implementation, step 102 may be implemented in the following manner, namely, determining whether the current load matches the current operating frequency of the core.

[0053] When determining whether the physical load of the core where the Guest OS is located matches the current operating frequency, a preset load table is obtained; the load table includes operating frequency ranges corresponding to different loads; then, by querying the load table, it is determined whether the current operating frequency of the core is within the operating frequency range corresponding to the current load; if so, the current load matches the current operating frequency; if not, they do not match.

[0054] If the operating frequency of the core where the Guest OS is located is lower than the frequency range corresponding to the current load, it indicates that an up-frequency operation is required to ensure performance. If the operating frequency of the core where the Guest OS is located is higher than the frequency range corresponding to the current load, it indicates that a down-frequency operation is required to reduce power consumption.

[0055] In the disclosed embodiment, when performing the frequency modulation operation, it can also be performed by querying the load table. The Hypervisor queries the load table according to the current load of the core where each Guest OS is located, obtains the frequency range corresponding to the current load, and then, according to the current number of votes returned by each Guest OS, performs frequency modulation within the frequency range corresponding to the current load. For example, the final operating frequency can be positively correlated with the current number of votes, the higher the number of votes, the higher the final operating frequency, and vice versa.

[0056] In the disclosed embodiment, the target service on the Guest OS includes a high-priority process running on the Guest OS; the target service may also be an external wake-up source received on the Guest OS; wherein the external wake-up source includes one or more of a real-time clock RTC (Real Time Clock), an external interrupt or a modem service.

[0057] Taking frequency reduction as an example, the Hypervisor will ask each current Guest OS whether it needs to perform frequency adjustment. Each Guest OS will receive a voting request, and then each Guest OS will start to detect whether it is running high-priority services and the number of services it is running, and whether it can perform frequency reduction. This stage is to detect the service table, and then self-test whether it can release resources to perform frequency reduction. The current Guest OS has the conditions for frequency adjustment, and at this time it will send a reply, that is, the current number of votes, to notify the Hypervisor to perform frequency adjustment. The Hypervisor will make a decision based on the number of votes for each Guest OS. The frequency adjustment result is determined by the Hypervisor, and the frequency adjustment operation will be performed based on the number of votes, the current load and frequency. The action of initiating voting is performed by the Hypervisor. The Hypervisor will initiate a vote at a certain interval to ensure that the entire system is in the most appropriate frequency state to reduce power consumption.

[0058] When the Hypervisor detects that the physical load and frequency do not match and that a frequency increase is required, the Hypervisor initiates a vote and notifies each Guest OS. At this time, the Guest OS will detect all services, how many high-priority services there are, and whether frequency adjustment can be performed. Each Guest OS has a corresponding process to receive voting requests, and then the process will perform service statistics; a Guest OS in the Hypervisor is running on the core at a relatively low frequency, and suddenly receives an external wake-up source, which can be RTC, external interrupts, or modem services. In each cluster, multiple Guest OSes will run in multiple scenarios, and the frequency of the currently running core needs to be adjusted according to the actual situation. At this time, the Hypervisor will determine the range to which the core where the Guest OS is located needs to be increased based on the number of votes returned by the Guest OS.

[0059] After the Hypervisor completes the frequency increase operation, it still counts the load occupancy rate (i.e., load) in real time to perform necessary voting and determine in real time whether dynamic frequency adjustment is required.

[0060] In the embodiment of the present disclosure, when performing a frequency modulation operation, the frequency of each core may be modulated individually, or the frequency of a cluster including multiple cores may be modulated as a whole.

[0061] When frequency adjustment is performed for each core individually, the frequency adjustment is performed based on the current load of the core and the current number of votes returned by the Guest OS running on the core.

[0062] When the cluster is frequency-adjusted as a whole, if multiple Guest OSes are running on different cores in the same cluster, the votes of each core need to be coordinated, and the maximum value of the current votes returned by the multiple Guest OSes is taken; then, the cluster is frequency-adjusted according to the maximum value of the current votes. When the cluster is frequency-adjusted as a whole, each core in the cluster needs to be frequency-adjusted.

[0063] In the disclosed embodiment, the Hypervisor may send a voting request via virtio; similarly, the Guest OS sends the current number of votes to the Hypervisor via virtio, where virtio is an abstract layer located above the device in the paravirtualized hypervisor.

[0064] Next, the Hypervisor-based dynamic frequency modulation method in the embodiment of the present disclosure is described by using a specific example. Figure 2 As shown, the following steps are included.

[0065] Step 201: Hypervisor starts the Guest OS.

[0066] Step 202: The Hypervisor counts the current load of each core where the Guest OS is located.

[0067] In step 203, the Hypervisor queries the load table to determine whether the current load matches the current operating frequency of the core. If so, the monitoring continues; if not, step 204 is executed.

[0068] Step 204: The Hypervisor initiates voting to the Guest OS. Assuming that the Guest OS includes Guest OS A and Guest OS B, the Hypervisor initiates voting to Guest OS A and Guest OS B respectively.

[0069] Step 205: The Hypervisor receives the current number of votes returned by each Guest OS. Continuing with the example in which the Guest OS includes Guest OS A and Guest OS B, the Hypervisor will receive the current number of votes returned by Guest OS A and Guest OS B.

[0070] Step 206: The Hypervisor queries the load table and adjusts the frequency according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located.

[0071] As described in the above embodiment, if the Hypervisor performs frequency modulation for each core separately, the Hypervisor can perform frequency modulation on the cores where Guest OS A and Guest OS B are located separately; if Guest OS A and Guest OS B are located on different cores in a cluster, and the Hypervisor performs frequency modulation on the entire cluster, the Hypervisor takes the maximum value of the current votes returned by Guest OS A and Guest OS B, and performs frequency modulation on the entire cluster in combination with the load of the core in the cluster.

[0072] Based on the same inventive concept, the embodiment of the present disclosure also provides a hypervisor-based dynamic frequency modulation device 300, wherein multiple client operating systems Guest OS run on the hypervisor, such as Figure 3 As shown, the device includes: a statistical module 301, used to count the current load of the core where each Guest OS is located; a judgment module 302, used to judge whether the current load matches the current operating frequency of the core; a voting module 303, used to initiate voting to each Guest OS when there is a mismatch, and receive the current number of votes returned by each Guest OS; wherein the current number of votes is used to indicate the number of target services on each Guest OS; a frequency modulation module 304, used to perform frequency modulation according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located.

[0073] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0074] Figure 4 FIG. 4 is a block diagram of an electronic device 400 according to an exemplary embodiment. Figure 4 As shown, the electronic device 400 may include: a processor 401 and a memory 402. The electronic device 400 may also include one or more of a multimedia component 403, an input / output (I / O) interface 404, and a communication component 405.

[0075] The processor 401 is used to control the overall operation of the electronic device 400 to complete all or part of the steps in the above-mentioned hypervisor-based dynamic frequency modulation method. The memory 402 is used to store various types of data to support the operation of the electronic device 400, and these data may include, for example, instructions for any application or method used to operate on the electronic device 400, and application-related data, such as contact data, sent and received messages, pictures, audio, video, etc. The memory 402 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (Static Random Access Memory, referred to as SRAM), electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, referred to as EEPROM), erasable programmable read-only memory (Erasable Programmable Read-Only Memory, referred to as EPROM), programmable read-only memory (Programmable Read-Only Memory, referred to as PROM), read-only memory (Read-Only Memory, referred to as ROM), magnetic memory, flash memory, magnetic disk or optical disk. The multimedia component 403 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone, which is used to receive external audio signals. The received audio signal may be further stored in the memory 402 or sent through the communication component 405. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 404 provides an interface between the processor 401 and other interface modules, and the above-mentioned other interface modules may be keyboards, mice, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 405 is used for wired or wireless communication between the electronic device 400 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, 4G, NB-IOT, eMTC, or other 5G, etc., or a combination of one or more of them, is not limited here. Therefore, the corresponding communication component 405 may include: Wi-Fi module, Bluetooth module, NFC module, etc.

[0076] In an exemplary embodiment, the electronic device 400 can be implemented by one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), controllers, microcontrollers, microprocessors or other electronic components to execute the above-mentioned hypervisor-based dynamic frequency modulation method.

[0077] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned hypervisor-based dynamic frequency modulation method are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 402 including program instructions, and the above-mentioned program instructions can be executed by the processor 401 of the electronic device 400 to complete the above-mentioned hypervisor-based dynamic frequency modulation method.

[0078] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program that can be executed by a programmable device. The computer program has a code portion for executing the above-mentioned hypervisor-based dynamic frequency adjustment method when executed by the programmable device.

[0079] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings; however, the present disclosure is not limited to the specific details in the above embodiments. Within the technical concept of the present disclosure, a variety of simple modifications can be made to the technical solution of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0080] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0081] In addition, various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

Claims

1. A dynamic frequency modulation method based on Hypervisor, wherein multiple client operating systems Guest OS run on a virtual machine monitor Hypervisor, characterized in that: The method comprises: Count the current load of each core where the Guest OS is located; Determining whether the current load matches the current operating frequency of the core; If there is no match, a vote is initiated to each Guest OS, and the current number of votes returned by each Guest OS is received; wherein the current number of votes is used to indicate the number of target services on each Guest OS; Frequency modulation is performed according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located, including: obtaining a preset load table; the load table includes operating frequency ranges corresponding to different loads; according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located, querying the load table to obtain the frequency range corresponding to the current load, and performing frequency modulation within the frequency range corresponding to the current load.

2. The method according to claim 1, characterized in that Frequency adjustment is performed according to the current number of tickets returned by each Guest OS and the current load of the core where each Guest OS is located, including: If multiple Guest OSs are running on different cores in the same cluster, the maximum value of the current votes returned by the multiple Guest OSs is taken; The cluster is frequency-adjusted according to the maximum value of the current number of votes.

3. The method according to claim 1, characterized in that Determining whether the current load matches the current operating frequency of the core includes: Querying the load table to determine whether the current operating frequency of the core is within the operating frequency range corresponding to the current load; If so, the current load matches the current operating frequency; if not, they do not match.

4. The method according to any one of claims 1 to 3, characterized in that The target service on the Guest OS includes a high-priority process running on the Guest OS or an external wake-up source received on the Guest OS; wherein the external wake-up source includes one or more of a real-time clock RTC, an external interrupt or a modem service.

5. The method according to claim 1, characterized in that The method further comprises: The current load of each core where the Guest OS is located is counted in real time or periodically.

6. A dynamic frequency modulation device based on Hypervisor, wherein multiple client operating systems Guest OS run on the Hypervisor, characterized in that: The device comprises: A statistics module, used to count the current load of each core where the Guest OS is located; A determination module, used to determine whether the current load matches the current operating frequency of the core; A voting module, used for initiating voting to each Guest OS when there is no match, and receiving the current number of votes returned by each Guest OS; wherein the current number of votes is used to indicate the number of target services on each Guest OS; The frequency modulation module is used to perform frequency modulation according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located, including: obtaining a preset load table; the load table includes operating frequency ranges corresponding to different loads; according to the current number of votes returned by each Guest OS and the current load of the core where each Guest OS is located, querying the load table to obtain the frequency range corresponding to the current load, and performing frequency modulation within the frequency range corresponding to the current load.

7. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method described in any one of claims 1 to 5 are implemented.

8. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 5.

Images