Resource scheduling method and electronic device

Abstract

Embodiments of the present application provide a resource scheduling method and an electronic device. The method comprises: in the case where a change in a user scenario corresponding to a service processed by the electronic device is detected, adjusting a parameter related to CPU power consumption based on a preset scheduling policy obtained, the preset scheduling policy being a scheduling policy that can be directly recognized by the electronic device, the CPU power consumption corresponding to the preset scheduling policy being greater than the CPU power consumption corresponding to a scheduling policy used before the change in the user scenario; and after adjusting the parameter related to the CPU power consumption based on the preset scheduling policy, adjusting the parameter related to the CPU power consumption based on a first scheduling policy corresponding to a current user scenario obtained, the current user scenario being a scenario after the change in the user scenario, the first scheduling policy being a scheduling policy that can be recognized by the electronic device after being processed by translation. The method can reduce the phenomenon of running lag of the electronic device.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 202210598830.3, filed with the State Intellectual Property Office of China on May 30, 2022, entitled "Resource Scheduling Method and Electronic Device". This application claims priority to Chinese Patent Application No. 202210530454.4, filed with the State Intellectual Property Office of China on May 16, 2022, entitled "Resource Scheduling Method and Electronic Device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of electronic technology, specifically to a resource scheduling method and an electronic device. Background Technology

[0003] As the performance of electronic devices improves, the user scenarios for these devices are also increasing, such as video scenarios, benchmarking scenarios, conferencing scenarios, and chat scenarios. Due to the different user scenarios, the power consumption and battery life requirements of electronic devices are not the same. Therefore, electronic devices will issue different resource scheduling strategies for different user scenarios to adapt to the power consumption and battery life requirements of the current user scenario.

[0004] In traditional technologies, when a user switches from one user scenario to another using an electronic device, the device formulates and issues a new resource scheduling strategy based on the characteristics of the new scenario. However, this switching process can easily lead to lag or stuttering on the electronic device. Summary of the Invention

[0005] This application provides a resource scheduling method and an electronic device that can reduce the occurrence of lag in electronic devices.

[0006] In a first aspect, this application provides a resource scheduling method, which is executed by an electronic device, including: when a change is detected in the user scenario corresponding to the service being processed by the electronic device, adjusting parameters related to CPU power consumption based on an acquired preset scheduling strategy, wherein the preset scheduling strategy is a scheduling strategy that can be directly recognized by the electronic device, and the CPU power consumption corresponding to the preset scheduling strategy is greater than the CPU power consumption corresponding to the scheduling strategy used before the change in user scenario.

[0007] After adjusting the parameters related to CPU power consumption based on the preset scheduling strategy, the parameters related to CPU power consumption are adjusted again based on the first scheduling strategy corresponding to the current user scenario. The current user scenario is the scenario after the user scenario has changed. The first scheduling strategy is a scheduling strategy that needs to be translated and processed so that it can be recognized by the electronic device.

[0008] The user scenario corresponding to the business processed by the electronic device can also be simply referred to as the user scenario in which the electronic device operates. There are various user scenarios, such as video scenarios, gaming scenarios, and office scenarios. When the user scenario in which the electronic device operates changes, since both formulating scheduling strategies for the new user scenario and issuing scheduling strategies to the CPU will incur latency, the electronic device will first adjust parameters related to CPU power consumption (referred to as CPU power consumption parameters) based on a preset scheduling strategy. It should be noted that this preset scheduling strategy can be directly recognized by the electronic device, and especially by the CPU. Therefore, the CPU can directly adjust the power consumption parameters based on this preset scheduling strategy. Optionally, the strategy number of the aforementioned preset scheduling strategy can be -1.

[0009] Then, the electronic device can adjust the CPU power consumption-related parameters based on a preset scheduling policy after adjusting the CPU power consumption-related parameters based on a first scheduling policy corresponding to the current user scenario. The first scheduling policy can include a CPU power consumption scheduling policy, and can also include other hardware scheduling policies besides the CPU power consumption scheduling policy, such as OS scheduling policies. In this implementation, the formulation of the first scheduling policy can be performed during the adjustment of CPU power consumption parameters based on the preset scheduling policy, before the adjustment, or after the adjustment; this application does not restrict the execution order. Because the first scheduling policy needs to be translated before it can be recognized by the CPU, the process of adjusting CPU power consumption parameters based on the preset scheduling policy needs to be performed before adjusting CPU power consumption parameters based on the first scheduling policy, thus reducing the latency of the CPU waiting for the translation of the first scheduling policy.

[0010] In the above implementation, after determining that the user scenario of the electronic device has changed, a corresponding CPU power scheduling strategy can be determined based on the current user scenario. Before issuing the CPU power scheduling strategy, the electronic device first issues a preset scheduling strategy. Because this preset scheduling strategy can be directly run by the CPU and is applicable to various user scenarios of the electronic device, the switching process when the electronic device switches from the preset scheduling strategy to the CPU power scheduling strategy is relatively smooth, which can reduce the phenomenon of lag in the operation of the electronic device.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, when a change in the user scenario corresponding to the service being processed by the electronic device is detected, parameters related to CPU power consumption are adjusted based on the obtained preset scheduling strategy. This includes: when a change in the user scenario is detected and the power consumption of the first CPU is greater than that of the second CPU, parameters related to CPU power consumption are adjusted based on the preset scheduling strategy. The power consumption of the first CPU is the power consumption required to process the service corresponding to the current user scenario, and the power consumption of the second CPU is the power consumption required to process the service corresponding to the user scenario before the change.

[0012] In this implementation, when the user scenario of the electronic device changes, if the CPU power consumption required after the user scenario changes is greater than the CPU power consumption required before the user scenario changes, that is, switching from a low-power scenario to a high-power scenario, then in order to reduce the stuttering phenomenon in the initial stage of the high-power scenario, the parameters related to CPU power consumption can be adjusted based on a preset scheduling strategy, thereby reducing the stuttering phenomenon in the high-power scenario.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, before adjusting the parameters related to CPU power consumption based on the obtained preset scheduling strategy, the above method further includes: determining the first scheduling strategy according to the scenario identifier of the current user scenario.

[0014] This implementation involves determining the corresponding first scheduling strategy based on the scenario identifier of the current user scenario when a change in the user scenario is detected. The scenario identifier can be a scenario number (e.g., V01) or a scenario name, or other information that uniquely identifies the scenario. Determining the first scheduling strategy through this process provides a data foundation for subsequently adjusting CPU power consumption parameters based on the first scheduling strategy.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, determining the first scheduling strategy based on the scenario identifier of the current user scenario includes: determining the second scheduling strategy based on the scenario identifier of the current user scenario, wherein the second scheduling strategy includes at least one strategy parameter among the CPU's first long-term turbo frequency power consumption PL1, first short-term turbo frequency power consumption PL2, and first energy efficiency ratio EPP.

[0016] The first scheduling strategy is determined based on the second scheduling strategy, the scenario identifier of the current user scenario, and the current system load of the electronic device. The first scheduling strategy includes at least one strategy parameter among the second PL1, second PL2, and second EPP of the CPU. When the system load is greater than a preset first value, the second PL1 is greater than the first PL1, the second PL2 is greater than the second PL2, and the second EPP is less than the first EPP.

[0017] When determining the first scheduling strategy, the electronic device can first determine a basic scheduling strategy (i.e., the second scheduling strategy) based on the current user scenario, and then fine-tune the basic scheduling strategy according to the current system load. For example, when the load increases, PL1 and PL2 can be appropriately increased and EPP can be reduced to better balance the performance and power consumption of the electronic device.

[0018] In conjunction with the first aspect, in some implementations of the first aspect, before adjusting the parameters related to CPU power consumption based on the first scheduling strategy corresponding to the current user scenario, the above method further includes: determining the CPU chip platform type, where the chip platform type includes a first type or a second type;

[0019] Accordingly, the parameters related to CPU power consumption are adjusted based on the first scheduling policy corresponding to the current user scenario, including: adjusting the parameters related to CPU power consumption according to the policy parameters of the first scheduling policy and the chip platform type of the CPU.

[0020] Among them, the first type of CPU can be CPU chips, the second type of CPU can be The CPU chip. Because different types of CPU chips handle scheduling strategies differently, this application will adopt different processing methods for different types of chip platforms, thereby improving the adaptability of the resource scheduling method of this application.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, parameters related to CPU power consumption are adjusted according to the policy parameters of the first scheduling strategy and the CPU chip platform type, including: when the chip platform type is the first type, adjusting the parameters related to CPU power consumption to the policy parameters of the first scheduling strategy; when the chip platform type is the second type, determining the Dynamic Tuning Technology (DTT) strategy number according to the policy parameters of the first scheduling strategy; and adjusting the parameters related to CPU power consumption according to the DTT strategy number.

[0022] In other words, targeting and For CPUs, this application can adaptively match different power scheduling strategies.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, the detection of a change in the user scenario corresponding to the service being processed by the electronic device includes: obtaining process information and first information of the first process corresponding to the first window currently displayed by the electronic device, wherein the first information includes at least one of the following: GPU usage information, peripheral event information, or power mode information of the first process; determining the scenario identifier of the current user scenario based on the process information and the first information; and determining that the user scenario has changed if the scenario identifier of the current user scenario is different from the scenario identifier of the previous user scenario.

[0024] In this implementation, the electronic device can determine the current user scenario by using the process information of the currently displayed window and the first information. If the current user scenario differs from the previous user scenario, it can be assumed that the user scenario has changed. For example, if the first process is of video type, its GPU utilization is greater than 0, and its GPU engine is a GPU video processing engine, then the user scenario the electronic device is in is determined to be a video playback scenario. Understandably, if the first process is of video type, it can be determined that the user is currently using a video application. If the first process's GPU utilization is greater than 0, it indicates that the first process is consuming GPU resources during operation. If the first process's GPU engine is a GPU video processing engine, it indicates that the first process is using the GPU for decoding operations during operation. Thus, it can be determined that the user is highly likely using the electronic device to play video, i.e., the user scenario the electronic device is in is a video playback scenario.

[0025] If the first process is a video-related process, its GPU utilization is greater than 0, and its GPU engine is a GPU 3D engine, then the user scenario is determined to be a video browsing scenario. Conversely, if the first process's GPU engine is a GPU 3D engine, it indicates that the first process only uses the GPU for 2D or 3D rendering operations, suggesting that the user is browsing video resources on the electronic device rather than playing videos; therefore, the user scenario is a video browsing scenario.

[0026] If the first process is a game application, we can first determine that the user is currently using a game application. If the GPU utilization of the first process is greater than 0, it indicates that the first process is consuming GPU resources during its execution. If the GPU engine of the first process is a GPU 3D engine, it indicates that the first process is using the GPU for 2D or 3D rendering operations. Therefore, we can determine that the user is highly likely playing a game on the electronic device, meaning the user's scenario is a game scenario.

[0027] In conjunction with the first aspect, in some implementations of the first aspect, the aforementioned peripheral event information may include one or more of the following: keyboard input events, mouse input events, microphone input events, and camera input events;

[0028] If the first process is a social application and a keyboard input event is detected, the user scenario is determined to be a text chat scenario. That is, if it is detected that the user is using a social application and typing simultaneously, the user is highly likely using a social application for chatting, and the user scenario can be determined to be a text chat scenario.

[0029] If the first process is a social application, and a microphone input event is detected but no camera input event is detected, then the user scenario in which the device is located is determined to be a voice chat scenario. That is, if it is detected that the user is using a social application and simultaneously using voice input, then the user is highly likely using a social application for voice chat, and the user scenario in which the device is located can be determined to be a voice chat scenario.

[0030] If the first process is a social application, and both microphone and camera input events are detected, it can be determined that the user scenario is a video chat scenario. That is, if it is detected that the user is using a social application and simultaneously inputting video, then the user is highly likely using a social application for video chat, and the user scenario can be determined to be a video chat scenario.

[0031] If the first process is of an office type and a keyboard input event is detected, the user scenario in which the electronic device is located is determined to be a document editing scenario. If it is detected that the user is using an office application and typing at the same time, then the user is most likely using an office application to edit a document, and the user scenario in which the electronic device is located can be determined to be a document editing scenario.

[0032] If the first process is of an office-related type, and mouse input events are detected but no keyboard input events are detected, then the user scenario in which the application is running is determined to be a document browsing scenario. That is, if the user is detected using the mouse but not the keyboard while using an office application, then the user is highly likely using the office application to browse documents, and the user scenario in which the application is running can be determined to be a document browsing scenario.

[0033] If the first process is classified as office-related, and microphone and camera input events are detected, the user scenario is determined to be a video conferencing scenario. That is, if the user is detected using a camera while using an office application, the user is highly likely to be using the office application for a video conference, thus confirming the user scenario is a video conferencing scenario. Therefore, peripheral event information can be combined to determine the current user scenario.

[0034] In conjunction with the first aspect, in some implementations of the first aspect, the aforementioned electronic device includes a scene recognition engine, a scheduling engine, a basic input / output system (BIOS), a system and chip driver OS2SOC node, and a CPU; the aforementioned method includes:

[0035] When the scene recognition engine detects a change in the user scenario corresponding to the service being processed by the electronic device, it determines the strategy parameters of the second scheduling strategy based on the scenario identifier of the current user scenario.

[0036] The scene recognition engine sends the scene identifier of the current user scene and the strategy parameters of the second scheduling strategy to the scheduling engine;

[0037] The scheduling engine determines the strategy parameters of the first scheduling strategy based on the strategy parameters of the second scheduling strategy, the scenario identifier of the current user scenario, and the current system load of the electronic device.

[0038] The scheduling engine sends the policy number of the preset scheduling policy to the BIOS;

[0039] The BIOS sends the policy number of the preset scheduling policy to the CPU;

[0040] The CPU adjusts parameters related to CPU power consumption according to the policy number of the preset scheduling policy;

[0041] When the CPU chip platform type is the first type, the scheduling engine sends the policy parameters of the first scheduling policy to the OS2SOC node, the OS2SOC node sends the policy parameters of the first scheduling policy to the CPU, and the CPU adjusts the parameters related to CPU power consumption based on the policy parameters of the first scheduling policy.

[0042] When the CPU chip platform type is type 2, the scheduling engine determines the DTT policy number according to the policy parameters of the first scheduling policy, sends the DTT policy number to the BIOS, the BIOS sends the DTT policy number to the CPU, and the CPU adjusts the parameters related to CPU power consumption based on the DTT policy number.

[0043] Secondly, this application provides an apparatus included in an electronic device, which has the function of implementing the electronic device behavior described in the first aspect and its possible implementations. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described functions. For example, a receiving module or unit, a processing module or unit, etc.

[0044] Thirdly, this application provides an electronic device, which includes a processor, a memory, and an interface; the processor, memory, and interface cooperate with each other to enable the electronic device to execute any one of the methods in the first aspect of the technical solution.

[0045] Fourthly, this application provides a chip including a processor. The processor is used to read and execute a computer program stored in a memory to perform the methods in the first aspect and any possible implementation thereof.

[0046] Optionally, the chip may also include a memory, which is connected to the processor via a circuit or wire.

[0047] Alternatively, the chip may also include a communication interface.

[0048] Fifthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform any one of the methods in the first aspect of the technical solution.

[0049] Sixthly, this application provides a computer program product, which includes computer program code that, when executed on an electronic device, causes the electronic device to perform any one of the methods in the first aspect of the technical solution. Attached Figure Description

[0050] Figure 1 This is a schematic diagram illustrating the change in CPU power consumption when a user scenario changes, as provided in an embodiment of this application.

[0051] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0052] Figure 3 This is a software structure block diagram of an electronic device provided in an embodiment of this application;

[0053] Figure 4 This is a schematic diagram illustrating the interaction between software modules in an electronic device, provided in an embodiment of this application.

[0054] Figure 5 This is another example of an interaction diagram between software modules in an electronic device provided in the embodiments of this application;

[0055] Figure 6 This is a flowchart illustrating an example of a resource scheduling method provided in an embodiment of this application;

[0056] Figure 7 This is a signaling interaction diagram of an example resource scheduling method provided in an embodiment of this application;

[0057] Figure 8 This is a signaling interaction diagram of another resource scheduling method provided in the embodiments of this application;

[0058] Figure 9This is an example of a window change interface diagram provided in an embodiment of this application;

[0059] Figure 10 This is a signaling interaction diagram of another example of a resource scheduling method provided in the embodiments of this application;

[0060] Figure 11 This is a signaling interaction diagram of another example of a resource scheduling method provided in the embodiments of this application. Detailed Implementation

[0061] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0062] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0063] Users are increasingly using electronic devices in various scenarios, such as video conferencing, benchmarking, conferencing, and chatting on personal computers (PCs). These diverse scenarios result in varying power consumption and battery life requirements for electronic devices; for example, video conferencing consumes more power than chatting. Therefore, electronic devices employ different resource scheduling strategies for different scenarios. For instance, in video conferencing, the power of the central processing unit (CPU) can be increased.

[0064] However, when a user switches from one user scenario to another using an electronic device, such as from a chat scenario to a video scenario, the electronic device will formulate and issue a new resource scheduling strategy based on the characteristics of the new user scenario (e.g., video scenario). During this process, because the foreground of the electronic device has already switched from one user scenario to another, but the background of the electronic device is still formulating a new resource scheduling strategy, in the initial stage of switching to the new user scenario, the new user scenario still uses the resource scheduling strategy of the previous user scenario, resulting in a switching latency. If this is the case, when switching from a low-power user scenario to a high-power user scenario, the high-power user scenario will initially use the resource scheduling strategy corresponding to the low-power user scenario, which may not meet the needs of the high-power user scenario, leading to lag or stuttering on the electronic device. For an example, please refer to [link to example]. Figure 1 Time t is the time when the user scenario in the foreground of the electronic device is switched, but the new resource scheduling strategy takes effect at time t'. As shown in the figure, time t' is after time t. During the time period between time t and time t', the foreground has switched to a high-power user scenario, but the electronic device is still using the resource scheduling strategy corresponding to the low-power user scenario.

[0065] In view of this, the resource scheduling method provided in this application can be applied to electronic devices such as laptops, PCs, and ultra-mobile personal computers (UMPCs). When a user switches user scenarios using an electronic device, the device can first issue a preset resource scheduling strategy. This preset resource scheduling strategy can meet the needs of most user scenarios. Therefore, in the initial stage of the switched user scenario, the preset resource scheduling strategy can be used to meet the needs of the new user scenario and reduce the phenomenon of electronic device lag. It should be noted that this application does not limit the specific type of electronic device.

[0066] To ensure clarity and conciseness in the description of the following embodiments, a brief introduction to the relevant concepts or technologies is given first:

[0067] The focus window is the window that has the user's focus. It is the only window that can receive keyboard input. The determination of the focus window is related to the system's focus mode. The top-level window of the focus window is called the active window. Only one window can be active at a time. The focus window is most likely the window the user currently needs to use.

[0068] Focus mode determines how the mouse gives focus to a window. Generally, there are three focus modes:

[0069] (1) Click-to-focus: In this mode, the window that is clicked by the mouse will gain focus. That is, when the mouse clicks anywhere on a window that can gain focus, that window will be activated, placed in front of all windows, and will receive keyboard input. When the mouse clicks on other windows, that window will lose focus.

[0070] (2) Focus-follow-mouse: In this mode, the window under the mouse cursor can gain focus. That is, when the mouse moves within the range of a window that can gain focus, the user does not need to click anywhere on the window to activate it and receive keyboard input, but the window is not necessarily placed on top of all windows. When the mouse moves out of the window's range, the window will also lose focus.

[0071] (3) Sloppy focus: This focus mode is similar to focus-follow-mouse. When the mouse moves within the range of a window that can receive focus, the user does not need to click anywhere on the window to activate it and receive keyboard input. However, this window is not necessarily placed on top of all windows. Unlike focus-follow-mouse, the focus does not change when the mouse moves out of the window's range. The system focus only changes when the mouse moves to another window that can receive focus.

[0072] A process consists of multiple threads, and threads can create windows. The focused process is the process to which the thread that created the focused window belongs.

[0073] (4) Long-term turbo power consumption (power limit 1, PL1) refers to the power consumption of the CPU under normal load, which is equivalent to thermal design power. The CPU's power consumption does not exceed PL1 most of the time.

[0074] (5) Short-term turbo boost power consumption (power limit 2, PL2) refers to the highest power consumption that the CPU can reach in a short period of time, which has a duration limit. Generally, PL2 is greater than PL1.

[0075] (6) CPU Energy Performance Preference (EPP) is used to reflect the CPU's scheduling tendency, and its value ranges from 0 to 255. The lower the CPU EPP, the more the CPU tends to perform well; the higher the CPU EPP, the more the CPU tends to consume less power.

[0076] (7) Translation refers to the transformation of parameters or data in one form to obtain parameters or data in another form that can be recognized by a specified platform. For example, electronic devices can translate obtained policy parameters to obtain parameters that can be recognized by the CPU chip platform.

[0077] Based on this, exemplarily, Figure 2 This is a schematic diagram of the structure of the electronic device 100 provided in an embodiment of this application. Figure 2 As shown, the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, a wireless communication module 150, a display screen 160, etc.

[0078] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0079] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0080] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0081] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0082] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an I2C interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a USB interface, etc.

[0083] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0084] The charging management module 140 receives charging input from a charger, which can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0085] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display screen 160, and wireless communication module 150, etc. In some embodiments, the power management module 141 and the charging management module 140 may also be housed in the same device.

[0086] The wireless communication module 150 can provide wireless communication solutions for use on the electronic device 100, including WLAN (such as Wi-Fi), Bluetooth, Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), and Infrared (IR) technologies. For example, in this embodiment, the electronic device 100 can establish a Bluetooth connection with a terminal device (such as a wireless headset 100) through the wireless communication module 150.

[0087] The wireless communication module 150 may be one or more devices integrating at least one communication processing module. The wireless communication module 150 receives electromagnetic waves via an antenna, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to the processor 110. The wireless communication module 150 may also receive signals to be transmitted from the processor 110, perform frequency modulation and amplification on them, and then convert them into electromagnetic waves for radiation via the antenna.

[0088] Electronic device 100 implements display functions through a GPU, a display screen 160, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 160 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0089] The display screen 160 is used to display images, videos, etc. The display screen 160 includes a display panel.

[0090] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0091] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. For example, in this embodiment, processor 110 can execute instructions stored in internal memory 121, which may include a program storage area and a data storage area.

[0092] The program storage area can store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.). The data storage area can store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Furthermore, the internal memory 121 can include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0093] The software system of the aforementioned electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This embodiment of the invention uses a layered Windows system as an example to exemplify the software structure of the electronic device 100.

[0094] For example, Figure 3 This is a software structure block diagram of an electronic device 100 according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Windows system is divided into user mode and kernel mode. User mode includes the application layer and subsystem dynamic link libraries. Kernel mode, from bottom to top, is divided into the hardware layer, firmware layer, hardware abstraction layer (HAL), kernel and driver layer, and executable.

[0095] like Figure 3 As shown, the application layer includes applications such as music, video, games, office applications, and social applications. The application layer also includes an environment subsystem, a scene recognition engine, and a scheduling engine. Only some applications are shown in the figure; the application layer may also include other applications, such as shopping applications and browsers, which are not limited in this application. In one embodiment, the environment subsystem, scene recognition engine, and scheduling engine can be integrated into a PC management application.

[0096] The environment subsystem can present a subset of basic execution system services to the application in a specific form, providing the application with an execution environment.

[0097] The scene recognition engine can identify the user scenario in which the electronic device 100 is located and determine a basic scheduling strategy (also known as a second scheduling strategy) that matches the user scenario. The scheduling engine can obtain the load status of the electronic device 100 and, in conjunction with the load status of the electronic device 100 and the aforementioned basic scheduling strategy, determine an actual scheduling strategy (also known as a first scheduling strategy) that conforms to the actual operating conditions of the electronic device 100. Specific details about the scene recognition engine and the scheduling engine will be discussed later and will not be described here.

[0098] The subsystem dynamic link library includes an API module, which includes the Windows API and the Windows native API. Both the Windows API and the Windows native API provide system call entry points and internal function support for applications. The difference is that the Windows native API is native to the Windows system. For example, the Windows API may include user.dll and kernel.dll, while the Windows native API may include ntdll.dll. user.dll is the Windows user interface, used to perform operations such as creating windows and sending messages. kernel.dll provides applications with an interface to access the kernel. ntdll.dll is an important Windows NT kernel-level file that describes the interface of the Windows native NT API. When Windows starts, ntdll.dll resides in a specific write-protected area of ​​memory, preventing other programs from occupying this memory area.

[0099] The execution unit includes the process manager, virtual memory manager, security reference monitor, I / O manager, Windows management instrumentation (WMI), power manager, operating system event driver (OsEventDriver) node, and operating system to system on chip (OS2SOC) node, etc.

[0100] The process manager is used to create and terminate processes and threads.

[0101] The virtual memory manager implements "virtual memory". The virtual memory manager also provides basic support for the cache manager.

[0102] The Security Reference Monitor can enforce security policies on the local computer, protecting operating system resources and performing protection and monitoring of runtime objects.

[0103] The I / O manager performs device-independent input / output and further processes calls to the appropriate device drivers.

[0104] The power manager can manage power state changes for all devices that support power state changes.

[0105] System event-driven nodes can interact with the kernel and driver layer, such as with the graphics card driver. After determining that a GPU video decoding event exists, they report the GPU video decoding event to the scene recognition engine.

[0106] The system and chip driver nodes allow the scheduling engine to send adjustment information to hardware devices, such as sending information to the CPU to adjust PL1 and PL2.

[0107] The kernel and driver layer includes the kernel and device drivers.

[0108] The kernel is an abstraction of the processor architecture, isolating the execution unit from the differences in processor architecture and ensuring system portability. The kernel can perform thread arrangement and scheduling, trap and exception handling and scheduling, interrupt handling and scheduling, etc.

[0109] Device drivers run in kernel mode and serve as the interface between the I / O system and the relevant hardware. Device drivers can include graphics card drivers, Intel DTT drivers, mouse drivers, audio / video drivers, camera drivers, keyboard drivers, etc. For example, a graphics card driver enables the GPU to run, and an Intel DTT driver enables the CPU to run.

[0110] HAL is a kernel-mode module that hides various hardware-related details, such as I / O interfaces, interrupt controllers, and multiprocessor communication mechanisms. It provides a unified service interface for different hardware platforms running Windows, achieving portability across multiple hardware platforms. It's important to note that, to maintain Windows portability, internal Windows components and user-written device drivers do not directly access the hardware; instead, they call routines in HAL.

[0111] The firmware layer may include the Basic Input Output System (BIOS), a set of programs embedded in a read-only memory (ROM) chip on the computer's motherboard. The BIOS stores the computer's most important basic input / output programs, power-on self-test (POST) programs, and system boot programs. It can read and write specific system settings information from the complementary metal-oxide-semiconductor (CMOS) display. Its main function is to provide the lowest-level, most direct hardware settings and control for the computer. For example, the Intel DTT driver can send instructions to the CPU through the BIOS. Optionally, the firmware layer may also include an embedded controller (EC), which can receive parameters from the hardware layer, process them accordingly, and then send them to the BIOS, which in turn passes them to higher layers.

[0112] The hardware layer can include hardware structures such as GPU, CPU, mouse, microphone, camera, and keyboard.

[0113] It should be noted that the embodiments of this application are only illustrated using the Windows system. In other operating systems (such as Android, iOS, etc.), the solution of this application can also be implemented as long as the functions implemented by each functional module are similar to those in the embodiments of this application.

[0114] Figure 4 A schematic diagram of the software and hardware workflow for the electronic device 100 to schedule resources is shown.

[0115] like Figure 4 As shown, the application layer scene recognition engine includes a system probe module, a scene recognition module, and a basic policy matching manager. The scene recognition module can interact with both the system probe module and the basic policy matching manager. The scene recognition module can send a request to the system probe module to obtain probe status. The system probe module can obtain the operating status of the electronic device 100. For example, the system probe module may include power status probes, peripheral device status probes, process load probes, audio / video status probes, system load probes, and system event probes, etc.

[0116] The power status probe can subscribe to power status events in kernel space and determine the power status based on the callback functions fed back from kernel space. Power status includes battery (remaining) power, power mode, etc., and power mode can include alternating current (AC) and direct current (DC). For example, the power status probe can send a request to subscribe to power status events to the OsEventDriver node in the execution layer, and the OsEventDriver node forwards the request to the power manager in the execution layer. The power manager can then feed back callback functions to the power status probe through the OsEventDriver node.

[0117] Peripheral status probes can subscribe to peripheral events in kernel space and determine the peripheral events based on the callback functions fed back from kernel space. Peripheral events include mouse wheel scroll events, mouse click events, keyboard input events, microphone input events, camera input events, etc.

[0118] Process load probes can subscribe to process load in kernel space and determine the load of a process (e.g., the first process) based on the callback function fed back from kernel space.

[0119] The system load probe can subscribe to system load in kernel mode and determine the system load based on the callback function fed back from kernel mode.

[0120] The audio / video status probe can subscribe to audio / video events in kernel space and determine the current audio / video events on the electronic device 100 based on the callback functions fed back from kernel space. Audio / video events may include GPU decoding events, etc. For example, the audio / video status probe can send a request to the OsEventDriver node in the execution layer to subscribe to GPU decoding events. The OsEventDriver node then forwards this request to the kernel and the graphics card driver in the driver layer. The graphics card driver can monitor the GPU's status, and upon detecting that the GPU is performing decoding operations, it feeds back a callback function to the audio / video status probe through the OsEventDriver node.

[0121] System event probes can subscribe to system events in kernel mode and determine these events based on callback functions returned by the kernel. System events can include window change events, process creation events, thread creation events, etc. For example, a system event probe can send a request to the OsEventDriver node at the execution layer to subscribe to a process creation event, which is then forwarded to the process manager. After creating the process, the process manager can return a callback function to the system event probe through the OsEventDriver node. As another example, the system event probe can also subscribe to focus window change events by sending a request to the API module. The API module can monitor whether the focus window of the electronic device 100 has changed, and when a change is detected, it returns a callback function to the system event probe.

[0122] As can be seen, the system probe module subscribes to various events of the electronic device 100 in kernel mode and then determines the operating state of the electronic device 100 based on the callback functions fed back from kernel mode, thus obtaining the probe state. After obtaining the probe state, the system probe module can feed back the probe state to the scene recognition module. After receiving the probe state, the scene recognition module can determine the user scene in which the electronic device 100 is located based on the probe state. This user scene can include video scene, game scene, office scene, and social scene, etc. The user scene can reflect the user's current usage needs. For example, when the scene recognition engine identifies the focus window as a video application window, it determines that the electronic device 100 is in a video scene, indicating that the user needs to use a video application to watch or browse videos. Another example is when the scene recognition engine identifies the focus window as WeChat... TMWhen the chat window is accessed, it is determined that the electronic device 100 is in a social scenario. Typically, when the scenario recognition module determines a change in the user scenario of the electronic device through the probe status (e.g., a change in probe status indicates a change in the user scenario), it can also send this user scenario to the basic policy matching manager. This allows the basic policy matching manager to determine a new scheduling policy (also known as a second scheduling policy, see S301 and S302 below for details). The basic policy matching manager then feeds back this basic scheduling policy to the scenario recognition module. The scenario recognition module then sends the basic scheduling policy and the user scenario to the application layer scheduling engine.

[0123] like Figure 4 As shown, the scheduling engine includes a load controller, a chip policy fusion unit, and a scheduling executor. The load controller receives the basic scheduling policy and user scenarios sent by the scenario recognition module. The load controller can also obtain the system load from the system probe module and adjust the basic scheduling policy according to the system load and user scenarios to obtain the actual scheduling policy (also called the first scheduling policy, see the description in S310 below). The actual scheduling policy includes the OS scheduling policy and the first CPU power consumption scheduling policy (also called the first sub-policy).

[0124] After determining the first scheduling policy, the load controller can send the OS scheduling policy from the first scheduling policy to the scheduler executor, which then performs scheduling based on the OS scheduling policy. The OS scheduling policy is used to adjust the process priority and I / O priority of the focus process. For example, the scheduler executor can send an instruction to the process manager to adjust the process priority of the focus process; in response to this instruction, the process manager adjusts the process priority of the focus process. As another example, the scheduler executor can send an instruction to the I / O manager to adjust the I / O priority of the focus process; in response to this instruction, the I / O manager adjusts the I / O priority of the focus process.

[0125] Simultaneously, the load controller can also send the first CPU power scheduling policy from the first scheduling strategy to the chip policy fusion unit. After receiving the first CPU power scheduling policy, the chip policy fusion unit typically needs to translate the first CPU power scheduling policy according to the CPU chip platform type before issuing it, so that the translated first CPU power scheduling policy is adapted to the CPU chip platform type. This translation process will generate latency. Therefore, in order to reduce the translation latency of the first CPU power scheduling policy, in this embodiment, the chip policy fusion unit will first issue a preset scheduling policy (this preset scheduling policy can be adapted to various CPU chip platforms and does not need to be translated), send the preset scheduling policy to the scheduler executor, and then the scheduler executor sends it to the Intel DTT driver through the WMI plugin, and then sends it to the CPU through the BIOS.

[0126] During the process of the chip policy fusion unit issuing the preset scheduling policy, the aforementioned first CPU power consumption scheduling policy can be translated simultaneously. This is because CPU chip platform types are mainly divided into two categories, namely AMD (Advanced Micro Devices). (Advanced Micro Devices, AMD) CPUs and These two types of CPUs have different methods for adjusting CPU power consumption, so they need to be distinguished.

[0127] If the CPU's chip platform type is AMD (also known as Type 1), the scheduler can send instructions to the power manager to adjust the EPP according to the first CPU power scheduling policy, thereby adjusting the CPU's EPP. Additionally, the scheduler can also send instructions to the OS2SOC driver node to adjust PL1 and PL2 according to the first CPU power scheduling policy, thereby adjusting the CPU's PL1 and PL2.

[0128] If the CPU chip platform type is The chip policy fusion unit first needs to derive a second CPU power scheduling policy (also known as a second sub-policy, see S329-S333 below for details) based on the first CPU power scheduling policy. The scheduling executor can send the second CPU power scheduling policy to the Intel DTT driver through the WMI plugin. The second CPU power scheduling policy may include the minimum value of PL1, the maximum value of PL1, PL2, the duration of PL2, and EPP. The Intel DTT driver CPU runs based on the second CPU power scheduling policy.

[0129] Then, if the CPU receives the adjusted first scheduling policy, it can switch the preset scheduling policy to the first scheduling policy. Since both the preset scheduling policy and the first scheduling policy are adapted to the current user scenario, the switching process is relatively smooth, reducing the phenomenon of electronic devices running sluggishly.

[0130] From the above Figure 4 As can be seen from the workflow, the resource scheduling method provided in this application mainly includes two processes: (1) determining that the user scenario of the electronic device has changed; and (2) issuing a preset scheduling strategy before issuing the new scheduling strategy corresponding to the user scenario. The above two processes will be described below with reference to the accompanying drawings. It can be understood that these two processes can be... Figure 2 The electronic device shown can be used, or it can be executed by Figure 4 The modules in the electronic device shown are executed.

[0131] To better understand the resource scheduling method provided in the embodiments of this application, let's first refer to the above... Figure 4 The software architecture involved in the embodiments of this application is simplified as follows: Figure 5 As shown, the software architecture includes: scene recognition engine, scheduling engine, BIOS and CPU.

[0132] The scene recognition engine detects a change in the user scenario of the electronic device and determines the corresponding scheduling policy based on the new scenario. Then, the scene recognition engine sends the CPU power scheduling policy from this policy to the scheduling engine. Because the scheduling engine incurs a delay when translating this CPU power scheduling policy, it first sends a preset scheduling policy to the BIOS, causing the BIOS to schedule the CPU to run based on this preset policy.

[0133] Then, the scheduling engine translates the above CPU power scheduling policy to obtain the corresponding policy number, and sends the translated policy number to the BIOS, so that the BIOS schedules the CPU to run based on the policy number. Because the above preset scheduling policy can be adapted to various CPU chip platforms and does not require translation, the CPU can run based on the preset scheduling policy while waiting for the scheduling engine to translate, instead of running based on the scheduling policy before the user scenario changed, thus reducing the phenomenon of electronic device lag.

[0134] The following describes the specific process of the resource scheduling method provided in the embodiments of this application, such as... Figure 6 As shown, this method can be executed by an electronic device and includes:

[0135] S1. When a change in the user scenario of the electronic device is detected, the corresponding CPU power consumption scheduling strategy is determined based on the scenario identifier of the current user scenario.

[0136] The process of detecting changes in the user scenario of the electronic device and determining the corresponding CPU power scheduling strategy for the current user scenario are detailed in the following embodiments. Optionally, when the electronic device detects a change in its user scenario, it can set an identifier, such as identifier 1 indicating a change in the user scenario. Optionally, the scenario identifier of the current user scenario can be information that can uniquely identify a scenario, such as scenario number or scenario name; the determined CPU power scheduling strategy can include strategy parameters, such as PL1, PL2, and EPP, and can also include strategy numbers, such as strategy 1, strategy 2, etc., and there can be a correspondence between the strategy number and the strategy parameters.

[0137] S2. Obtain the policy number of the preset scheduling policy.

[0138] Optionally, the policy number of the preset scheduling policy can be -1, representing the scheduling policy when the electronic device is in a high-power state. Therefore, it can be applied to various user scenarios of the electronic device. For example, the policy parameters of the preset scheduling policy can be PL1 of 35W, PL2 of 60W, and EPP of 180.

[0139] S3. Send the policy number of the preset scheduling policy to the CPU, so that the CPU runs based on the policy number of the preset scheduling policy.

[0140] Here, to reduce the time spent by electronic devices translating the CPU power scheduling policy, the policy number of the preset scheduling policy can be sent to the CPU first, allowing the CPU to run in a high-power state and reducing stuttering. In one implementation, after receiving the preset policy number, the CPU can obtain the corresponding policy parameters based on the policy number, and then adjust its operating state according to the obtained policy parameters. It should be noted that the policy number of this preset scheduling policy can be adapted to... CPU and The CPU does not require translation.

[0141] S4. Translate the CPU power scheduling policy determined in S1 above to determine the translated CPU power scheduling policy.

[0142] S5. Send the translated CPU power scheduling policy to the CPU so that the CPU runs based on the CPU power scheduling policy.

[0143] While the CPU is running based on a preset scheduling policy, the electronic device can translate the aforementioned determined CPU power scheduling policy, thereby switching the CPU's scheduling policy from the preset policy to the translated CPU power scheduling policy, completing a smooth transition process. The process of translating the CPU power scheduling policy in S4 can be detailed in the following embodiments.

[0144] In one embodiment, after determining in S1 that the user scenario of the electronic device has changed, it can first be determined whether the user scenario of the electronic device has changed from a low-power scenario to a high-power scenario, such as switching from an office scenario to a video scenario. If so, the steps S2-S3 of issuing a preset scheduling strategy are executed; if the user scenario of the electronic device has changed from a high-power scenario to a low-power scenario, the steps S2-S3 can be omitted. The process of determining whether the user scenario of the electronic device has changed from a low-power scenario to a high-power scenario can be as follows: a scenario level table is set in advance, and a level is assigned to each user scenario. For example, the higher the required CPU power consumption, the higher the level. For example, the office scenario is level 2, and the video scenario is level 5. If the level of the user scenario after the change is higher than the level of the user scenario before the change, it can be determined that the user scenario of the electronic device has changed from a high-power scenario to a low-power scenario.

[0145] In another embodiment, to further reduce the lag of electronic devices, when the electronic device detects a change in the user scenario in S1, it can simultaneously execute the process of determining the corresponding CPU power scheduling strategy based on the current user scenario and the process of S2-S3, or execute the process of S2-S3 first and then execute the process of determining the corresponding CPU power scheduling strategy based on the current user scenario. That is, once a change in the user scenario is detected, a preset scheduling strategy is issued, further reducing the time waiting for the CPU power scheduling strategy to be issued.

[0146] In this embodiment, after the electronic device determines that the user scenario it is in has changed, it can determine the corresponding CPU power scheduling strategy based on the current user scenario. Before issuing the CPU power scheduling strategy, the electronic device first issues a preset scheduling strategy. Because the preset scheduling strategy can be directly run by the CPU and can be applied to various user scenarios of the electronic device, the switching process when the electronic device switches from the preset scheduling strategy to the CPU power scheduling strategy is relatively smooth, which can reduce the phenomenon of lag in the operation of the electronic device.

[0147] In combination with the above Figure 5 Software architecture and Figure 6 The flowchart shown below illustrates the resource scheduling method provided in this application, which will be further described below with an example. Figure 7 As shown, it can specifically include:

[0148] S11. When the scene recognition engine detects a change in the user scene of the electronic device, it determines the corresponding CPU power consumption scheduling strategy 1 based on the scene identifier of the current user scene.

[0149] The process by which the scene recognition engine detects changes in the user scenario of an electronic device can be seen in the following... Figure 8 The process of the illustrated embodiment. Optionally, after the scene recognition engine determines that the user scene of the electronic device has changed, it can also obtain the scene identifier of the current user scene, such as the scene number of the current user scene.

[0150] The process by which the scene recognition engine determines CPU power scheduling strategy 1 can be found in the following... Figure 10 The process of S301-S303 in the illustrated embodiment.

[0151] S12, The scene recognition engine sends the scene identifier of the current user scene and CPU power consumption scheduling policy 1 to the scheduling engine.

[0152] In one implementation, the scene recognition engine can send the scene number of the current user scene and the policy parameters corresponding to CPU power scheduling policy 1 to the scheduling engine. In another implementation, the scene recognition engine can send the scene number of the current user scene and the policy number corresponding to CPU power scheduling policy 1 to the scheduling engine. Since the policy number corresponding to CPU power scheduling policy 1 and the policy parameters can have a corresponding relationship, the corresponding policy parameters can be found through the policy number.

[0153] S13. The scheduling engine determines the CPU power scheduling strategy 2 based on the CPU power scheduling strategy 1, the scene identifier of the current user scenario, and the system load.

[0154] The system load can be determined based on the number of processes currently running on the electronic device. For example, the more processes there are, the heavier the system load, and the fewer processes there are, the lighter the system load. The process by which the scheduling engine determines CPU power scheduling strategy 2 can be found below. Figure 10 The process of S304-S310 in the illustrated embodiment.

[0155] S14. The scheduling engine sends the policy number of the preset scheduling policy to the BIOS.

[0156] It is understandable that the scheduling engine can send the policy number of the preset scheduling policy to the BIOS through WMI.

[0157] S15, the BIOS sends the policy number of the preset scheduling policy to the CPU, so that the CPU runs according to the policy number of the preset scheduling policy.

[0158] The CPU operates based on a preset scheduling policy, which means adjusting the CPU's power consumption parameters (such as PL1, PL2, and EPP parameters) to the policy parameters corresponding to the preset scheduling policy. In one implementation, the process from S14 to S15 can be executed before S13 to further reduce the CPU's waiting time, thereby reducing lag in electronic devices.

[0159] It should be noted that the embodiments of this application do not restrict the execution order of the above-mentioned processes S12-S13 and S14-S15. That is, when the user scenario changes, S12-S13 can be executed first and then S14-S15, or S14-S15 can be executed first and then S12-S13.

[0160] S16. The scheduling engine translates CPU power scheduling policy 2 to obtain the translated CPU power scheduling policy 2.

[0161] S17. The scheduling engine sends the translated CPU power scheduling policy 2 to the BIOS.

[0162] S18, the BIOS sends the translated CPU power scheduling policy 2 to the CPU, so that the CPU runs based on the CPU power scheduling policy 2.

[0163] The translation of CPU power scheduling policy 2 by the scheduling engine can be a process of translating the policy parameters in CPU power scheduling policy 2 based on the CPU platform type. The process of the scheduling engine translating and issuing CPU power scheduling policy 2 in S16-S18 can be seen below. Figure 11 The illustrated embodiment is described below. After CPU power scheduling policy 2 is translated, the CPU power consumption parameters can be adjusted to the policy parameters corresponding to CPU power scheduling policy 2.

[0164] In this embodiment, after the electronic device determines that the user scenario it is in has changed, it can determine the corresponding CPU power scheduling strategy based on the current user scenario. Before issuing the CPU power scheduling strategy, the electronic device first issues a preset scheduling strategy. Because the preset scheduling strategy can be directly run by the CPU and can be applied to various user scenarios of the electronic device, the switching process when the electronic device switches from the preset scheduling strategy to the CPU power scheduling strategy is relatively smooth, which can reduce the phenomenon of lag in the operation of the electronic device.

[0165] Regarding the process S11 described above, taking the transformation of an electronic device from an office scenario to a video scenario as an example, such as... Figure 8 As shown, the process for determining when the user scenario of an electronic device changes is as follows:

[0166] S101, The system probe module sends a request to the OsEventDriver node to subscribe to the process creation event.

[0167] like Figure 4As shown, the scene recognition engine includes a system probe module, which in turn includes a system event probe. In this embodiment, the system event probe can send a request to subscribe to a process creation event to the OsEventDriver node located in the execution layer. This request to subscribe to a process creation event can also be referred to as a first request.

[0168] In one alternative implementation, the request to subscribe to process creation events can carry the process name, meaning the scene recognition engine can subscribe only to the creation events of a specified process, reducing interference from the creation events of irrelevant processes. For example, the specified process could be a video application, a game application, an office application, a social application, and so on. Of course, in other implementations, the scene recognition engine may not impose restrictions on the subscribed process creation events.

[0169] S102, the OsEventDriver node sends a request to the process manager to subscribe to the process creation event.

[0170] The request for a process creation event can be found in the description of S101, and will not be repeated here.

[0171] In other words, the system event probe of the scene recognition engine can send a request to the process manager to subscribe to the process creation event through the OsEventDriver node.

[0172] Understandably, the OsEventDriver node registers a callback with the process manager. The purpose of registering this callback is to return the process creation event to the OsEventDriver node after the process manager creates a process.

[0173] S103, The system probe module sends a request to the OsEventDriver node to subscribe to GPU decoding events.

[0174] Still as Figure 4 As shown, the system probe module also includes an audio / video status probe. In this embodiment, the audio / video status probe of the system probe module can send a request to the OsEventDriver node to subscribe to GPU decoding events. This request to subscribe to GPU decoding events can also be referred to as a third request.

[0175] The S104 OsEventDriver node sends a request to the graphics card driver to subscribe to GPU decoding events.

[0176] In other words, the audio and video status probe of the scene recognition engine can send a request to the graphics card driver to subscribe to GPU decoding events through the OsEventDriver node. Similarly, the OsEventDriver node can register a callback with the graphics card driver. The purpose of registering this callback is that when the graphics card driver monitors the GPU performing a decoding operation, it can return the GPU decoding event to the OsEventDriver node.

[0177] S105. The system probe module sends a request to the API module to subscribe to the focus window change event.

[0178] The API module may include a Windows user interface implemented by user32.dll, which can be used to create windows. In an alternative implementation, the system event probe of the system probe module may send a request to the Windows user interface of the API module to subscribe to focus window change events. This request to subscribe to focus window change events may also be referred to as a second request.

[0179] Similarly, the system event probe can register a callback with the API module. The purpose of registering this callback is to return the focus window change event to the system event probe when the API module (Windows user interface) detects a change in the focus window.

[0180] The focus window is the window that receives focus attention, and it's highly likely that the user is currently using it. Therefore, by monitoring the focus window, we can determine the user's needs. For example, if the focus window is a video application window, it indicates that the user needs to browse and play videos. Similarly, if the focus window is a game application window, it indicates that the user needs to play games. By monitoring whether the focus window changes, we can determine whether the user's needs have changed. For example, if the focus window changes from a video application window to a game application window, it indicates that the user's current need has changed from watching videos to playing games. In short, if the focus window changes, it means the user's needs have changed, and thus, the current user scenario has changed.

[0181] It should be noted that there is no strict order among S101, S103, and S105; they can be arranged in the following order: Figure 8The execution order shown can be sequential, simultaneous, or sequential, such as S103, S101, S105, S103, S105, S101, S105, S101, S103, or S105, S103, S101. Similarly, there is no strict order among S102, S104, and S106, as long as S102 is executed after S101, S104 after S103, and S106 after S105. No specific restrictions are imposed here.

[0182] After the system probe module has subscribed to various event requests, it can detect changes in the user scenario of the electronic device. The following description uses the example of the electronic device changing from an office scenario to a video scenario.

[0183] S106. In response to the received user action of starting the video application, the video application sends a process creation request to the process manager.

[0184] The process creation request includes the storage address of the video application.

[0185] Alternatively, video applications can send a process creation request to the process manager through the kernel32.dll and Ntdll.dll interfaces of the API module (not shown in the figure).

[0186] S107. The process manager creates a video application process.

[0187] Specifically, the process manager can locate the video application's binary file at the aforementioned storage address. By loading the video application's binary file, the environment for the process to run can be created, and the video application process can be started.

[0188] In the Windows operating system, an application's execution is defined as a process. A process can have multiple threads. A window is an instance of a window structure, a type of graphical user interface (GUI) resource. Windows are created by threads, and a thread can own all the windows it creates. In this embodiment, when an electronic device runs a video application, the process manager needs to create a process for that video application, namely the video application process (i.e., the first process). The video application process includes multiple threads, including thread 1. Thread 1 can be used to create the main window of the video application, which is a window that integrates all the function buttons of the video application.

[0189] S108. The process manager reports the process creation event to the OsEventDriver node.

[0190] The process creation event may include the name of the process created by the process manager. In this embodiment, the process name is the name of the video application process. Of course, if the process manager creates a process for another application, the process name will also correspond to the name of that other application's process.

[0191] As explained earlier, the OsEventDriver node sends a request to the process manager to subscribe to the process creation event and registers a callback. Therefore, the process manager can report the process creation event to the OsEventDriver node after creating the video application process.

[0192] S109 and OsEventDriver nodes report process creation events to the system probe module.

[0193] The description of the process creation event is shown in S108 and will not be repeated here.

[0194] In this embodiment of the application, the OsEventDriver node can report the process creation event to the system event probe of the system probe module.

[0195] S110, The system probe module sends a process creation event to the scene recognition module.

[0196] S111. In response to the call request from thread 1, the API module creates window 1.

[0197] After the process manager creates the video application process, thread 1 of the video application process actively calls the Windows user interface of the API module to create window 1. For example, as shown... Figure 9 As shown in (a), the electronic device can display window 101, which is an office interface. The electronic device can receive a user's click on the video application icon 102 on the desktop, and respond to the operation as follows: Figure 9 As shown in (b) above, the electronic device displays window 103 (i.e., window 1, or the first window). During the above process, the focus window changes from the original window 101 to window 103.

[0198] S112, The API module reports the focus window event to the system probe module.

[0199] In this embodiment, after the Windows user interface of the API module creates window 1, it can obtain the name of the first process (i.e., the focus process) and the name of the second process. The first process is the process corresponding to the current focus window (i.e., window 1), and the second process is the process corresponding to the previous focus window (e.g., window 2). For example, the process corresponding to window 1 is a video application process (the first process), and its name is, for example, hlive.exe. The process corresponding to window 2 is an office application process (the second process), and its name is, for example, word.exe. Since the names of the first and second processes are inconsistent, the API module determines that the focus window has changed and reports the focus window event to the system event probe of the system probe module. The focus window change event includes the name of the first process (i.e., the focus process). For example, the first process is the video application process, and the focus window change event carries the name of the video application process.

[0200] It should be noted that if the video application is already running on the electronic device, the electronic device does not need to execute S106 to S111. After the system probe module sends a request to the API module to subscribe to the focus window change event, if the user switches the focus window to the video application window, the API module can also detect the focus window change and report the focus window event to the system probe module.

[0201] S113, The system probe module sends a focus window event to the scene recognition module.

[0202] S114. The scene recognition module determines that the type of the first process is video.

[0203] Electronic devices can be pre-configured with an application list. The scene recognition module can query whether the first process is included in the application list. If the first process is included in the application list, the scene recognition module can determine the type of the first process. The application list includes the process name and application type of each application. For example, the application list can be shown in Table 1:

[0204] Table 1

[0205] video hlive.exe Video Word word.exe Office Shooting game shot.exe Games WeChat wechat.exe Social …… …… ……

[0206] For example, if the first process is named hlive.exe, the scene recognition module can determine that the first process belongs to the video category. As another example, if the first process is named wechat.exe, the scene recognition module can determine that the first process belongs to the social networking category. It should be noted that Table 1 above is only an example; in practice, Table 1 can include the process names and their respective types for many more applications.

[0207] It should be noted that the purpose of this step is to initially determine the user scenario in which the electronic device is located. The user scenario can include video scenarios, gaming scenarios, social networking scenarios, office scenarios, browser scenarios, etc. Among these, video scenarios can further include video playback scenarios and video browsing scenarios. Social networking scenarios can further include text chat scenarios, voice chat scenarios, and video chat scenarios. Office scenarios can further include document editing scenarios, document browsing scenarios, and video conferencing scenarios. Browser scenarios can include web browsing scenarios and video playback scenarios.

[0208] In this step, the type of user scenario the electronic device is in can be determined by the type of the first process. For example, if the first process is determined to be a video process, the electronic device is in a video scenario; similarly, if the first process is determined to be a game process, the electronic device is in a game scenario. Furthermore, since the names of the first and second processes are different, it can be determined that the user scenario of the electronic device has changed.

[0209] To further analyze user needs, the scene recognition module can also combine other parameters (such as peripheral events, GPU running status, etc.) to analyze the specific scene in which the electronic device is located, so as to achieve a more accurate analysis result. Continuing with the video scene as an example, the specific process can include:

[0210] S115. In response to the received user's request to play video, the video application sends a video playback instruction to the API module.

[0211] Specifically, video applications can send this video playback command to the DirectX API of the API module. This video playback command can include the cache address of the video.

[0212] S116, API module reads video files.

[0213] The API module can read the corresponding video file based on the cache address carried in the video playback command.

[0214] S117, the API module sends decoding commands to the graphics card driver.

[0215] S118, The graphics card driver sends a startup command to the GPU.

[0216] S119 and GPU perform decoding.

[0217] Specifically, the GPU can decode the video file using the GPU video processing engine.

[0218] S120, the GPU reports decoding events to the graphics card driver.

[0219] S121, The graphics card driver reports decoding events to the OsEventDriver node.

[0220] The S122 and OsEventDriver nodes report decoding events to the system probe module.

[0221] Specifically, the OsEventDriver node reports the decoding event to the audio and video status probe of the system probe module.

[0222] S123, The system probe module sends a decoding event to the scene recognition module.

[0223] S124, The scene recognition module sends instruction 1 to the system probe module.

[0224] Instruction 1 instructs the system probe module to obtain the GPU utilization of the first process. This instruction 1 may include the name of the first process.

[0225] S125, The system probe module sends a request to the process manager to obtain the GPU utilization of the first process.

[0226] The request to obtain the GPU utilization of the focused process may include the name of the first process.

[0227] In one alternative implementation, the audio / video status probe of the system probe module can send a request to the process manager to obtain the GPU utilization of the first process.

[0228] S126. The process manager collects the GPU usage of the first process.

[0229] Specifically, the process manager can collect the GPU usage of the first process through the graphics kernel interface of the graphics card driver.

[0230] S127. The process manager sends the GPU utilization of the first process to the system probe module.

[0231] The process manager can send the GPU utilization of the first process to the audio / video status probe of the system probe module.

[0232] S128, The system probe module sends the GPU utilization rate of the first process to the scene recognition engine.

[0233] S129. The scene recognition module determines whether the GPU utilization rate of the first process is greater than 0.

[0234] If the GPU utilization of the first process is greater than 0, then S130 is executed.

[0235] By measuring the GPU utilization of the first process, we can determine whether the first process is using the GPU during its operation. If the GPU utilization of the first process is greater than 0, it can be considered that the first process is using the GPU during its operation; if the GPU utilization of the first process is 0, it indicates that the first process is not using the GPU during its operation.

[0236] S130, The scene recognition module sends instruction 2 to the system probe module.

[0237] Instruction 2 instructs the system probe module to obtain the GPU engine of the first process. This instruction 2 may carry the name of the first process.

[0238] S131, The system probe module sends a request to the process manager to obtain the GPU engine of the first process.

[0239] Specifically, the audio / video status probe of the system probe module can send a request to the process manager to obtain the GPU engine of the first process. The request to obtain the GPU engine of the first process includes the name of the first process.

[0240] The GPU engine includes the GPU 3D engine, GPU copy engine, GPU video encoding engine, and GPU video processing engine. The GPU 3D engine is primarily responsible for processing 2D or 3D graphics. The GPU copy engine is mainly used for data transfer. The GPU video encoding engine is primarily used for encoding operations. The GPU video processing engine is primarily used for decoding operations. In some embodiments, the GPU video processing engine can be replaced by the GPU video decode engine.

[0241] S132, The process manager obtains the GPU engine of the first process.

[0242] Specifically, the process manager can obtain the GPU engine of the first process through the graphics kernel interface of the graphics card driver.

[0243] S133, The process manager sends message 1 to the system probe module, which indicates that the GPU engine of the first process is the GPU video processing engine.

[0244] Specifically, the process manager can send this message to the audio and video status probe of the system probe module, and then the audio and video status probe can forward the message to the scene recognition module.

[0245] S134, The system probe module sends message 1 to the scene recognition module.

[0246] S135, The scene recognition module determines whether the GPU engine of the first process is a GPU video processing engine.

[0247] If the GPU engine of the first process is a GPU video processing engine, then execute S136; if the GPU engine of the first process is not a GPU video processing engine, then execute S130.

[0248] In step S114, the scene recognition engine has determined that the first process belongs to the video category, thus confirming that the electronic device is in a video scene. Through step S135, the scene recognition engine can determine the specific operations performed by the first process via the GPU, thereby determining the specific operations the user is performing in the video application. For example, if the first process's GPU engine is a GPU video processing engine, it indicates that the first process is using the GPU for decoding operations, suggesting the user is playing a video in the video application. Conversely, if the first process's GPU engine is not a GPU video processing engine, it indicates that the first process is not using the GPU for decoding operations, meaning the user is likely browsing video resources in the video application and has not yet played the video.

[0249] S136. The scene recognition module determines the user scene as a video playback scene based on the process information of the first process.

[0250] The process information of the first process includes the name of the first process, the application type to which the first process belongs, the GPU utilization of the first process, and the GPU engine used by the first process.

[0251] Based on the above, if the first process (focus process) is of video type, the GPU utilization of the first process is greater than 0, and the GPU engine of the first process is a GPU video processing engine, then it can be determined that the electronic device is in a video playback scenario.

[0252] It should be noted that S101 to S136 above are only used as an example of a video playback scenario where the electronic device is in a video environment. In reality, the electronic device can also be in other user scenarios (e.g., gaming, office, social networking, video browsing, etc.).

[0253] In one alternative implementation, if the scene recognition engine determines that the type of the first process (focus process) is game-related, the CPU power mode changes to game mode, the GPU utilization of the first process is greater than 0, and the GPU engine of the first process is a GPU 3D engine, then the electronic device can be determined to be in a game scene.

[0254] The system probe module's power status probe can send a request to the power manager to subscribe to power mode change events. The power manager can report this power mode change event to the system probe module's power status probe when the power module switches to game mode. Thus, the scene recognition engine can determine whether the CPU's power mode is game mode through these power mode change events. Furthermore, the process by which the scene recognition engine obtains the type of the first process can be found in [link to documentation]. Figure 8 S101, S102, S105, and S106–S114 describe the process by which the scene recognition engine determines whether the GPU utilization of the first process is greater than 0 and whether the GPU engine of the first process is a GPU 3D engine. See S124–S135 for the details. The difference lies in replacing the video application with a game application, which will not be elaborated upon here.

[0255] In summary, after executing the above process, the electronic device can determine that the user scenario has changed from an office scenario to a video scenario, and can then execute the subsequent process of issuing scheduling strategies, which can be found later. Figure 10 The description.

[0256] For the processes from S11 "determine the corresponding CPU power scheduling strategy 1 based on the current user scenario" to S13 above, as follows: Figure 10 As shown, the process of electronic devices executing the dispatching strategy is as follows:

[0257] S301, The scene recognition module sends scene information to the basic scheduling strategy matching manager.

[0258] The scene information is used to indicate the user scene in which the electronic device is located. For example, the electronic device can pre-assign unique identifiers to different user scenes, and this scene information can include the unique identifier of the user scene. For instance, this identifier (e.g., scene number V01) could indicate that the electronic device is in a video playback scene. Or, for example, this identifier (e.g., scene number V02) could indicate that the electronic device is in a video browsing scene.

[0259] For details on the process by which the scene recognition module determines the user scene in which the electronic device is located, please refer to S101 to S136, and will not be repeated here.

[0260] S302, The basic strategy matching manager obtains scheduling strategy 1 based on the scenario information.

[0261] Among them, scheduling strategy 1 includes OS scheduling strategy 1 and CPU power consumption scheduling strategy 1. Scheduling strategy 1 can also be called the second scheduling strategy.

[0262] Optionally, OS scheduling policy 1 includes the first process priority and the first I / O priority. The first process priority measures its ability to preempt the CPU; the higher the priority, the more readily its CPU resource requirements can be met, resulting in smoother operation of the first process. In an optional implementation, the priorities of the focus process, from highest to lowest, include: real-time, high, above normal, normal, below normal, and low. The first process priority can also be understood as the focus process priority (FPP).

[0263] The I / O priority of the first process is used to measure the system's responsiveness to the disk and I / O requests of the first process. A higher priority results in a higher responsiveness, i.e., a faster response time. In one optional implementation, the focus process I / O priority, from highest to lowest, includes the following levels: critical, high, normal, low, and very low. The I / O priority of the first process can also be understood as the focus process I / O priority (FPP_IO).

[0264] Optionally, the CPU power scheduling strategy 1 includes the CPU's first PL1, first PL2, and first EPP.

[0265] As can be seen, scheduling strategy 1 can adjust the process priority, I / O priority, and CPU power consumption of the first process.

[0266] In one optional implementation, the electronic device can be pre-configured with various user scenarios and their corresponding scheduling strategies. For example, the correspondence between various user scenarios and their corresponding scheduling strategies can be shown in Table 2 below.

[0267] For example, if the user scenario of the electronic device is determined to be a text chat scenario within a social context, then scheduling strategy 1 includes: the first process priority of the first process is normal, the first I / O priority of the first process is normal, the first PL1 of the CPU is 12W, the first PL2 is 60W, and the first EPP is 220. It should be noted that the scheduling strategies in Table 2 are only examples; in actual applications, the values ​​of process priority, I / O priority, PL1, PL2, and EPP may differ from those in Table 2. Furthermore, Table 2 only shows scheduling strategies for some scenarios; actual electronic devices can be configured with more scheduling strategies than those shown in Table 2.

[0268] It should be noted that the above scheduling strategy is the default scheduling strategy when the electronic device is in a light-load state. It can pre-calculate the CPU power consumption of each application under the corresponding load characteristics and configure the strategy based on the statistically obtained load characteristics and CPU power consumption. Therefore, the scheduling strategy 1 obtained by the basic strategy matching manager can be used as a reference scheme for the electronic device to perform scheduling. The electronic device can also obtain the actual scheduling strategy based on the scheduling strategy 1 and the actual system load.

[0269] Table 2

[0270]

[0271] S303, The basic policy matching manager sends scheduling policy 1 to the scene recognition module.

[0272] S304. The scene recognition module sends scheduling strategy 1 and scene information to the load controller.

[0273] That is, after the basic policy matching manager determines scheduling policy 1, it forwards scheduling policy 1 to the load controller through the scenario identification module. In an optional implementation, the scenario identification module can send scheduling policy 1 and scenario information to the load controller in two steps.

[0274] S305, The load controller sends a request to the system probe module to obtain the system load.

[0275] System load is the average number of processes in a runnable state and processes in an uninterruptible state. Runnable processes are those that are using the CPU or waiting to use the CPU. Uninterruptible processes are those waiting for I / O access (e.g., disk I / O).

[0276] S306. The system probe module sends a request to the process manager to obtain the system load.

[0277] like Figure 4 As shown, the system probe module includes a system load probe, which can send a request to the process manager to obtain the system load. In an optional implementation, the OsEventDriver node can also forward the system load probe's request to obtain the system load to the process manager (not shown).

[0278] S307, Process Manager retrieves system load.

[0279] S308, the process manager sends the system load to the system probe module.

[0280] Specifically, the process manager can send the system load to the system load probe of the system probe module. In an alternative implementation, the system load can also be forwarded to the system load probe by the OsEventDriver node (not shown).

[0281] S309, The system probe module sends the system load to the load controller.

[0282] S310, the load controller obtains scheduling strategy 2 based on system load, scenario information and scheduling strategy 1.

[0283] Scheduling strategy 2 may include OS scheduling strategy 2 (also referred to as OS scheduling strategy) and CPU power consumption scheduling strategy 2 (also referred to as the first sub-strategy). CPU power consumption scheduling strategy 2 includes PL1', PL2', and EPP'. PL1' is the PL1 adjusted by the load controller, also referred to as the second PL1. PL2' is the PL2 adjusted by the load controller, also referred to as the second PL2. EPP' is the EPP adjusted by the load controller, also referred to as the second EPP. Scheduling strategy 2 may also be referred to as the first scheduling strategy.

[0284] In one alternative implementation, the load controller can classify the system load into three levels: light load, medium load, and heavy load. Electronic devices can be pre-configured with various user scenarios and their corresponding adjustment strategies. For example, the adjustment strategies can be as shown in Table 3:

[0285] Table 3

[0286]

[0287] For example, if the electronic device is in a video playback scenario, and according to Table 2, scheduling strategy 1 is: the process priority of the video application process is normal, the I / O priority of the video application process is normal, the CPU's PL1 (i.e., the first PL1) is 18W, PL2 (i.e., the first PL2) is 60W, and EPP (i.e., the first EPP) is 200. In this case, if the system load is light, no adjustment to the scheduling strategy is needed; that is, scheduling strategy 2 is the same as scheduling strategy 1. If the system load is medium, the process priority of the video application process and the I / O priority of the video application process must be kept normal. PL1 is increased by 22W from 18W, PL2 is increased by 30W from 60W, and EPP is decreased by 50 from 200. That is, scheduling strategy 2 is: the process priority of the video application process is normal, the I / O priority of the video application process is normal (OS scheduling strategy 2), PL1' is 40W, PL2' is 90W, and EPP' is 150 (CPU scheduling strategy 2). If the system load is heavy, the process priority of the video application process should be kept normal, and the I / O priority of the video application process should be adjusted to high. PL1 should be increased by 37W from 18W, PL2 should be increased by 45W from 60W, and EPP should be decreased by 100 from 200. That is, scheduling strategy 2 is: the process priority of the video application process is normal, the I / O priority of the video application process is high, PL1 is 55W, PL2 is 105W, and EPP is 100.

[0288] It should be noted that Table 3 only shows some user scenarios and their corresponding adjustment strategies. Electronic devices can be configured with more adjustment strategies than those in Table 3, and no specific restrictions are imposed here.

[0289] In one alternative implementation, the system load and CPU power consumption satisfy a specific mapping relationship (e.g., mapping through a specific formula). The load controller can also calculate the CPU power consumption through this specific formula and the system load, and then obtain scheduling policy 2.

[0290] After determining the above-mentioned scheduling strategy 2, the electronic device may optionally perform OS scheduling and CPU scheduling. The OS scheduling process can be referred to in S311 to S315 below, and the CPU scheduling process can be referred to in the following... Figure 11 The description process.

[0291] S311, The load controller sends OS scheduling policy 2 to the scheduler executor.

[0292] OS scheduling policy 2 includes the second process priority and the second I / O priority of the first process.

[0293] S312, The scheduler sends instruction 4 to the I / O manager.

[0294] Instruction 4 carries the second I / O priority of the first process. Additionally, by... Figure 4 As can be seen, the scheduler includes an I / O priority interface, through which instruction 4 can be sent to the I / O manager. This instruction 4 can also be referred to as the second instruction.

[0295] S313, In response to instruction 4, the I / O manager adjusts the I / O priority of the first process.

[0296] In other words, the I / O manager can adjust the I / O priority of the first process to the second I / O priority. This ensures that the first process can perform I / O access first, reducing the response time of the first process during I / O access.

[0297] S314, The scheduler sends instruction 5 to the process manager.

[0298] Instruction 5 carries the priority of the second process in the first process. Additionally, by... Figure 4 As can be seen, the scheduler also includes a process priority interface, through which instruction 5 can be sent to the process manager. This instruction 5 can also be referred to as the first instruction.

[0299] S315. In response to receiving instruction 5, the process manager adjusts the process priority of the first process.

[0300] In other words, the process manager can adjust the priority of the first process to that of the second process. This allows the first process to have priority access to CPU resources, ensuring its smooth operation.

[0301] As can be seen, by adjusting the I / O priority and process priority of the first process, the I / O access and CPU resource consumption of the first process can be prioritized, so that the first process can run normally and smoothly, ensuring a good user experience.

[0302] It should be noted that there is no strict order between S312 and S314. S312 can be executed first and then S314, or S314 can be executed first and then S312, or both S314 and S312 can be executed simultaneously.

[0303] For the processes S16-S18 above, as follows Figure 11 As shown, the process by which the electronic device translates and distributes CPU power scheduling policy 2 may include:

[0304] S321, the chip strategy fusion unit determines the CPU's chip platform type as follows: or

[0305] because The company's CPU chips and The companies' CPU chips use different methods to adjust CPU power consumption, so differentiation is necessary. Specifically, if the CPU chip platform type is... (Also known as the first type), then execute S322; if the PU's chip platform type is (Also known as the second type), then execute S329.

[0306] S322, the chip policy fusion unit sends CPU power consumption scheduling policy 2 to the scheduler executor.

[0307] Among them, CPU power consumption scheduling strategy 2 includes PL1`, PL2`, and EPP`.

[0308] S323, the scheduler sends instruction 6 to the OS2SOC driver node.

[0309] Instruction 6 carries PL1' and PL2'. That is, instruction 6 is used to instruct the CPU to adjust PL1 and PL2 according to PL1' and PL2'. Instruction 6 can also be called the third instruction.

[0310] In one alternative implementation, instruction 6 can be sent from the CPU power scheduling interface of the scheduler to the OS2SOC driver node.

[0311] S324, the OS2SOC driver node sends instruction 6 to the CPU.

[0312] S325, in response to instruction 6, the CPU adjusts PL1 and PL2.

[0313] That is, the CPU can adjust PL1 to PL1' and PL2 to PL2'.

[0314] S326, The scheduler sends instruction 7 to the power manager.

[0315] Instruction 7 carries EPP'. That is, instruction 7 is used to instruct the CPU to adjust EPP according to EPP'. Instruction 7 can also be called the fourth instruction.

[0316] S327, Power Manager sends instruction 7 to CPU.

[0317] S328, in response to instruction 7, the CPU adjusts the EPP.

[0318] In other words, the CPU can adjust EPP to EPP`.

[0319] S329, The chip strategy fusion unit determines the dynamic tuning technology strategy number based on CPU power consumption scheduling strategy 2.

[0320] Dynamic tuning technology (DTT) is The company processor and The technology automatically and dynamically allocates power consumption among discrete graphics cards to optimize performance and extend battery life, which can improve the performance of CPU and GPU and intelligently balance power for mixed workloads.

[0321] Understandably, there can be a mapping relationship between DTT policy numbers and CPU power scheduling policy 2. A DTT policy table is built in the BIOS, and any CPU power scheduling policy 2 can be mapped to a certain DTT policy number in the DTT policy table through its parameters (PL1', PL2', EPP'), as shown in Table 4.

[0322] The DTT strategy number identifies a DTT strategy (also known as a second sub-strategy). The DTT strategy corresponding to the DTT strategy number is used to adjust the CPU's PL1_MINI, PL1_MAX, PL2, PL2_TIME, and EPO Gear. PL1_MINI is the minimum value of PL1, PL1_MAX is the maximum value of PL1, and PL2_TIME is the duration of PL2. The energy performance optimize gear (EPO Gear) characterizes the degree to which DTT adjusts the CPU's energy efficiency ratio (EPP). Its value ranges from 1 to 5; a higher value indicates a greater emphasis on energy efficiency when adjusting EPP, while a lower value indicates a greater emphasis on performance.

[0323] Table 4

[0324]

[0325] It should be noted that Table 4 only shows a partial correspondence between PL1', PL2', EPP', and DTT policy numbers; in reality, it may include more information than Table 4. For example, if CPU power scheduling policy 2 indicates that PL1' is -1, PL2' is -1, and EPP' is -1, then the DTT policy number can be determined to be 0, with corresponding PL1_MINI being 30, PL1_MAX being 40, PL2 being 95, PL2_TIME being 28, and EPO Gear being 3.

[0326] S330, the chip policy fusion unit sends the DTT policy number to the scheduler executor.

[0327] In an alternative implementation, the chip policy fusion unit may also directly send the DTT policy (i.e., the second sub-policy) corresponding to the DTT policy number to the scheduler executor.

[0328] S331, The scheduler sends the DTT policy number to the Intel DTT driver.

[0329] It is understandable that the scheduler can send the DTT policy number to the Intel DTT driver via WMI.

[0330] S332, Intel DTT driver sends DTT policy number to CPU.

[0331] Understandably, this Intel DTT driver can send the DTT policy number to the CPU via the BIOS.

[0332] S333, CPU operates based on DTT policy number.

[0333] It can be seen that if the CPU chip platform type is The chip policy fusion unit can send instructions to the power manager to adjust the EPP via the scheduler executor, and the power manager can adjust the CPU's EPP. Additionally, the scheduler executor can also send instructions to the OS2SOC driver node to adjust PL1 and PL2, and the OS2SOC driver node drives the CPU's PL1 and PL2.

[0334] If the CPU chip platform type is The chip policy fusion unit can determine the DTT policy number of CPU power scheduling policy 2, and send the DTT policy number to the Intel DTT driver through the scheduler executor via the WMI plugin, so that the CPU runs based on the DTT policy number, thereby achieving the effect of adjusting power consumption.

[0335] In other words, the CPU no longer executes the preset scheduling policy at this time, but switches to the corresponding new scheduling policy.

[0336] In this embodiment, the electronic device can acquire a focus window change event and determine that the user scenario of the electronic device has changed based on the focus window change event. It then determines a first scheduling strategy by combining the current user scenario and the system load of the electronic device. Before issuing the first scheduling strategy, the electronic device first issues a preset scheduling strategy. Because this preset scheduling strategy can be directly executed by the CPU and is applicable to various user scenarios of the electronic device, the switching process when the electronic device switches from the preset scheduling strategy to the first scheduling strategy is relatively smooth, reducing the phenomenon of lag in the operation of the electronic device.

[0337] The foregoing has detailed examples of the resource scheduling method provided in the embodiments of this application. It is understood that, in order to achieve the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0338] This application embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into a separate functional module, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0339] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0340] The electronic device provided in this embodiment is used to execute the above-described resource scheduling method, and therefore can achieve the same effect as the above-described implementation method.

[0341] When using integrated units, the electronic device may further include a processing module, a storage module, and a communication module. The processing module is used to control and manage the operation of the electronic device. The storage module supports the execution of stored program code and data. The communication module supports communication between the electronic device and other devices.

[0342] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.

[0343] In one embodiment, when the processing module is a processor and the storage module is a memory, the electronic device involved in this embodiment can be a device having... Figure 2 The device with the structure shown.

[0344] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, causes the processor to perform the resource scheduling method of any of the above embodiments.

[0345] This application also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement the resource scheduling method described in the above embodiments.

[0346] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip, component or module. The apparatus may include a connected processor and a memory. The memory is used to store computer execution instructions. When the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the resource scheduling methods in the above-described method embodiments.

[0347] In this embodiment, the electronic device, computer-readable storage medium, computer program product or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0348] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0349] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0350] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0351] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0352] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0353] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A resource scheduling method, characterized in that, The method is performed by an electronic device, the electronic device including a CPU, and the method includes: In response to a click operation on the second window of the second application, the focus window is changed from the first window of the first application to the second window of the second application. Before the click operation on the second window of the second application, the first window is the focus window. When the first window is the focus window, the long-term turbo frequency power consumption PL1 of the CPU is a first value. The first application and the second application are different. The first value is used to support the operation of the first window. Based on the change of the focus window from the first window to the second window, the CPU's PL1 is adjusted to a second value, which is greater than the first value. The second value is used to support switching from running in the first window to running in the second window. After adjusting the CPU's PL1 to the second value, and when the focus window is the second window, the CPU's PL1 is adjusted to a third value, which is less than the second value, and the third value is used to support the operation of the second window.

2. The method according to claim 1, characterized in that, The CPU's chip platform supports Dynamic Tuning Technology (DTT).

3. The method according to claim 1, characterized in that, The step of adjusting the CPU's PL1 to a second value based on the change of the focus window from the first window to the second window includes: Based on the change of the focus window from the first window to the second window, if the third value is greater than the first value, the CPU's PL1 is adjusted to the second value.

4. The method according to claim 3, characterized in that, The method further includes: Based on the change of the focus window from the first window to the second window, if the third value is less than or equal to the first value, the CPU's PL1 will not be adjusted to the second value.

5. The method according to any one of claims 1 to 4, characterized in that, The step of adjusting the CPU's PL1 to a second value based on the change of the focus window from the first window to the second window includes: Upon receiving the click operation, it is determined that the user scenario corresponding to the second window is different from the user scenario corresponding to the first window; Obtain a preset scheduling strategy, in which the CPU's PL1 is the second value; Based on the preset scheduling strategy, the CPU's PL1 is adjusted to the second value.

6. The method according to claim 5, characterized in that, Before obtaining the preset scheduling strategy, the method further includes: The first scheduling strategy is determined based on the user scenario corresponding to the second window.

7. The method according to claim 6, characterized in that, The step of adjusting the CPU's PL1 to a third value after adjusting the CPU's PL1 to the second value, and when the focus window is the second window, includes: After adjusting the CPU's PL1 to the second value, and with the focus window being the second window, the CPU's PL1 is adjusted to the third value based on the first scheduling policy.

8. The method according to claim 7, characterized in that, The step of adjusting the CPU's PL1 to the third value based on the first scheduling policy includes: The first scheduling policy is translated, and the PL1 of the CPU is adjusted to the third value based on the translated first scheduling policy.

9. The method according to claim 8, characterized in that, The step of translating the first scheduling policy and adjusting the CPU's PL1 to the third value based on the translated first scheduling policy includes: The chip platform type of the CPU is determined, and the chip platform type includes a first type or a second type based on different manufacturers; When the chip platform type is the first type, the PL1 of the CPU is adjusted to the value of PL1 carried in the first scheduling policy, and the value of PL1 carried in the first scheduling policy is the third value. When the chip platform type is the second type, the Dynamic Tuning Technology (DTT) strategy number is determined according to the strategy parameters of the first scheduling strategy, and the PL1 of the CPU is adjusted to the third value according to the DTT strategy number.

10. The method according to any one of claims 6 to 9, characterized in that, The step of determining the first scheduling strategy based on the user scenario corresponding to the second window includes: The second scheduling strategy is determined based on the scenario identifier of the user scenario corresponding to the second window. The second scheduling strategy includes at least one strategy parameter among the CPU's first PL1, first short-term turbo power consumption PL2, and first energy efficiency ratio EPP. The first scheduling strategy is determined based on the second scheduling strategy, the scene identifier of the user scene corresponding to the second window, and the current system load of the electronic device. The first scheduling strategy includes at least one strategy parameter among the second PL1, second PL2, and second EPP of the CPU. When the system load is greater than a preset first value, the second PL1 is greater than the first PL1, the second PL2 is greater than the first PL2, and the second EPP is less than the first EPP.

11. The method according to claim 5, characterized in that, The step of determining that the user scenario corresponding to the second window is different from the user scenario corresponding to the first window includes: The process information and first information of the first process corresponding to the electronic device when the second window is launched are obtained. The first information includes at least one of the following: GPU usage information, peripheral event information or power mode information of the first process. The scene identifier of the user scene corresponding to the second window is determined based on the process information of the first process and the first information. If the scene identifier of the user scene corresponding to the second window is different from the scene identifier of the user scene corresponding to the first window, it is determined that the user scene corresponding to the second window is different from the user scene corresponding to the first window.

12. The method according to claim 1, characterized in that, The second value is 35w.

13. An electronic device, characterized in that, include: One or more processors; One or more memory units; The memory stores one or more programs that, when executed by the processor, cause the electronic device to perform the method as described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 12.

Images