CN116028206A

CN116028206A - Resource scheduling method, electronic equipment and storage medium

Info

Publication number: CN116028206A
Application number: CN202210609316.5A
Authority: CN
Inventors: 任书源; 相超
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-05-16
Filing date: 2022-05-31
Publication date: 2023-04-28

Abstract

The application provides a resource scheduling method, electronic equipment and a storage medium, and relates to the technical field of computers. According to the scheme, the corresponding scheduling strategy is determined according to the user scene and the system load of the electronic equipment, and the scheduling strategy is executed, so that the power consumption of the CPU can be reduced, the focus process preferentially occupies CPU resources and carries out I/O access, and the focus process can be ensured to run smoothly. That is, according to the load condition of the current task executed by the electronic device and the resource requirement of the user scene, more accurate resource scheduling can be dynamically performed on the current task, so that the smooth and non-blocking use experience is met, and the CPU power consumption is reduced. And moreover, the operation condition of the intelligent scheduling system is monitored in real time, and when the failure of the intelligent scheduling system is detected (for example, due to abnormal operation or termination of a user and the like), the intelligent scheduling system is automatically restored to a default scheduling strategy to perform resource scheduling, so that the problem of blocking of the electronic equipment in the using process is avoided.

Description

Resource scheduling method, electronic equipment and storage medium

The present application claims priority from the national intellectual property agency, application number 202210530375.3, application name "resource scheduling method and electronic device" filed on day 16 of month 2022, the entire contents of which are incorporated herein by reference.

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to a resource scheduling method, an electronic device, and a storage medium.

Background

With the improvement of the performance of the electronic device, the power consumption of the electronic device is higher, and the use experience of the user on the electronic device is higher. The use experience of the user can be satisfied through resource scheduling. In the resource scheduling process, when the problems of abnormal running, termination (forced killing and unloading) by a user and the like occur, the intelligent scheduling is invalid. Once the intelligent scheduling system fails, the intelligent scheduling system cannot recover from the adjustment of the CPU performance power consumption, and in this case, a jam may occur, and only the machine is restarted to recover, so that the user experience is greatly reduced.

Disclosure of Invention

The application provides a resource scheduling method, electronic equipment and a storage medium, which can monitor the running condition of an intelligent scheduling system in real time, and automatically restore a CPU scheduling strategy to a default scheduling strategy when detecting that the intelligent scheduling system fails (such as failure caused by abnormal running or termination by a user, etc.), so as to avoid the problem of blocking the electronic equipment in the using process.

In order to achieve the above purpose, the present application adopts the following technical scheme:

In a first aspect, the present application provides a resource scheduling method, applied to an electronic device, where the electronic device includes an intelligent scheduling system, a graphics processor GPU and a central processing unit CPU, the method includes:

responding to a first operation of a user, and displaying a first window by the electronic equipment, wherein the first window is a focus window; and acquiring process information and first information of a first process corresponding to the first window, wherein the first information comprises at least one of the following information: GPU occupation information, peripheral events or power mode information of the first process; determining a user scene where the electronic equipment is located according to the process information of the first process and the first information; obtaining a first scheduling strategy according to the system load of the electronic equipment and the user scene; adopting the first scheduling strategy to adjust the power consumption of the CPU, the process priority of the first process and the input/output I/O priority; and when detecting that the intelligent scheduling system is abnormal, adopting a default CPU power consumption scheduling strategy of the electronic equipment to adjust the power consumption of the CPU.

According to the method provided by the embodiment of the application, under the condition that the first operation is determined to enable the focus window to be changed into the first window (namely, the focus window is changed), the user scene (such as a video playing scene or a video browsing scene in a video scene, a document browsing scene, a document editing scene or a video conference scene in an office scene and the like) where the electronic equipment is located can be determined through the process information of the first process and the information of GPU occupation information, peripheral events, power mode information and the like of the first process. That is, the actual demand of the user in the process of using the electronic device can be determined, and the first scheduling policy is obtained by combining the actual demand of the user (i.e. user scene) and the actual running condition of the electronic device (i.e. system load), and by applying the first scheduling policy, the power consumption of the CPU can be reduced, and the first process can occupy CPU resources and perform I/O access preferentially, so that the first process can be ensured to run smoothly. And the operation condition of the intelligent scheduling system is monitored in real time, and when the failure of the intelligent scheduling system is monitored (for example, caused by abnormal operation or termination of users and the like), the operation is automatically recovered to a default scheduling strategy to perform resource scheduling, so that the problem of blocking of the electronic equipment in the use process is avoided.

Wherein the system load is the average number of processes in an executable state and processes in an uninterruptible state. The process in the runnable state refers to a process that is using or waiting for using a CPU. The process of the uninterruptible state is a process waiting for I/O access (e.g., disk I/O). The system load can be divided into three levels, namely light load, medium load and heavy load. The electronic device may be preconfigured with various user scenarios and scheduling policies corresponding to various system loads.

Wherein, under the first scheduling policy, the CPU may be adjusted to a high power consumption state or to a low power consumption state, depending on the user scenario and the system load. If the CPU is in a low power consumption state, when the intelligent scheduling system fails, if the user scene changes or the system load changes, the situation of insufficient CPU performance is likely to occur, and the phenomenon of stuck is likely to occur. Therefore, after the intelligent scheduling system is started, it is necessary to monitor whether the intelligent scheduling system operates normally in real time, and automatically recover to a default scheduling strategy to perform resource scheduling when the intelligent scheduling system fails, so as to avoid the problem of blocking of the electronic equipment in the use process.

It can be appreciated that, in the case where the CPU adopts the default scheduling policy, the CPU is generally adjusted to a high power consumption state, so that the electronic device can be prevented from being stuck when in various user scenarios or when different user scenarios are switched to some extent.

Illustratively, the default scheduling policy may be: long-term turbo power consumption pl1=35, short-term turbo power consumption pl2=80, and energy efficiency ratio epp=153. It should be noted that, for CPUs of different models or platforms, the corresponding default scheduling policies may be different, that is, the long-time Rui power consumption PL1, the short-time Rui power consumption PL2, and the energy efficiency ratio EPP may be determined specifically according to actual situations, which is not limited in the embodiments of the present application.

Specifically, for example, a first scheduling policy is employed in a text chat scenario: the long-time Rui frequency power consumption PL1=12, the short-time Rui frequency power consumption PL2=60 and the energy efficiency ratio EPP=220, and the CPU is in a low-power state after being scheduled by the intelligent scheduling system, so that smooth and non-jamming use experience is met. At this time, if the intelligent scheduling system fails, the failure of the intelligent scheduling system can be detected in time by detecting the heartbeat of the intelligent scheduling system, and the system automatically recovers to a default CPU power consumption scheduling strategy to perform resource scheduling: for example, long-time turbo power consumption pl1=35, short-time turbo power consumption pl2=80, and energy efficiency ratio epp=153. In this case, the CPU performance corresponding to the default CPU power consumption scheduling policy is higher than the CPU performance corresponding to the first scheduling policy. Thus, when the user scene or the system load may change, for example, the user scene is switched from the text chat scene to the game scene, the performance requirement of the game scene on the CPU is higher than that of the text chat scene, and at this time, the CPU is restored to the high power consumption state from the low power consumption state, so that the phenomenon of clamping in the game scene can be avoided.

In one possible design manner of the first aspect, the method further includes: starting an intelligent scheduling system; and judging whether the intelligent scheduling system is abnormal or not by carrying out periodic heartbeat detection on the intelligent scheduling system.

Optionally, when the electronic device is powered on and started, the electronic device automatically starts the intelligent scheduling system; or, in response to the triggering operation of the user, the electronic equipment starts the intelligent scheduling system.

In one possible design manner of the first aspect, the determining whether the intelligent scheduling system is abnormal by performing periodic heartbeat detection on the intelligent scheduling system includes: after the intelligent scheduling system is started, sending a heartbeat packet every a first period time length T; when the first timer is overtime and the heartbeat packet is not detected, judging that the intelligent scheduling system is abnormal; or when the first timer is not overtime and the heartbeat packet is detected, judging that the intelligent scheduling system is normal in operation; the first period duration T is smaller than or equal to the timing duration of the first timer.

In one possible design manner of the first aspect, the method further includes: in the event that the first timer does not timeout and a heartbeat packet is detected, the first timer is restarted.

In one possible design manner of the first aspect, the method further includes: stopping sending the heartbeat packet when the intelligent scheduling system has the first condition; wherein the first condition comprises any one of the following: the intelligent scheduling system is turned off; the intelligent scheduling system is offloaded; the intelligent scheduling system is disabled due to system crash during operation.

In one possible design manner of the first aspect, the electronic device further includes a basic input output system BIOS and a microcontroller EC. Wherein, through carrying out periodic heartbeat detection to intelligent scheduling system, judge whether the intelligent scheduling system takes place unusual, include: after the intelligent scheduling system is started, the intelligent scheduling system sends a heartbeat packet to the basic input/output system BIOS every a first period time T; in response to receiving the heartbeat packet, the BIOS judges that the intelligent scheduling system operates normally; the basic input/output system BIOS sends a notification message that the intelligent scheduling system operates normally to the microcontroller EC; in response to receiving the notification message, the microcontroller EC determines whether the first timer has been started; in the case that the first timer is started, the microcontroller EC judges whether the first timer is overtime; if the first timer is overtime, the microcontroller EC sends an overtime event to the basic input output system BIOS; in response to receiving the timeout event, the BIOS determines that the intelligent dispatch system is abnormal.

In one possible design manner of the first aspect, after the microcontroller EC determines whether the first timer has been started, the method further includes: in case the first timer is not started, the microcontroller EC controls the first timer to be started.

In one possible design manner of the first aspect, after the microcontroller EC determines whether the first timer has timed out, the method further includes: if the first timer does not time out, the microcontroller EC restarts the first timer. If the first timer does not time out when the notification message that the intelligent scheduling system operates normally is received, the first timer restarts to count time, and heartbeat detection is circularly performed.

Illustratively, the first transmission period T may be 30 seconds, and the timing duration of the first timer may be 35 seconds.

In one possible design manner of the first aspect, after the BIOS determines that the intelligent scheduling system is abnormal, the method further includes: the basic input output system BIOS adjusts the resource scheduling policy of the electronic device to a default CPU power consumption scheduling policy.

In one possible design manner of the first aspect, the BIOS adjusts a resource scheduling policy of the electronic device to a default CPU power consumption scheduling policy, including: the basic input output system BIOS acquires a first DTT strategy number for identifying a default CPU power consumption scheduling strategy from a preset DTT strategy table; the preset DTT policy table comprises a mapping relation between CPU power consumption scheduling parameters in a default CPU power consumption scheduling policy and a first DTT policy number.

In one possible design manner of the first aspect, the electronic device further includes a dynamic tuning technology DDT driver. After the BIOS adjusts the resource scheduling policy of the electronic device to the default CPU power consumption scheduling policy, the method further includes: the BIOS sends a first message to the DDT driver, wherein the first message indicates that the resource scheduling strategy is changed; in response to receiving the first message, the DDT driver sends a request to a Basic Input Output System (BIOS) to request to issue the latest resource scheduling policy; in response to receiving the request, the basic input output system BIOS issues a first DTT policy number to the DDT driver; in response to receiving the first DTT policy number, the DDT driver issues the first DTT policy number to the CPU.

In one possible design manner of the first aspect, adjusting power consumption of the CPU with a default CPU power consumption scheduling policy of the electronic device includes: in response to receiving the first DTT policy number, the CPU determines a corresponding default CPU power consumption scheduling policy according to the first DTT policy number; the CPU adjusts the power consumption of the CPU according to the CPU power consumption scheduling parameters in the default CPU power consumption scheduling strategy; wherein the CPU power consumption scheduling parameters include at least one of: default long-time-to-frequency power consumption, default short-time-to-frequency power consumption, and default energy efficiency ratio EPP of the CPU.

In one possible design manner of the first aspect, the first scheduling policy includes an optimized CPU power consumption scheduling policy and an optimized operating system OS scheduling policy. The method for adjusting the power consumption of the CPU, the process priority of the first process and the input/output I/O priority by adopting the first scheduling strategy comprises the following steps: adjusting the power consumption of the CPU according to the optimized CPU power consumption scheduling strategy; and adjusting the process priority and the I/O priority of the first process according to the optimized OS scheduling strategy.

In one possible design manner of the first aspect, the method further includes: when the intelligent scheduling system is detected to be abnormal, a default OS scheduling strategy of the electronic equipment is adopted to adjust the process priority and the input/output I/O priority of the first process.

In one possible design manner of the first aspect, before obtaining the first scheduling policy according to the system load and the user scenario, the method further includes: determining a second scheduling strategy according to a user scene, wherein the second scheduling strategy comprises a first process priority of a first process, a first input/output (I/O) priority, a first long-time-with-frequency power consumption (PL 1) of a CPU, a first short-time-with-frequency power consumption (PL 2) and a first energy efficiency ratio (EPP);

the method for obtaining the first scheduling policy according to the system load and the user scene comprises the following steps: obtaining a first scheduling policy according to the system load, the user scene and a second scheduling policy, wherein the first scheduling policy at least comprises a second process priority of a first process, a second I/O priority, a second PL1 of a CPU, a second PL2 and a second EPP; when the system load is larger than a preset first value, the second process priority is higher than or equal to the first process priority, the second I/O priority is higher than or equal to the first I/O priority, the second PL1 is larger than the first PL1, the second PL2 is larger than the second PL2, and the second EPP is smaller than the first EPP.

It can be understood that the higher the load, the higher the process priority and the I/O priority of the first process, so that the first process can be guaranteed to occupy the CPU resources and perform the I/O access preferentially, and the first process can be guaranteed to run smoothly. In addition, PL1, PL2 are appropriately increased and EPP is reduced when the load increases to balance the performance and power consumption of the electronic device.

Through the scheme, under the condition that the performance of the terminal equipment can smoothly meet the requirements of users, the energy consumption of the electronic equipment is reduced, and the cruising ability of the electronic equipment is improved.

In one possible design manner of the first aspect, the method further includes: the method comprises the steps of determining a chip platform type of a CPU, wherein the chip platform type comprises a first type and a second type. Wherein the first type of CPU may be

The second type of CPU may be +.>

Is provided.

In one possible design manner of the first aspect, the CPU power consumption scheduling policy includes a first sub-policy and a second sub-policy, where the second sub-policy is a dynamic tuning technology DTT policy determined according to the first sub-policy; adjusting the power consumption of the CPU according to the CPU power consumption scheduling strategy, including: if the chip platform type is the first type, adjusting the power consumption of the CPU according to the first sub-strategy; and if the chip platform type is the second type, adjusting the power consumption of the CPU according to the second sub-strategy. I.e. for

And->

The CPU of the power consumption scheduling method and the power consumption scheduling device can be adaptively matched with different power consumption scheduling strategies.

In one possible design manner of the first aspect, the GPU occupation information of the first process includes a GPU occupation rate of the first process and a GPU engine; determining a user scene where the electronic equipment is located according to the process information and the first information, including:

determining the type of the first process according to the process information; if the type of the first process is a video type, the GPU occupancy rate of the first process is greater than 0, the GPU engine is a GPU video process engine, and the user scene where the electronic is located is determined to be a video playing scene. It will be appreciated that if the type of first process is a video class, it may be determined first that the user is currently using a video class application. If the GPU occupancy rate of the first process is greater than 0, the condition that resources occupying the GPU exist in the running process of the first process is indicated. If the GPU engine of the first process is a GPU video processing (video process) engine, then this indicates that the first process uses the GPU for decoding operations during execution. Therefore, the user can be determined to play the video by using the electronic equipment with high probability, namely, the user scene where the electronic equipment is located is a video playing scene.

If the type of the first process is a video type, the GPU occupancy rate of the first process is larger than 0, the GPU engine is a GPU 3D engine, and the user scene where the electronic is located is determined to be a video browsing scene. Accordingly, if the GPU engine of the first process is a GPU 3D engine, it indicates that the first process uses only the GPU to perform 2D or 3D rendering operation, and it can be inferred that the user is browsing video resources using the electronic device, but not playing video, that is, the user scene where the electronic device is located is a video browsing scene.

In one possible design manner of the first aspect, the method further includes: if the type of the first process is a game type, the power mode is a game mode, the GPU occupancy rate of the first process is larger than 0, the GPU engine is a GPU 3D engine, and a user scene where the electronic is located is determined to be a game scene.

It will be appreciated that if the type of first process is a game class, it may be determined first that the user is currently using the game class application. If the GPU occupancy rate of the first process is greater than 0, the condition that resources occupying the GPU exist in the running process of the first process is indicated. If the GPU engine of the first process is a GPU 3D engine, the first process is indicated to use the GPU to perform 2D or 3D rendering operation. Thus, the user can be determined to play the game by using the electronic equipment with high probability, namely, the user scene where the electronic equipment is located is a game scene.

In one possible design manner of the first aspect, the peripheral event includes one or more of a keyboard input event, a mouse input event, a microphone input event, and a camera input event; determining a user scene where the electronic equipment is located according to the process information and the first information, including: and determining the type of the first process according to the process information.

If the type of the first process is social, and a keyboard input event is detected, determining that the user scene where the electronic is located is a text chat scene. That is, if it is detected that the user is using the social application and typing at the same time, the user is chatting using the social application with a high probability, and it can be determined that the user scene where the electronic is located is a text chatting scene.

If the type of the first process is social, a microphone input event is detected, a camera input event is not detected, and the user scene where the electronic is located is determined to be a voice chat scene. That is, if it is detected that the user is using the social application and is inputting voice at the same time, the user is highly likely to use the social application to perform voice chat, and it can be determined that the user scene where the electronic device is located is a voice chat scene.

If the type of the first process is social, detecting a microphone input event and a camera input event, and determining that a user scene where the electronic device is located is a video chat scene. That is, if it is detected that the user is using the social application and is inputting video at the same time, the user is using the social application to conduct video chat with a high probability, and it can be determined that the user scene where the electronic is located is a video chat scene.

In one possible design manner of the first aspect, the method further includes:

if the type of the first process is office type, and a keyboard input event is detected, determining that the user scene where the electronic device is located is a document editing scene. If the fact that the user is using the office application and typing is detected, the user is likely to edit the document by using the office application, and the user scene where the electronic device is located can be determined to be a document editing scene.

If the type of the first process is office type, detecting a mouse input event and not detecting a keyboard input event, and determining a user scene where the electronic device is located as a document browsing scene. That is, if it is detected that the user uses the mouse but does not use the keyboard in the process of using the office application, the user browses the document using the office application with a high probability, and it can be determined that the user scene where the electronic is located is a document browsing scene.

If the type of the first process is office type, detecting a microphone input event and a camera input event, and determining a user scene where the electronic device is located as a video conference scene. That is, if it is detected that the user uses the camera in the process of using the office application, the user performs the video conference using the office application with a high probability, and it can be determined that the user scene where the electronic device is located is a video conference scene.

In one possible design manner of the first aspect, the electronic device further includes a scene recognition engine, a system event driven oseeventdriver node, and a process manager, and the method further includes: the scene recognition engine sends a first request to an OsEventDriver node; the OsEventDriver node sends a first request to a process manager; responding to the first request, and after creating a second process, the process manager sends process information of the second process to the OsEventDriver node; the OsEventDriver node sends the process information of the second process to the scene recognition engine.

In one possible design manner of the first aspect, the electronic device further includes a scene recognition engine and an API module, and the method further includes: the scene recognition engine sends a second request to the API module; in response to the second request, the API module sends the process information of the first process to the scene recognition engine after detecting that the focus window changes.

In one possible design manner of the first aspect, the electronic device further includes a scene recognition engine, an oseeventdriver node, and a graphics card driver, and the method further includes: the scene recognition engine sends a third request to the OsEventDriver node; the OsEventDriver node sends a third request to the display card driver; responding to a third request, and reporting a GPU decoding event to an OsEventDriver node by the display card driver after detecting that the GPU performs decoding operation; the OsEventDriver node sends a GPU decoding event to the scene recognition engine.

In one possible design manner of the first aspect, the electronic device further includes a scene recognition engine, an oseeventdriver node, and a peripheral driver, and the method further includes: the scene recognition engine sends a fourth request to the OsEventDriver node; the OsEventDriver node sends a fourth request to the display card driver; responding to a fourth request, and reporting a peripheral event to the OsEventdriver node after the peripheral driver detects that the peripheral operation is performed; the OsEventDriver node sends a peripheral event to the scene recognition engine.

In one possible design manner of the first aspect, the method includes: responding to a first operation of a user, and acquiring a name of a first process and a name of a second process by an API module, wherein the second process is a process corresponding to a historical focus window; and if the name of the first process is inconsistent with the name of the second process, sending the process information of the first process to the scene recognition engine.

In one possible design manner of the first aspect, determining, according to the process information and the first information, a user scenario in which the electronic device is located includes: and the scene recognition engine determines a user scene where the electronic equipment is located according to the process information and the first information.

In one possible design manner of the first aspect, the electronic device further includes a scheduling engine, and the obtaining the scheduling policy according to the system load and the user scenario includes: the scene recognition engine determines a second scheduling strategy according to the user scene; the scene recognition engine sends a second scheduling strategy and a user scene to the scheduling engine; the scheduling engine sends a fifth request to the scene recognition engine; responding to the fifth request, the scene recognition engine acquires the system load and sends the system load to the scheduling engine; the scheduling engine obtains a first scheduling strategy according to the system load, the user scene and the second scheduling strategy.

In one possible design manner of the first aspect, the electronic device further includes a process manager and an I/O manager, the OS scheduling policy includes a second process priority and a second I/O priority of the first process, and the adjusting the process priority and the input/output I/O priority of the first process according to the OS scheduling policy includes: the scheduling engine sends a first instruction to the process manager, wherein the first instruction carries the second process priority of the first process; in response to receiving the first instruction, the process manager adjusts the process priority of the first process to a second process priority; the scheduling engine sends a second instruction to the I/O manager, wherein the second instruction carries a second I/O priority of the first process; in response to receiving the second instruction, the I/O manager adjusts the I/O priority of the first process to a second I/O priority.

In one possible design manner of the first aspect, determining a chip platform type of the CPU includes: the scheduling engine judges whether the chip platform type of the CPU is of a first type or a second type.

In one possible design manner of the first aspect, the electronic device further includes a power manager, a system and a chip OS2SOC driving node, the first sub-policy includes a second PL1, a second PL2 and a second EPP of the CPU, and the adjusting the power consumption of the CPU according to the first sub-policy includes: the scheduling engine sends a third instruction to the OS2SOC driving node, wherein the third instruction carries a second PL1 and a second PL2 of the CPU; the OS2SOC driving node sends a third instruction to the CPU; in response to the third instruction, the CPU adjusts PL1 to be the second PL1 and PL2 to be the second PL2; the scheduling engine sends a fourth instruction to the power manager, wherein the fourth instruction carries a second EPP of the CPU; the power manager sends a fourth instruction to the CPU; in response to the fourth instruction, the CPU adjusts the EPP to a second EPP.

In one possible design manner of the first aspect, the electronic device further includes an intel DTT driver, and adjusting the power consumption of the CPU according to the second sub-policy includes: the scheduling engine sends a fifth instruction to the Intel DTT driver, wherein the fifth instruction carries a second sub-strategy; the Intel DTT driver sends a fifth instruction to the CPU; in response to the fifth instruction, the CPU operates based on the second sub-policy.

Through the scheme, more accurate resource scheduling can be dynamically carried out on the current task according to the load condition of the current execution task of the electronic device and the resource requirement of a user scene, so that the smooth and non-blocking use experience is met, and meanwhile, the energy consumption of the electronic device is reduced.

In a second aspect, the present application provides a resource scheduling apparatus comprising means for performing the method of the first aspect described above. The apparatus may correspond to performing the method described in the first aspect, and the relevant descriptions of the units in the apparatus are referred to the description of the first aspect, which is omitted herein for brevity.

The method described in the first aspect may be implemented by hardware, or may be implemented by executing corresponding software by hardware. The hardware or software includes one or more modules or units corresponding to the functions described above. Such as a processing module or unit, a display module or unit, etc.

In a third aspect, the present application provides an electronic device comprising a memory and one or more processors; wherein the memory is for storing computer program code, the computer program code comprising computer instructions; the computer instructions, when executed by the processor, cause the electronic device to perform the method of any of the first aspects.

In a fourth aspect, the present application provides a computer-readable storage medium comprising computer instructions. When executed on an electronic device (e.g. a computer) the computer instructions cause the electronic device to perform the method as described in the first aspect and any one of its possible designs.

In a fifth aspect, the present application provides a computer program product which, when run on a computer, causes the computer to perform the method according to the first aspect and any one of its possible designs.

In a sixth aspect, the present application provides a chip system comprising one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected by a wire. The chip system described above may be applied to an electronic device including a communication module and a memory. The interface circuit is for receiving signals from a memory of the electronic device and transmitting the received signals to the processor, the signals including computer instructions stored in the memory. When executed by a processor, the electronic device may perform the method as described in the first aspect and any one of its possible designs.

It may be appreciated that the advantages achieved by the resource scheduling device according to the second aspect, the electronic device according to the third aspect, the computer readable storage medium according to the fourth aspect, the computer program product according to the fifth aspect and the chip system according to the sixth aspect provided above may refer to the advantages in any one of the possible designs of the first aspect and the second aspect, and will not be described herein again.

Drawings

Fig. 1 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a software module architecture according to an embodiment of the present application;

FIG. 3 is a schematic diagram illustrating interactions between software modules according to an embodiment of the present application;

fig. 4 is a schematic signal interaction diagram provided in an embodiment of the present application;

FIG. 5 is an interface diagram provided in an embodiment of the present application;

FIG. 6 is a schematic diagram of still another signal interaction provided in an embodiment of the present application;

fig. 7 is a schematic diagram of still another signal interaction provided in an embodiment of the present application;

FIG. 8 is a schematic diagram of a software module architecture according to an embodiment of the present application;

FIG. 9 is a schematic diagram of still another signal interaction provided in an embodiment of the present application;

fig. 10 is a schematic diagram of a chip structure according to an embodiment of the present application.

Detailed Description

For the purposes of making the objects, technical solutions and advantages of the embodiments of the present application more clear, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments.

The term "and/or" herein is an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. The symbol "/" herein indicates that the associated object is or is a relationship, e.g., A/B indicates A or B.

The terms "first," "second," and the like herein are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include one or more such feature. In the description of the present embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

For clarity and conciseness in the description of the embodiments below, a brief introduction to related concepts or technologies is first given:

A focus window (focus window) refers to a window having focus. The focus window is the only window that can receive keyboard input. The manner in which the focus window is determined is associated with the focus mode (focus mode) of the system. The top level window of the focus window is called an active window (active window). Only one window at a time may be an active window. The focus window is a window which is needed to be used by the user at present with high probability.

The focus mode may be used to determine how the mouse brings a window into focus. In general, the focus modes may include three types, respectively:

(1) Click-to-focus (click-to-focus) in this mode, the window that the mouse clicks on gets focus. I.e. when the mouse clicks on any position of a window where focus is available, the window is activated, placed in front of all windows and receives keyboard input. When the mouse clicks on other windows, the window loses focus.

(2) The focus follows the mouse (focus-mouse), in which mode a window under the mouse can acquire focus. I.e. when the mouse is moved to a range of windows where focus is available, the user does not need to click somewhere on the window to activate the window, receive keyboard input, but the window is not necessarily placed at the forefront of all windows. When the mouse moves out of the range of this window, this window will also lose focus.

(3) Grass-focus (slope focus), which is similar to focus-mouse comparison: when the mouse is moved to a window where focus is available, the user may activate the window without clicking somewhere on the window, receiving keyboard input, but the window is not necessarily positioned at the forefront of all windows. Unlike focus-focus, focus does not change when the mouse moves out of this window, but only when the mouse moves into another window that can receive focus.

A process includes multiple threads, which may create a window. The focus process is the process to which the thread that created the focus window belongs.

The long-time power consumption (PL 1) refers to the power consumption of the CPU under normal load, which is equivalent to the thermal design power consumption, and the running power consumption of the CPU for most of the time does not exceed PL1.

Short-time-with-frequency power consumption (PL 2), which refers to the highest power consumption that a CPU can reach in a short time, has a duration limit. Generally, PL2 is greater than PL1.

The CPU energy efficiency ratio (energy performance preference, EPP) is used for reflecting the scheduling trend of the CPU, and the value range is 0-255. The smaller the CPU energy efficiency ratio, the higher the CPU tends to be; the higher the CPU energy efficiency ratio, the lower the CPU trend.

The application layer can determine a user scene where the electronic device is currently located according to the focus window change event and the first information, determine a first scheduling policy according to the user scene and a system load of the electronic device, and adjust the process priority of the focus process, the I/O priority and the power consumption of the CPU based on the first scheduling policy, thereby reducing the energy consumption of the electronic device under the condition of smoothly meeting user requirements (ensuring the smooth operation of the focus process).

The resource scheduling method provided by the embodiment of the invention can monitor the running condition of the intelligent scheduling system in real time, and automatically restore the CPU scheduling strategy to the default scheduling strategy when detecting the failure of the intelligent scheduling system (for example, caused by abnormal running, termination by a user and the like), thereby avoiding the problem of blocking the electronic equipment in the using process.

Referring to fig. 1, a schematic structural diagram of an electronic device 100 according to an embodiment of the present application is provided.

As shown in fig. 1, the electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, wireless communication module 150, display screen 160, etc.

It is to be understood that the structure illustrated in the present embodiment does not constitute a specific limitation on the electronic apparatus 100. In other embodiments, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

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

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 100. In other embodiments, the electronic device 100 may also employ different interfaces in the above embodiments, or a combination of interfaces.

The charge management module 140 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display screen 160, the wireless communication module 150, and the like. In some embodiments, the power management module 141 and the charge management module 140 may also be provided in the same device.

The wireless communication module 150 may provide solutions for wireless communication including WLAN (e.g., wi-Fi), bluetooth, global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., applied to the electronic device 100. For example, in the embodiment of the present application, the electronic device 100 may establish a bluetooth connection with an electronic device (such as the wireless headset 100) through the wireless communication module 150.

The wireless communication module 150 may be one or more devices that integrate at least one communication processing module. The wireless communication module 150 receives electromagnetic waves via an antenna, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 150 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via an antenna.

The electronic device 100 implements display functions through a GPU, a display screen 160, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 160 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 160 is used to display images, videos, and the like. The display 160 includes a display panel.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 100. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121. For example, in an embodiment of the present application, the processor 110 may include a storage program area and a storage data area by executing instructions stored in the internal memory 121, and the internal memory 121 may include a storage program area and a storage data area.

The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The software system of the electronic device 100 may employ a layered architecture, an event driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the present application exemplifies a Windows system of a layered architecture, and illustrates a software structure of the electronic device 100.

Fig. 2 is a software architecture block diagram of the electronic device 100 according to the embodiment of the present application.

The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, windows systems are classified into a user mode and a kernel mode. The user mode comprises an application layer and a subsystem dynamic link library. The kernel mode is divided into a firmware layer, a hardware abstraction layer (hardware abstraction layer, HAL), a kernel and a driving layer and an executing body from bottom to top. The software architecture runs on a hardware layer of the electronic device, and the hardware layer can comprise a GPU, a CPU, a mouse, a microphone, a camera, a keyboard and the like.

As shown in FIG. 2, the application layer includes applications for music, video, games, office, social, etc. The application layer also comprises an environment subsystem and an intelligent scheduling system, wherein the intelligent scheduling system comprises a scene recognition engine, a scheduling engine and the like. Wherein only a part of application programs are shown in the figure, the application layer can also comprise other application programs, such as shopping application, browser and the like, and the application is not limited.

The environment subsystem may expose certain subsets of the basic executive services to the application in a particular modality, providing an execution environment for the application.

The scenario recognition engine may recognize a user scenario in which the electronic device 100 is located and determine a base scheduling policy (also referred to as a second scheduling policy) that matches the user scenario. The scheduling engine may obtain the load situation of the electronic device 100, and determine an actual scheduling policy (may also be referred to as a first scheduling policy) according to the actual operation situation of the electronic device 100 in combination with the load situation of the electronic device 100 and the basic scheduling policy. The specific contents of the scene recognition engine and the scheduling engine are described below, and are not described herein.

The subsystem dynamic link library includes an application program interface (application programming interface, API) module including Windows API, windows native API, and the like. The Windows API and the Windows native API can provide system call entry and internal function support for the application program, and the difference is that the Windows native API is an API native to the Windows system. For example, windows APIs may include user. Dll, kernel. Dll, and Windows native APIs may include ntdll. The user. Dll is a Windows user interface, and can be used for performing operations such as creating a window, sending a message, and the like. kernel. Dll is used to provide an interface for applications to access the kernel. ntdll.dll is an important Windows NT kernel-level file. When Windows is started, ntdll is resident in a specific write protection area in the memory, so that other programs cannot occupy the memory area.

The executives include a process manager, a virtual memory manager, a secure reference monitor, an I/O manager, windows management specifications (Windows management instrumentation, WMI), a power manager, a system event driver (operating system event driver) node, a system and chip driver (operating system to System on Chip, OS2 SOC) node, and the like.

The process manager is used to create and suspend processes and threads.

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

The security reference monitor may execute a security policy on the local computer that protects operating system resources, performs protection and monitoring of runtime objects.

The I/O manager performs device independent input/output and further processes call the appropriate device drivers.

The power manager may manage power state changes for all devices that support power state changes.

The system event driven node may interact with the kernel and the driver layer, for example, with a graphics card driver, and after determining that a GPU video decoding event exists, report the GPU video decoding event to the scene recognition engine.

The system and chip driver nodes may be configured for the scheduler engine to send adjustment information to the hardware device, e.g., to send adjustment PL1 and PL2 information to the CPU.

The kernel and driver layer includes a kernel and a device driver.

The kernel is an abstraction of the processor architecture, separates the difference between the executable and the processor architecture, and ensures the portability of the system. The kernel may perform thread scheduling and scheduling, trap handling and exception scheduling, interrupt handling and scheduling, etc.

The device driver operates in kernel mode as an interface between the I/O system and the associated hardware. The device drivers may include graphics card drivers, intel DTT drivers, mouse drivers, audio video drivers, camera drivers, keyboard drivers, and the like. For example, the graphics driver may drive the GPU to run and the Intel DTT driver may drive the CPU to run.

The HAL is a core state module, which can hide various details related to hardware, such as an I/O interface, an interrupt controller, a multiprocessor communication mechanism and the like, provide uniform service interfaces for different hardware platforms running Windows, and realize portability on various hardware platforms. It should be noted that, in order to maintain portability of Windows, the Windows internal components and the device driver written by the user do not directly access the hardware, but rather by calling the routine in the HAL.

The firmware layer may include a basic input output system (basic input output system, BIOS), which is a set of programs that are cured into a Read Only Memory (ROM) chip on the motherboard of the computer, which holds the most important basic input output programs, post-boot self-test programs, and system self-start programs of the computer, which can read and write specific information of the system settings from the complementary metal oxide semiconductor (complementary metal oxide semiconductor, CMOS). Its main function is to provide the lowest, most direct hardware setup and control for the computer. The Intel DTT driver may send instructions to the CPU via the BIOS.

It should be noted that, in the embodiment of the present application, only the Windows system is used as an example, and in other operating systems (such as an android system, an IOS system, etc.), the scheme of the present application can be implemented as long as the functions implemented by each functional module are similar to those of the embodiment of the present application.

Fig. 3 shows a schematic workflow diagram of software and hardware when the electronic device 100 schedules resources.

As shown in fig. 3, the application layer scene recognition engine includes a system probe module, a scene recognition module, and a base policy matching manager. The scene recognition module can interact with the system probe module and the basic policy matching manager respectively. The scene recognition module may send a request to the system probe module to obtain the probe status. The system probe module may acquire the operating state of the electronic device 100. For example, the system probe modules may include a power state probe, a peripheral state probe, a process load probe, an audio video state probe, a system load probe, a system event probe, and the like.

The power state probe may subscribe to a kernel state for a power state event, determine a power state according to a callback function fed back by the kernel state, where the power state includes a battery (remaining) power, a power mode, and the like, and the power mode may include an alternating current (alternating current, AC) power and a Direct Current (DC) power. For example, the power state probe may send a request to the oseeventdriver node of the executive layer to subscribe to a power state event, which is forwarded by the oseeventdriver node to the power manager of the executive layer. The power manager may feed back a callback function to the power state probe through the oseeventdriver node.

The peripheral state probe can subscribe a peripheral event to the kernel state, and the peripheral event is determined according to a callback function fed back by the kernel state. Peripheral events include mouse wheel slide events, mouse click events, keyboard input events, microphone input events, camera input events, and the like.

The process load probe may subscribe to the process load from kernel states and determine the load of the process (e.g., the first process) according to the callback function fed back from kernel states.

The system load probe can subscribe the system load to the kernel state, and the system load is determined according to a callback function fed back by the kernel state.

The audio and video status probe may subscribe to the kernel mode for audio and video events, and determine the audio and video events currently existing in the electronic device 100 according to the callback function fed back by the kernel mode. The audio video events may include GPU decoding events, and the like. For example, the audio/video status probe may send a request to the oseeventdriver node of the executive layer for subscribing to the GPU decoding event, and the oseeventdriver node forwards the request to the graphics card driver of the kernel and driver layer. The display card driver can monitor the state of the GPU, and after the GPU is monitored to perform decoding operation, callback functions are fed back to the audio and video state probes through the OsEventDriver node.

The system event probe can subscribe to the kernel state for system events, and the system events are determined according to a callback function fed back by the kernel state. The system events may include window change events, process creation events, thread creation events, and the like. For example, the system event probe may send a request to the oseeventdriver node executing the body layer to subscribe to a process creation event, which is forwarded by the oseeventdriver node to the process manager. The process manager can feed back a callback function to the system event probe through the OsEventDriver node after the process is created. For another example, the system event probe may also send a subscribe to focus window change event to the API module, which may monitor whether the focus window of the electronic device 100 has changed, and when it is monitored that the focus window has changed, feed back a callback function to the system event probe.

It can be seen that the system probe module subscribes to various events of the electronic device 100 from the kernel mode, and then determines the running state of the electronic device 100 according to the callback function fed back from the kernel mode, so as to obtain the probe state. After the system probe module obtains the probe state, the probe state can be fed back to the scene recognition module. After the scene recognition module receives the probe state, the scene recognition module can determine the user scene where the electronic device 100 is located according to the probe state. The user scene may include a video scene, a game scene, an office scene, a social scene, and the like. The user context may reflect the current use needs of the user. For example, when the scene recognition engine recognizes the focus window as a window of the video application, it determines that the electronic device 100 is in a video scene, which indicates that the user needs to view and browse the video using the video application. As another example, the scene recognition engine recognizes that the focus window is recognized as WeChat ^TM When determining that electronic device 100 is in a social context. The scene recognition module may also send the user scene to the base policy matching manager. The base policy matching manager may determine a base scheduling policy (which may also be referred to as a second scheduling policy, see for details the description in S301, S302 below) from the user scenario. Basic strategy The matching manager may feed back the base scheduling policy to the scene recognition module. The scene recognition module may send the base scheduling policy and the user scene to a scheduling engine of the application layer.

As shown in fig. 3, the scheduling engine includes a load manager, a chip policy aggregator, and a scheduling executor. The load management controller can receive the basic scheduling strategy and the user scene sent by the scene identification module. The load manager may also obtain the system load from the system probe module, and adjust the basic scheduling policy according to the system load and the user scenario, to obtain an actual scheduling policy (which may also be referred to as a first scheduling policy, see the description in S310 below for details). The actual scheduling policy includes an OS scheduling policy and a first CPU power consumption scheduling policy (which may also be referred to as a first sub-policy). The load manager may send the OS scheduling policy to the scheduling executor, and the scheduling executor may schedule based on the OS scheduling policy. The OS scheduling policy is used to adjust the process priority and I/O priority of the focal process. For example, the schedule executor may send an instruction to the process manager to adjust the process priority of the focal process, in response to which the process manager adjusts the process priority of the focal process. For another example, the scheduling executor may send an instruction to the I/O manager to adjust the I/O priority of the focal process, in response to which the I/O manager adjusts the I/O priority of the focal process.

The load manager may also send a first CPU power consumption scheduling policy to the chip policy aggregator, which may obtain a second CPU power consumption scheduling policy (also referred to as a second sub-policy, see the description in S317-S325 below) based on the chip platform type of the CPU and the first CPU power consumption scheduling policy. The chip platform types of the CPU are mainly divided into two types, namely

CPU and +.about.of (advanced micro devices, AMD)>

The two types of CPUs are not identical in the adjustment mode of CPU power consumption,and therefore a distinction is required. />

If the type of the chip platform of the CPU is AMD (also referred to as a first type), the scheduling executor may send an instruction to adjust EPP to the power manager to adjust EPP of the CPU. In addition, the schedule executor may also send instructions to the OS2SOC driving node to adjust PL1, PL2 to adjust PL1 and PL2 of the CPU.

If the chip platform type of the CPU is

The scheduling executor may send the second CPU power consumption scheduling policy to the Intel DTT driver through the WMI plug-in, where the second CPU power consumption scheduling policy may include a minimum value of PL1, a maximum value of PL1, durations of PL2 and PL2, and EPP, and the CPU is operated by the Intel DTT driver based on the second CPU power consumption scheduling policy.

The resource scheduling method provided by the embodiment of the application is mainly divided into two processes, namely: (1) determining a user scene in which the electronic device is located; (2) And carrying out resource scheduling according to the user scene where the electronic equipment is located and the system load of the electronic equipment. The above two processes will be respectively described below with reference to the drawings.

The following will take an example that the electronic device is in a video playing scene, and refer to fig. 4, to describe an interaction process of a part of modules in the electronic device shown in fig. 3. As shown in fig. 4, a flow of determining a user scenario where an electronic device is located in a resource scheduling method provided in an embodiment of the present application is as follows:

s101, a system probe module sends a request for subscribing a process creation event to an OsEventDriver node.

As shown in fig. 3, the scene recognition engine includes a system probe module that includes a system event probe. In the embodiment of the application, a request for subscribing to a process creation event can be sent by a system event probe to an oseeventdriver node located at an executable layer. Wherein the request to subscribe to a process creation event may also be referred to as a first request.

In an alternative embodiment, the request to subscribe to a process creation event may carry a process name. That is, the scene recognition engine may subscribe to only the creation events of the specified process, reducing interference of the creation events of irrelevant processes. For example, the specified process may be a process of a video application, a process of a game application, a process of an office application, a process of a social application, and so on. Of course, in other embodiments, the scenario recognition engine may not limit the subscribed process creation events.

S102, the OsEventDriver node sends a request for subscribing a process creation event to a process manager.

The request of the process creation event may refer to the description of S101, and will not be described herein.

That is, the system event probe of the scene recognition engine may send a request to subscribe to a process creation event to the process manager through the oseeventdriver node.

It will be appreciated that the oseeventdriver node registers a callback with the process manager, and the role of registering the callback is to return the process creation event to the oseeventdriver node after the process manager creates the process.

S103, the system probe module sends a request for subscribing the GPU decoding event to the OsEventDriver node.

As also shown in fig. 3, the system probe module further includes an audio-visual status probe. In the embodiment of the application, a request for subscribing the GPU decoding event can be sent to the oseeventdriver node by an audio/video status probe of the system probe module. Wherein, the request to subscribe to the GPU decode event may also be referred to as a third request.

S104, the OsEventdriver node sends a request for subscribing the GPU decoding event to the display card driver.

That is, the audio and video status probe of the scene recognition engine may send a request to subscribe to the GPU decoding event to the graphics card driver through the oseeventdriver node. Similarly, the oseeventdriver node may register a callback with the graphics card driver, where the role of registering the callback is to return the GPU decoding event to the oseeventdriver node after the graphics card driver monitors that the GPU performs the decoding operation.

S105, the system probe module sends a request for subscribing the focus window change event to the API module.

The API module may include a windows user interface implemented by user32.dll, which may be used to create a window. In an alternative embodiment, a request to subscribe to a focus window change event may be sent by a system event probe of the system probe module to a windows user interface of the API module. Wherein the request to subscribe to the focus window change event may also be referred to as a second request.

Likewise, the system event probe may register a callback with the API module, where the role of registering the callback is to return the focus window change event to the system event probe when the (windows user interface of the) API module monitors that the focus window has changed.

The focus window is a window with focus, and the high probability is a window which is needed to be used by a user currently. Thus, by monitoring the focus window, the user's need for use can be determined. For example, the focus window is a window of the video application, which indicates that the user needs to browse and play the video. As another example, the focus window is a window of a gaming application, indicating that the user desires to play a game. By monitoring whether the focus window changes, it can be determined whether the user's needs have changed. For example, the focus window changes from the window of the video application to the window of the game application, indicating that the user's current needs change from watching video to playing a game.

The above-mentioned steps S101, S103 and S105 are not strictly sequential, and may be sequentially performed in the order shown in fig. 4, or may be simultaneously performed, or may be sequentially performed in the order of S103, S101 and S105, sequentially performed in the order of S103, S105 and S101, sequentially performed in the order of S105, S101 and S103, or sequentially performed in the order of S105, S103 and S101. Accordingly, there is no strict order among S102, S104, and S106, as long as it is satisfied that S102 is performed after S101, S104 is performed after S103, and S106 is performed after S105, and no specific limitation is made herein.

S106, responding to the received operation of starting the video application by the user, and sending a process creation request to a process manager by the video application.

Wherein the creation process request includes a storage address of the video application.

The video application may send a request to create a process to a process manager (not shown) through the kernel32.Dll interface and the ntdll interface of the API module.

S107, the process manager creates a video application process.

Specifically, the process manager may query the binary file of the video application through the storage address. By loading the binary file of the video application program, a process running environment can be created, and the video application process is started.

Wherein the Windows operating system defines a run of an application as a process. A process may own multiple threads. A window is an example of a window structure, a graphical user interface (graphical user interface, GUI) resource, a window is created by a thread, and a thread can own all of the windows it creates. In the embodiment of the application, when the electronic device runs the video application, the process manager needs to create a process of the video application, namely, a video application process (namely, a first process). The video application process comprises a plurality of threads, the plurality of threads comprise a thread 1, the thread 1 can be used for creating a main window of the video application, and the main window is a window integrated with all function keys of the video application.

S108, the process manager reports a process creation event to the OsEventDriver node.

Wherein the process creation event may include a name of the process created by the process manager. In the embodiment of the present application, the name of the process is the name of the video application process. Of course, if the process manager creates a process of another application, the name of the process corresponds to the name of the process of the other application.

As already described above, the OsEventDriver node sends a request to the process manager to subscribe to a process creation event, and registers a callback. Therefore, the process manager can report a process creation event to the oseeventdriver node after creating the video application process.

S109, the OsEventDriver node reports a process creation event to the system probe module.

The description of the process creation event is S108, and is not described herein.

In this embodiment of the present application, the oseeventdriver node may report the process creation event to a system event probe of the system probe module.

S110, the system probe module reports the process creation event to the scene recognition module.

S111, responding to a call request of the thread 1, and creating the window 1 by the API module.

After the process manager creates the video application process, the thread 1 of the video application process actively calls the windows user interface creation window 1 of the API module. For example, as shown in fig. 5 (a), the electronic device may display a window 101, where the window 101 may be a desktop, and may also be referred to as a main interface. The window 101 includes an icon 102 of a video application. The electronic device may receive an operation in which the user clicks on the icon 102 of the video application, and in response to the operation, as shown in (b) of fig. 5, the electronic device displays a window 103 (i.e., window 1, which may also be referred to as a first window). In the above procedure, the focus window is changed from the original window 101 to the window 103.

S112, reporting a focus window event to the system probe module by the API module, wherein the focus window event carries the name of the first process.

In this embodiment of the present application, after creating window 1, the windows user interface of the API module may obtain the name of a first process (i.e. a focus process) and the name of a second process, where the first process is a process corresponding to a current focus window (i.e. window 1), and the second process is a process corresponding to a previous focus window (e.g. window 2). Illustratively, the process corresponding to the window 1 is a video application process (first process), the name of which is, for example, hlive. Exe, and the process corresponding to the window 2 is a process (second process) of a windows program manager, the name of which is, for example, explorer. Exe. And because the name of the first process is inconsistent with the name of the second process, the API module determines that the focus window changes, and reports a focus window event to a system event probe of the system probe module. Wherein the focus window change event includes the name of the first process (i.e., the focus process). Illustratively, the first process is a video application process, and the focus window change event carries a name of the video application process.

Note that, in the case where the electronic device has already started the video application, the electronic device may not execute S106 to S111. After the system probe module sends a request for subscribing the focus window change event to the API module, if the user switches the focus window to the window of the video application, the API module can also detect that the focus window changes and report the focus window event to the system probe module.

S113, the system probe module reports the focus window event to the scene recognition module.

S114, the scene recognition module determines that the type to which the first process belongs is a video type.

The electronic device may be preconfigured with an application list, and the scene recognition module may query whether the application list includes the first process. If the application list includes the first process, the scene recognition module may determine a type to which the first process belongs. The application list comprises the process name of each application and the type of the application. By way of example, the application list may be as shown in Table 1:

TABLE 1

Application of	Process name	Type(s)
			Glory video	hlive.exe	Video class
word	word.exe	Office class
			Shooting game	shot.exe	Game class
WeChat ^TM	wechat.exe	Social class
			……	……	……

For example, the name of the first process is hlive. Exe, the scene recognition module may determine that the type to which the first process belongs is a video class. For another example, the name of the first process is wechat. Exe, the scene recognition module may determine that the type to which the first process belongs is a social class. It should be noted that, table 1 is only used as an example, and in fact, table 1 may further include process names of more applications and types to which the process names belong.

It should be noted that the purpose of this step is to primarily determine the user scenario in which the electronic device is located. The user scene in which the electronic device is located may include a video scene, a game scene, a social scene, an office scene, a browser scene, and so forth. The video scene further comprises a video playing scene and a video browsing scene. The social scenes may further include text chat scenes, voice chat scenes, video chat scenes, and so on. The office scenes further may include document editing scenes, document browsing scenes, video conferencing scenes, and the like. The browser scene may include a browse web scene, a play video scene, and the like.

In this step, the type of the user scene where the electronic device is located may be determined by the type to which the first process belongs. For example, if the type to which the first process belongs is determined to be a video class, it may be determined that the electronic device is in a video scene; for another example, if it is determined that the type to which the first process belongs is a game class, it may be determined that the electronic device is in a game scene. In order to further analyze the user requirements, the scene recognition module may further analyze the specific scene where the electronic device is located by combining other parameters (such as a peripheral event, a GPU running state, etc.), so as to achieve an effect that the analysis result is more accurate, and the specific content is described in the following text.

S115, in response to receiving the operation of playing the video by the user, the video application sends a video playing instruction to the API module.

Specifically, the video application may send the video play instruction to the DirectX API of the API module. The video play instruction may include a cache address of the video.

S116, the API module reads the video file.

The API module can read the corresponding video file according to the cache address carried in the video playing instruction.

S117, the API module sends a decoding instruction to the display card driver.

S118, the display card drives to send a starting instruction to the GPU.

S119, the GPU decodes.

Specifically, the GPU may perform decoding operations on the video file through the GPU video processing engine.

S120, the GPU reports the decoding event to the display card driver.

S121, the display card driver reports the decoding event to the OsEventDriver node.

S122, the OsEventDriver node reports the decoding event to the system probe module.

Specifically, the oseeventdriver node reports the decoding event to an audio/video status probe of the system probe module.

S123, the system probe module sends a decoding event to the scene recognition module.

S124, the scene recognition module sends an instruction 1 to the system probe module.

The instruction 1 indicates the system probe module to acquire the GPU occupancy rate of the first process. The instruction 1 may carry the name of the first process.

S125, the system probe module sends a request for acquiring the GPU occupancy rate of the first process to the process manager.

Wherein the request for obtaining the GPU occupancy of the focal process may include the name of the first process.

In an alternative embodiment, a request to obtain the GPU occupancy of the first process may be sent by an audio video status probe of the system probe module to the process manager.

S126, the process manager collects the GPU occupancy rate of the first process.

Specifically, the process manager may collect the GPU occupancy rate of the first process through a graphics kernel (graphics kernel) interface driven by a graphics card.

S127, the process manager sends the GPU occupancy rate of the first process to the system probe module.

The process manager may send the GPU occupancy of the first process to the audio-video status probe of the system probe module.

S128, the system probe module sends the GPU occupancy rate of the first process to the scene recognition engine.

S129, the scene recognition module judges whether the GPU occupancy rate of the first process is larger than 0.

If the GPU occupancy rate of the first process is greater than 0, S130 is executed.

Whether the first process uses the GPU in the running process can be determined through the GPU occupancy rate of the first process, and if the GPU occupancy rate of the first process is greater than 0, the first process can be considered to use the GPU in the running process; if the GPU occupancy rate of the first process is 0, the first process is indicated to not use the GPU in the running process.

S130, the scene recognition module sends an instruction 2 to the system probe module.

Wherein instruction 2 instructs the system probe module to acquire the GPU engine of the first process. The instruction 2 may carry the name of the first process.

S131, the system probe module sends a request for acquiring the GPU engine of the first process to the process manager.

The audio and video status probe of the system probe module can send a request for acquiring the GPU engine of the first process to the process manager. The request to acquire the GPU engine of the first process includes the name of the first process.

The GPU engines comprise a GPU 3D engine, a GPU copy engine, a GPU video encoding engine and a GPU video processing engine. Wherein the GPU 3D engine is mainly responsible for processing 2D or 3D graphics. The GPU copy engine is mainly used for transmitting data. The GPU video encoding engine is mainly used for encoding operation. The GPU video processing engine performs mainly decoding operations. In some embodiments, the GPU video processing engine may also be replaced by a GPU video decoder engine.

S132, the process manager acquires the GPU engine of the first process.

Specifically, the process manager may obtain the GPU engine of the first process through a graphics kernel interface driven by a graphics card.

S133, the process manager sends a message 1 to the system probe module, wherein the message 1 indicates that the GPU engine of the first process is a GPU video processing engine.

Specifically, the process manager may send the message to an audio/video status probe of the system probe module, and then forward the message to the scene recognition module by the audio/video status.

S134, the system probe module sends a message 1 to the scene recognition module.

S135, the scene recognition module judges whether the GPU engine of the first process is a GPU video processing engine.

If the GPU engine of the first process is GPU video processing engine, then execute S129; if the GPU engine of the first process is not GPU video processing engine, then S130 is executed.

In step S114, the scene recognition engine has determined that the type to which the first process belongs is a video class, i.e. that the electronic device is in a video scene. Through step S135, the scene recognition engine may determine a specific operation performed by the first process through the GPU, and further determine a specific operation of the user using the video application. For example, if the GPU engine of the first process is GPU video processing engine, indicating that the first process is using the GPU for decoding operations, the user may be considered to be playing video using the video application. For another example, if the GPU engine of the first process is not GPU video processing engine, it indicates that the first process is not using the GPU for decoding operations, then the user has a high probability of browsing video resources on the video application, and not yet playing video.

S136, the scene recognition module determines that the user scene is a video playing scene according to the process information of the first process.

The process information of the first process comprises information such as the name of the first process, the application type to which the first process belongs, the GPU occupancy rate of the first process, and a GPU engine used by the first process.

From the above, it can be seen that if the type of the first process (the focus process) is a video type, the GPU occupancy rate of the first process is greater than 0, and the GPU engine of the first process is a GPU video processing engine, it can be determined that the electronic device is in a video playing scene.

The above S101 to S136 are described only by taking a video playing scene in which the electronic device is in a video scene as an example. Indeed, the electronic device may also be in other user scenes (e.g., gaming scenes, office scenes, social scenes, video browsing scenes, etc.).

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to the game class, the power mode of the CPU is changed to the game mode (game mode), the GPU occupancy rate of the first process is greater than 0, and the GPU engine of the first process is a GPU 3D engine, it may be determined that the electronic device is in the game scene.

Wherein the power state probes of the system probe module may send a request to the power manager to subscribe to a power mode change event. The power manager may report the power mode change event to a power state probe of the system probe module when the power module transitions to a game mode (game mode). As such, the scene recognition engine can determine whether the power mode of the CPU is a game mode through the power mode change event.

In addition, the process of the scene recognition engine obtaining the type of the first process may refer to S101, S102, S105, S106 to S114 in fig. 4, and the process of the scene recognition engine determining whether the GPU occupancy rate of the first process is greater than 0 and whether the GPU engine of the first process is a GPU 3D engine refers to S124 to S135. The difference is that the video application is replaced with a game application, and the description thereof is omitted.

Next, a flow of determining a user scenario where the electronic device is located when the electronic device is in an office scenario will be briefly described with reference to fig. 6. It should be noted that, the principle and flow of the flowchart shown in fig. 6 and the flowchart shown in fig. 4 are basically detailed, and only the differences between the two are specifically described below, and the details of the differences are not described in detail, and refer to the description of the related steps in fig. 4. Fig. 6 shows a flow of determining a user scenario where an electronic device is located according to a resource scheduling method provided in an embodiment of the present application as follows:

s201, a system probe module sends a request for subscribing a process creation event to an OsEventDriver node.

S202, the OsEventDriver node sends a request for subscribing a process creation event to a process manager.

S203, the system probe module sends a request for subscribing the peripheral event to the OsEventDriver node.

As shown in fig. 3, the system probe module further includes a peripheral status probe. In the embodiment of the application, a peripheral status probe of the system probe module can send a request for subscribing a peripheral event to the OsEventDriver node. Wherein the request to subscribe to a peripheral event may also be referred to as a fourth request.

The external events comprise mouse wheel sliding, mouse clicking, keyboard input, camera input, microphone input and the like.

S204, the OsEventDriver node sends a request for subscribing the peripheral event to the peripheral driver.

The peripheral driver is a generic term for driving all peripheral devices, and may include, for example, a mouse driver, a keyboard driver, a camera driver, a microphone driver, and the like.

S205, the system probe module sends a request for subscribing to the focus window change event to the API module.

S206, responding to the operation of receiving the opening of the office application by the user, and sending a request for creating the office application process to the process manager by the office application.

Wherein the request to create the office application process may include a storage address of the office application program.

S207, the process manager creates an office application process.

Specifically, the process manager may query the binary file of the office application through the storage address. By loading the binary file of the office application program, a process running environment can be created, and the office application process is started. In addition, the office application process includes thread 2, thread 2 being available to create a main window of the office application.

S208, the process manager reports a process creation event to the OsEventDriver node.

S209, the OsEventDriver node reports a process creation event to the system probe module.

Wherein the process creation event carries the name of the office application process.

S210, the system probe module sends a process creation event to the scene recognition module.

S211, responding to the call request of the thread 2, and creating an office application window by the API module.

S212, reporting a focus window event to the system probe module by the API module.

The focus window event carries the name of the first process (focus process). It can be appreciated that in the embodiment of the present application, the first process is an office application process.

S213, the system probe module sends a focus window event to the scene recognition module.

S214, the scene recognition module determines that the type to which the first process belongs is an office class.

For example, the name of the first process is word. Exe, it may be determined that the type to which the first process belongs is an office class.

S215, responding to the operation of the user on the peripheral, and detecting a peripheral event by the peripheral driver.

S216, the peripheral driver reports the peripheral event to the OsEventdriver node.

S217, the OsEventDriver node sends a peripheral event to the system probe module.

S218, the system probe module sends a peripheral event to the scene recognition module.

S219, the scene recognition module determines a user scene according to the type of the peripheral event and the first process.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to an office class and the peripheral event is a mouse wheel sliding event or a clicking event, it may be determined that the electronic device is specifically in a document browsing scene under the office scene. Or if the scene recognition engine determines that the type of the first process (focus process) belongs to an office class and does not receive the mouse wheel sliding event, the mouse click event and the keyboard input event again within a preset time (for example, 10 seconds) after receiving the keyboard input event, it may be determined that the electronic device is specifically located in a document browsing scene under the office scene.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to an office class and receives a keyboard input event, it may determine that the electronic device is specifically in a document editing scene in the office scene.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to an office class and receives a camera input event (i.e., the camera is in an on state and there is a video stream input), it may be determined that the electronic device is specifically in a video conference scene under the office scene.

The electronic device may also be in a social context. The social scene comprises three specific scenes, namely: text chat scene, voice chat scene and video chat scene. The principle of judging that the electronic device is in the social scene is similar to the principle of judging that the electronic device is in the office scene, and is not described herein, and only the conditions which need to be met when judging that the electronic device is in the social scene are described below.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to the social class and receives the keyboard input event, it may determine that the electronic device is specifically in a text chat scene under the social scene.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to the social class, and the microphone input event is received and the camera is in the off state, it may be determined that the electronic device is specifically in a voice chat scene under the social scene.

In an alternative embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to the social class and receives a microphone input event and a camera input event, it may determine that the electronic device is specifically in a video chat scene under the social scene.

The above description illustrates how to identify the user scene where the electronic device is located, after determining the user scene where the electronic device is located, the electronic device may further perform resource scheduling according to the user scene where the electronic device is located and the system load, so that the CPU of the electronic device may operate according to the actual requirement of the user, and the effect of avoiding the CPU from having excessive performance under the condition of not affecting the user experience is achieved.

Next, the resource scheduling process of the electronic device is described by taking the electronic device in a video playing scene as an example. As shown in fig. 7, a resource scheduling method provided in the embodiment of the present application includes the following steps:

as shown in fig. 7, the resource scheduling method provided in the embodiment of the present application further includes:

s301, the scene recognition module sends scene information to the basic scheduling policy matching manager.

The scene information is used for indicating a user scene where the electronic equipment is located. For example, the electronic device may pre-assign unique identifiers to different user scenarios, and the scenario information may include the unique identifiers of the user scenarios. For example, the identification (e.g., V01) may indicate that the electronic device is in a video playback scene. For another example, the identification (e.g., V02) may indicate that the electronic device is in a video browsing scenario.

Regarding the process of determining the user scene where the electronic device is located by the scene recognition module, refer to S101 to S136 specifically, and are not described herein again.

S302, the basic strategy matching manager obtains a scheduling strategy 1 according to the scene information.

The scheduling policy 1 includes an OS scheduling policy 1 and a CPU power consumption scheduling policy 1. The OS scheduling policy 1 includes a first process priority and a first I/O priority of a first process. Wherein the scheduling policy 1 may also be referred to as a second scheduling policy.

The priority of the first process is used for measuring the capability of the first process to preempt the CPU, and the higher the priority is, the higher the first process can preferentially meet the occupation requirement of the first process on CPU resources, so that the higher the running smoothness of the first process is. In an alternative embodiment, the priority of the focal process includes, in order from high to low, the level: real-time, high, above normal, below normal, low. The priority of the first process can also be understood as the focal process priority (focus process priority, FPP).

The I/O priority of the first process is used for measuring the responsiveness of the system to the disk and the I/O request of the first process, and the higher the priority is, the higher the responsiveness of the disk and the I/O request of the first process is, namely the faster the response speed is. In an alternative embodiment, the focal process I/O priority includes, in order from high to low, the levels of: critical, high, normal, low, very low. The I/O priority of the first process can also be understood as the focal process I/O priority (focus process IO priority, FPP_IO).

The CPU power consumption scheduling policy 1 includes a first PL1, a first PL2, and a first EPP of the CPU.

It can be seen that the scheduling policy 1 may adjust the process priority, the I/O priority and the CPU power consumption of the first process.

In an alternative embodiment, the electronic device may be preconfigured with various user scenarios and their corresponding scheduling policies. For example, the correspondence between various user scenarios and their corresponding scheduling policies may be as shown in table 2.

For example, if it is determined that the user scenario in which the electronic device is located is a text chat scenario in a social scenario, the scheduling policy 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 policy in table 2 is only an example, and in practical application, the values of the process priority, the I/O priority, PL1, PL2, and EPP may not coincide with the values in table 2. In addition, table 2 only shows the scheduling policies of a partial scenario, and the actual electronic device may also configure more scheduling policies than table 2.

It should be noted that, the above scheduling policy is a scheduling policy when the default electronic device is in a light load state, and may be configured according to the load characteristics and the CPU power consumption obtained by statistics, where the CPU power consumption of each application under the corresponding load characteristics is counted in advance for the electronic device. Therefore, the scheduling policy 1 obtained by the basic policy matching manager can be used as a reference scheme of a policy for scheduling by the electronic equipment, and the electronic equipment can also obtain an actual scheduling policy according to the scheduling policy 1 and combining with an actual system load.

TABLE 2

S303, the basic policy matching manager sends the scheduling policy 1 to the scene recognition module.

S304, the scene recognition module sends the scheduling strategy 1 and scene information to the load controller.

That is, after the base policy matching manager determines the scheduling policy 1, the scheduling policy 1 is forwarded to the load manager through the scene recognition module. In an alternative embodiment, the scenario recognition module may send the scheduling policy 1 and the scenario information to the load manager in two steps, respectively.

S305, the load controller sends a request for acquiring the system load to the system probe module.

Wherein the system load is the average number of processes in an executable state and processes in an uninterruptible state. The process in the runnable state refers to a process that is using or waiting for using a CPU. The process of the uninterruptible state is a process waiting for I/O access (e.g., disk I/O).

S306, the system probe module sends a request for acquiring the system load to the process manager.

As shown in fig. 3, the system probe module includes a system load probe, and a request to acquire a system load may be sent by the system load probe to the process manager. In an alternative embodiment, the oseeventdriver node may also forward a request to the process manager to acquire the system load of the system load probe (not shown in fig. 3).

S307, the process manager acquires the system load.

S308, the process manager sends a system load to the system probe module.

In particular, the process manager may send the system load to a system load probe of the system probe module. In an alternative embodiment, the system load may also be forwarded by the oseeventdriver node to a system load probe (not shown).

S309, the system probe module sends the system load to the load controller.

And S310, the load controller obtains a scheduling strategy 2 according to the system load, the scene information and the scheduling strategy 1.

Scheduling policy 2 may include an OS scheduling policy 2 (may also be referred to as an OS scheduling policy) and a CPU power consumption scheduling policy 2 (may also be referred to as a first sub-policy). The CPU power consumption scheduling policy 2 includes PL1 ', PL 2', EPP ', and PL 1' is PL1 adjusted by the load manager, and may also be referred to as second PL1.PL 2' is the load regulator adjusted PL2 and may also be referred to as a second PL2. EPP' is the EPP adjusted by the load controller and may also be referred to as the second EPP. Wherein the scheduling policy 2 may also be referred to as a first scheduling policy.

In an alternative embodiment, the load manager may divide the system load into three levels, light load, medium load, heavy load, respectively. The electronic device may be preconfigured with various user scenarios and adjustment policies corresponding to the system load. For example, the adjustment strategy may be as shown in table 3:

TABLE 3 Table 3

For example, if the electronic device is in a video playing scene, and according to table 2, it can be known that the scheduling policy 1 is: the process priority of the video application process is normal, the I/O priority of the video application process is normal, PL1 (i.e., first PL 1) of the CPU is 18W, PL2 (i.e., first PL 2) is 60W, and EPP (i.e., first EPP) is 200. In this case, if the system load is a light load, there is no need to adjust the scheduling policy, that is, the scheduling policy 2 is the scheduling policy 1. If the system load is a medium load, the process priority of the video application process needs to be kept normal, the I/O priority of the video application process is normal, PL1 is increased by 22W on the basis of 18W, PL2 is increased by 30W on the basis of 60W, epp is decreased by 50 on the basis of 200, i.e. the scheduling policy 2 is: the video application process has normal process priority, the video application process has normal I/O priority (OS scheduling policy 2), PL1 ' 40W, PL2 ' 90W, and EPP ' 150 (CPU scheduling policy 2). If the system load is heavy, the process priority of the video application process needs to be kept normal, the I/O priority of the video application process is adjusted to be high, PL1 is increased by 37W on the basis of 18W, PL2 is increased by 45W on the basis of 60W, EPP is reduced by 100 on the basis of 200, namely the 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.

It should be noted that, table 3 only shows a part of user scenes and corresponding adjustment policies, and the electronic device may further configure more adjustment policies than table 3, which is not limited herein.

In an alternative embodiment, the specific mapping relationship (for example, mapping is performed by a specific formula) is satisfied between the system load and the CPU power consumption, and the load controller may also calculate the CPU power consumption by using the specific formula and the system load, so as to obtain the scheduling policy 2.

S311, the load management controller sends the OS scheduling strategy 2 to the scheduling executor.

The OS scheduling policy 2 includes a second process priority of the first process and a second I/O priority.

S312, the scheduling executor sends an instruction 1 to the I/O manager.

Wherein instruction 1 carries the second I/O priority of the first process. In addition, as shown in FIG. 3, the dispatch executor includes an I/O priority interface from which instruction 1 may be sent to the I/O manager. Wherein this instruction 1 may also be referred to as a second instruction.

S313, in response to the instruction 1, the I/O manager adjusts the I/O priority of the first process.

That is, the I/O manager may adjust the I/O priority of the first process to the second I/O priority. Thus, the first process can be guaranteed to be capable of preferentially performing the I/O access, and the response time of the first process in the I/O access process is reduced.

S314, the scheduling executor sends an instruction 2 to the process manager.

Wherein instruction 2 carries the second process priority of the first process. In addition, as shown in FIG. 3, the dispatch executor also includes a process priority interface, from which instruction 2 may be sent to the process manager. Wherein this instruction 2 may also be referred to as a first instruction.

S315, in response to receiving the instruction 2, the process manager adjusts the process priority of the first process.

That is, the process manager may adjust the process priority of the first process to the second process priority. Therefore, the first process can occupy CPU resources preferentially, and smooth operation of the first process is guaranteed.

Therefore, by adjusting the I/O priority and the process priority of the first process, the I/O access of the first process and the consumption of CPU resources can be preferentially ensured, so that the first process can normally and smoothly run, and the user is ensured to have good experience.

It should be noted that, there is no strict sequence between S312 and S314, S312 may be executed first, S314 may be executed first, S312 may be executed second, S312 may be executed first, or S314 and S312 may be executed simultaneously.

S316, the load management controller sends the CPU power consumption scheduling strategy 2 to the chip strategy fusion device.

S317, the chip strategy fusion device judges the type of the chip platform of the CPU as

Or->

CPU chip of company and->

The CPU of the company has different adjustment modes for CPU power consumption, and therefore needs to be distinguished. Wherein, if the chip platform type of the CPU is +.>

(which may also be referred to as a first type), then S318 is performed; if the chip platform type of the CPU is +.>

(which may also be referred to as a second type), S325 is performed.

S318, the chip policy fusion device sends the CPU power consumption scheduling policy 2 to the scheduling executor.

The CPU power consumption scheduling strategy 2 comprises PL1 ', PL2 ' and EPP '.

And S319, the scheduling executor sends an instruction 3 to the OS2SOC driving node.

Wherein, instruction 3 carries PL1 'and PL 2'. That is, instruction 3 is used to adjust PL1 and PL2 of the CPU. Wherein instruction 3 may also be referred to as a third instruction.

In an alternative embodiment, instruction 3 may be sent by the CPU power consumption scheduling interface of the scheduling executor to the OS2SOC driving node.

S320, the OS2SOC driving node sends an instruction 3 to the CPU.

S321, in response to instruction 3, the cpu adjusts PL1 and PL2.

That is, the CPU may adjust PL1 to PL1 'and PL2 to PL 2'.

S322, the scheduling executor sends an instruction 4 to the power manager.

Wherein instruction 4 carries EPP'. That is, instruction 4 is used to adjust the EPP of the CPU. Instruction 4 may also be referred to as a fourth instruction.

S323, the power manager sends an instruction 4 to the CPU.

S324, in response to the instruction 4, the CPU adjusts EPP.

That is, the CPU may adjust EPP to EPP'.

S325, the chip strategy fusion device determines a dynamic tuning technical strategy number according to the CPU power consumption scheduling strategy 2.

The dynamic tuning technique (dynamic tuning technology, DTT) is

Company is->

Processor and->

The power consumption is automatically and dynamically distributed among the independent display cards, so that the performance is optimized, the battery endurance time is prolonged, the performance of the CPU and the GPU can be improved, and the intelligent mixed work load power is balanced. />

It will be appreciated that there may be a mapping relationship between the DTT policy number and the CPU power consumption scheduling policy 2. A DTT policy table is constructed in BIOS, and any CPU power consumption scheduling policy 2 can be mapped to a DTT policy number in the DTT policy table through parameters (PL 1 ', PL2 ' and EPP ') in the DTT policy table, as shown in Table 4.

The DTT policy number may be used to identify a DTT policy (may also be referred to as a second sub-policy), where the DTT policy corresponding to the DTT policy number is used to adjust pl1_mini, pl1_max, pl2, pl2_time, EPO Gear of the CPU. 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 efficiency-performance optimization Gear (Energy Performance Optimize Gear, EPO Gear) is used for representing the strength of the DTT for adjusting the CPU energy efficiency ratio (EPP), the range of values is 1-5, and the larger the value is, the more energy efficiency tends to be when the EPP is adjusted; the smaller the value, the more performance is favored when adjusting EPP.

TABLE 4 Table 4

Note that table 4 only shows the correspondence of the parts PL1', PL2', EPP ' and DTT policy numbers, and actually may include more information than table 4. For example, if the CPU power consumption scheduling policy 2 indicates that PL1' is-1, PL2' is-1 and EPP ' is-1, the DTT policy number may be determined to be 0, which corresponds to PL1 MINI of 30, PL1 max of 40, PL2 of 95, PL2 time of 28, epo Gear of 3.

S326, the chip strategy fusion device sends the DTT strategy number to the scheduling executor.

In an alternative embodiment, the chip policy aggregator may also send the power DTT policy (i.e. the second sub-policy) corresponding to the DTT policy number directly to the scheduling executor.

S327, the scheduling executor sends the DTT policy number to the Intel DTT driver.

S328, intel DTT driving sends a DTT strategy number to the CPU.

It will be appreciated that the Intel DTT driver may send a DTT policy number to the CPU via the BIOS.

S329, the CPU runs based on the DTT strategy number.

It can be seen that if the type of the chip platform of the CPU is

The chip policy aggregator may send an instruction to adjust EPP to the power manager via the schedule executor, and the power manager may adjust EPP of the CPU. In addition, the scheduling executor may also provide the OS2 withThe SOC driving node transmits an instruction to adjust PL1, PL2, and the OS2SOC driving node drives PL1 and PL2 of the CPU.

If the chip platform type of the CPU is

The chip policy fusion device can determine that the CPU power consumption scheduling policy 2 obtains a DTT policy number, and send the DTT policy number to the Intel DTT driver through the bios by the scheduling executor, so that the CPU operates based on the DTT policy number, and the effect of adjusting power consumption is achieved.

It can be understood that the present application may acquire a focus window change event and first information (including process information of a focus process, occupation condition of the focus process on a GPU, a peripheral event, a power mode, and the like), determine a user scene where the electronic device is currently located according to the focus window change event and the first information, determine a first scheduling policy in combination with the user scene and a system load of the electronic device, and adjust a process priority of the focus process, an I/O priority, and power consumption of the CPU based on the first scheduling policy, so as to reduce energy consumption of the electronic device under a condition that a user demand is smoothly satisfied (smooth operation of the focus process is ensured).

The intelligent scheduling system is applied to notebook products carrying Intel CPUs. From the view of the software architecture, the intelligent scheduling system is located at the application layer of the operating system, and the problems of abnormal running, termination (forced killing and unloading) by users and the like are unavoidable, so that the intelligent scheduling is invalid. Once the intelligent scheduling system fails, the adjustment of the CPU performance and power consumption can not be recovered, and the user experience is directly affected. For example, the user is in an office scene, and the intelligent scheduling system adjusts the CPU to a low power consumption state in the office scene, but at the moment, the intelligent scheduling system exits due to abnormal operation, so that when the user switches to a game scene, the CPU is continuously in the low power consumption state to cause a clamping, and only the machine is restarted to recover to be normal, thereby greatly reducing the user experience.

The embodiment of the application provides a resource scheduling method, which is characterized in that a corresponding scheduling strategy is determined by combining a user scene and a system load of electronic equipment through an intelligent scheduling system, the process priority, the I/O priority and the power consumption of a CPU (central processing unit) of a focus process are adjusted based on the scheduling strategy, meanwhile, the running condition of the intelligent scheduling system is monitored in real time, and when the failure of the intelligent scheduling system is detected (for example, caused by abnormal running, user termination and the like), the intelligent scheduling system is automatically restored to a default scheduling strategy to perform resource scheduling, so that the problem of blocking of the electronic equipment in the using process is avoided.

The embodiment of the application provides a scheme for solving the problem of abnormal failure of intelligent scheduling, and aims at recovering abnormal scenes such as application crash, user unloading and the like. Specifically, after determining the corresponding scheduling policy according to the application scenario, if an abnormal scenario is detected, the scheduling policy is not scheduled according to the original scheduling policy, but is restored to the default scheduling policy. When detecting an abnormal scene, whether the intelligent scheduling system is abnormal or not is identified by detecting the heartbeat message sent by the intelligent scheduling system, and if no corresponding heartbeat message is received, the intelligent scheduling system is considered to be abnormal. The time-out of the received data packet can be considered as abnormal occurrence of the intelligent scheduling system.

As shown in fig. 8, the intelligent scheduling system of the application layer establishes a heartbeat mechanism with the firmware layer of the PC, and the intelligent scheduling system sends a heartbeat packet to the firmware layer every preset time period (for example, 30 s).

The embedded controller (embedded controller, EC) at the firmware layer starts a 30s timer and resets the timer when the heartbeat packet sent by the upper layer is received. If the heartbeat packet is not received after the 30s timing is finished, the time-out is carried out, the intelligent dispatching system is judged to be finished running, and the BIOS is informed to set the power consumption dispatching strategy of the Intel CPU as a default dispatching strategy.

After the Intel DTT driver (driver) of the OS kernel layer detects the change of the scheduling strategy, the default scheduling strategy is read, and the default scheduling strategy is issued to the CPU, so that the CPU operates with normal performance, and the problem of blocking when a user uses the electronic equipment is avoided.

Because the operation life cycle of the firmware layer (BIOS, EC) is synchronous with the life cycle of the PC operation, the firmware layer is always in an operation state as long as the PC equipment is normally started, so the operation state of the intelligent scheduling system can be continuously monitored through a heartbeat mechanism, and the intelligent scheduling system is a very stable scheme.

Fig. 9 is another timing diagram of the resource scheduling method according to the embodiment of the present application, where the timing diagram is an interaction diagram provided in conjunction with the architecture diagram shown in fig. 8. As shown in fig. 9, the method includes S410 to S429 described below. Note that, the timing chart shown in fig. 9 may be executed simultaneously with the timing chart shown in fig. 4, 6, or 7.

S410, the intelligent scheduling system starts a resource scheduling function.

In some embodiments, when the electronic device is powered on, the electronic device may automatically turn on the intelligent scheduling system, i.e., turn on the resource scheduling function.

In some embodiments, the electronic device turns on the intelligent scheduling system, i.e., turns on the resource scheduling function, in response to a triggering operation by the user.

After the intelligent scheduling system is started, the electronic device can identify the user scenario as shown in fig. 4 and 6 in the above embodiments, and perform resource scheduling based on the user scenario and the system load as shown in fig. 7, where the resource scheduling includes scheduling of CPU power consumption, and scheduling of process priority and I/O priority of the focus process, so that the focus process is ensured to run smoothly, and the energy consumption of the electronic device is reduced under the condition that the user requirement is met. Thus, this resource scheduling policy may also be referred to as an optimized resource scheduling policy.

And after the intelligent scheduling system is started, whether the intelligent scheduling system operates normally can be judged by carrying out periodic heartbeat detection on the intelligent scheduling system. Under the condition that the intelligent scheduling system operates normally, the electronic equipment continuously executes an optimized resource scheduling strategy; and once the occurrence of abnormality of the intelligent scheduling system is detected, automatically switching to a default resource scheduling strategy of the electronic equipment to perform resource scheduling, so that the phenomenon of blocking caused by failure of the intelligent scheduling system when the user scene is switched is avoided.

The process of periodic heartbeat detection for the intelligent scheduling system is described in detail below.

S411, the intelligent scheduling system sends a heartbeat packet to the BIOS.

In some embodiments, after the smart dispatcher system is turned on, the smart dispatcher system sends a heartbeat packet to the BIOS every a first period of time, T. For example, the period of transmitting the heartbeat packet is 30 seconds, that is, the heartbeat packet is transmitted every 30 seconds.

It will be appreciated that when an exception occurs in the intelligent scheduling system, the intelligent scheduling system stops sending heartbeat packets.

In some embodiments, the intelligent scheduling system stops sending heartbeat packets when any of the following occurs: the intelligent scheduling system is turned off; the intelligent scheduling system is offloaded; the intelligent scheduling system is disabled due to system crash during operation. It will be appreciated that, for exemplary purposes, the occurrence of an exception in the intelligent scheduling system may include other situations, which are not limited in this embodiment of the present application.

S412, in response to receiving the heartbeat packet, the BIOS sends a message to the EC that the intelligent scheduling system is operating normally.

The state value may be used to indicate the operation status of the intelligent scheduling system, for example, the state value 1 may be used to indicate that the intelligent scheduling system is operating normally. Illustratively, the BIOS may notify the EC that the intelligent dispatch system is functioning properly by sending a status value (e.g., equal to 1) to the EC.

In some embodiments, in response to receiving the heartbeat packet, the BIOS forwards the heartbeat packet to the EC, thereby informing the EC that the intelligent dispatch system is functioning properly.

S413, the BIOS feeds back the successful receipt of the heartbeat packet to the intelligent dispatching system.

Illustratively, the BIOS may indicate that the heartbeat packet has been successfully received by returning a reshape value to the intelligent dispatch system.

It should be noted that S413 is an optional step, that is, the BIOS may feed back the message that the heartbeat packet is successfully received to the intelligent scheduling system, or may not feed back the message, which is not limited in the scheme of the present application.

S414, the EC judges whether a timer is started.

S415, if the timer is not started, the EC starts the timer.

In some embodiments, the EC needs to start a timer (also referred to as a first timer) when the EC first receives a message that the intelligent scheduling system is operating properly.

In some embodiments, the timing period of the timer is greater than or equal to the transmission period duration T of the heartbeat packet.

Illustratively, the period duration of the smart scheduling system transmitting the heartbeat packet may be set to 30 seconds, and the timing duration of the timer may be set to 30 seconds.

Illustratively, the period duration of the smart scheduling system transmitting the heartbeat packet may be set to 30 seconds, and the timing duration of the timer may be set to 35 seconds. It can be understood that the timing duration of the timer is slightly longer than the period duration of the heartbeat packet sent by the intelligent scheduling system, so that the monitoring accuracy can be ensured.

For example, in actual implementation, the period duration of sending the heartbeat packet by the intelligent scheduling system and the timing duration of the timer may be determined according to actual use requirements, which is not limited in the embodiment of the present application.

S416, if the timer is started, the timer starts to count.

The method for periodically detecting the heartbeat of the intelligent scheduling system comprises the following steps:

and when the timer is not overtime and the heartbeat packet is detected or the message that the intelligent scheduling system operates normally is detected, judging that the intelligent scheduling system operates normally and restarting the timer. See steps S417 to S420 described below in particular.

Or when the timer is overtime and no heartbeat packet is detected or the intelligent scheduling system operates normally, the intelligent scheduling system is judged to be abnormal, and the following steps S421 to S424 can be seen.

S417, the intelligent scheduling system sends the heartbeat packet to the BIOS again.

S418, BIOS sends message of normal operation of intelligent dispatching system to EC again.

S419, when the EC receives the message sent by the BIOS, the EC judges whether the timer is overtime.

S420, if the timer does not timeout, the EC resets the timer (i.e., the timer restarts counting).

It will be appreciated that before the timer expires, the EC receives a message that the intelligent scheduling system is operating properly and can determine that the intelligent scheduling system is operating properly.

Then, the EC resets the timer, the timer restarts to count, and before the timer times out, if the EC receives a message that the intelligent scheduling system is running normally, the EC can determine that the intelligent scheduling system is running normally.

The circulation is executed, and whether the intelligent scheduling system is in a normal running state can be judged in real time.

Through the steps, the intelligent scheduling system can be judged to be in a normal running state in real time according to the timer. In the case that the intelligent scheduling system is in a normal running state, the power consumption strategy of the CPU can be dynamically adjusted according to the resource scheduling method provided in the embodiment.

In some cases, when the intelligent scheduling system is abnormal in operation and is stopped (killed and unloaded by a user) and other problems, the intelligent scheduling system can be disabled, and a corresponding strategy recovery mechanism is needed to be adopted at the moment, so that the CPU can operate in a default power consumption state, and the problem of blocking when the user uses the electronic equipment is avoided. The specific recovery policy mechanism is as follows.

S421, the intelligent scheduling system is abnormal in operation or terminated by a user, and scheduling is invalid.

In this case, the intelligent dispatch system will not send heartbeat packets to the BIOS nor will the BIOS send notification messages to the EC.

S422, the EC judges whether the timer is overtime.

S423, when the timer times out, the EC sends a timeout event to the BIOS.

S424, BIOS judges whether a timeout event is received.

S425, when the BIOS receives the overtime event, the BIOS modifies the CPU scheduling policy to a default scheduling policy.

In some embodiments, the BIOS obtains a first DTT policy number from a preset DTT policy table that identifies a default CPU power consumption scheduling policy.

The preset DTT policy table comprises a mapping relation between CPU power consumption scheduling parameters in a default CPU power consumption scheduling policy and a first DTT policy number.

S426, the BIOS informs the Intel DTT driver of reading the scheduling policy.

S427, the Intel DTT driver requests the BIOS for reading the scheduling policy.

S428, BIOS issues default scheduling policy to Intel DTT driver.

S429, intel DTT driving issues a default scheduling policy to the CPU.

In some embodiments, the BIOS sends a first message to the DDT driver, the first message indicating that the resource scheduling policy has changed. In response to receiving the first message, the DDT driver sends a request to the BIOS to request that the latest resource scheduling policy be issued. Then, in response to receiving the request, the BIOS issues a first DTT policy number to the DDT driver; in response to receiving the first DTT policy number, the DDT driver issues the first DTT policy number to the CPU. In this way, the CPU adjusts power consumption and performance according to the default scheduling policy.

It should be noted that, in the above embodiment, the Intel CPU is taken as an example to read the DTT policy number corresponding to the default scheduling policy through the Intel DTT driver, and issue the DTT policy number corresponding to the default scheduling policy to the CPU, so that the CPU may determine the corresponding default scheduling policy according to the DTT policy number. Optionally, aThe above-mentioned scheme is also applicable to

When the CPU chip of the intelligent scheduling system is detected to be invalid, automatically recovering to a default scheduling strategy to perform resource scheduling; the difference is that- >

The manner of reading the scheduling policy of the CPU chip may be different from the manner of reading the default scheduling policy by Intel DTT, which may be specifically determined according to the actual situation, and the embodiment of the application is not limited.

Based on the upper layer scene identification, the CPU executes different power consumption strategies according to different user scenes, so as to achieve the purpose of increasing the endurance experience. Under the condition that the upper layer scene identification fails (such as abnormal scenes of application crash, user unloading and the like), the scheduling is not performed according to the original optimized scheduling strategy, but the power consumption strategy of the CPU is automatically switched to the default power consumption strategy, so that the CPU performance is restored to the normal level, and the normal experience of the user is ensured.

By way of example, assuming that the user scenario is currently an office scenario, when the intelligent scheduling system operates normally, the intelligent scheduling system can adjust the CPU to a low power consumption state based on the office scenario and the system load, so that smooth and non-stuck use experience is satisfied, and meanwhile, the CPU power consumption can be reduced. When the intelligent scheduling system exits due to abnormal operation, the abnormal occurrence of the intelligent scheduling system can be detected rapidly through the scheme, and the default scheduling strategy of the electronic equipment is automatically restored to perform resource scheduling, for example, the CPU is adjusted to a high power consumption state. At this time, if the user scene is switched from the office scene to the game scene, since the CPU is in a high power consumption state at this time, a stuck will not occur in the game scene, and thus a stuck event can be avoided.

In addition, when the intelligent scheduling system operates normally, not only the optimized CPU power consumption scheduling strategy is adopted to adjust the power consumption of the CPU, but also the optimized OS scheduling strategy is adopted to adjust the process priority and the input/output I/O priority of the focus process. Under the condition, when the occurrence of the abnormality of the intelligent scheduling system is detected, on one hand, the system automatically restores to a default scheduling strategy to schedule resources; on the other hand, the OS scheduling policy for adjusting the process priority and the input/output I/O priority of the focus process is also automatically restored to the default OS scheduling policy. Therefore, the problem of clamping and stopping of the electronic equipment in the using process is avoided.

Embodiments of the present application also provide an electronic device including a memory and one or more processors.

Wherein the memory is for storing computer program code, the computer program code comprising computer instructions; the computer instructions, when executed by the processor, cause the electronic device to perform the functions or steps of the method embodiments described above. The structure of the electronic device may refer to the structure of the electronic device 100 shown in fig. 1.

The electronic device in the embodiment of the present application may be a notebook computer or a personal computer (personal computer, PC) or the like, and the embodiment of the present application is not particularly limited.

Embodiments of the present application also provide a chip system, as shown in fig. 10, comprising at least one processor 801 and at least one interface circuit 802. The processor 801 and the interface circuit 802 may be interconnected by wires. For example, interface circuit 802 may be used to receive signals from other devices (e.g., a memory of an electronic apparatus). For another example, interface circuit 802 may be used to send signals to other devices (e.g., processor 801). The interface circuit 802 may, for example, read instructions stored in a memory and send the instructions to the processor 801. The instructions, when executed by the processor 801, may cause the electronic device to perform the various steps of the embodiments described above. Of course, the chip system may also include other discrete devices, which are not specifically limited in this embodiment of the present application.

The embodiment of the application also provides a computer storage medium, which comprises computer instructions, when the computer instructions run on the electronic device, the electronic device is caused to execute the functions or steps executed by the mobile phone in the embodiment of the method.

The present application also provides a computer program product, which when run on a computer, causes the computer to perform the functions or steps performed by the mobile phone in the above-mentioned method embodiments.

It may be understood that, in order to implement the above-mentioned functions, the electronic device provided in the embodiments of the present application includes corresponding hardware structures and/or software modules that perform each function. Those of skill in the art will readily appreciate that the elements and algorithm steps of the examples described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.

The embodiment of the application may divide the functional modules of the electronic device according to the method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated modules may be implemented in hardware or in software functional modules. It should be noted that, in the embodiment of the present application, the division of the modules is schematic, which is merely a logic function division, and other division manners may be implemented in actual implementation.

It will be apparent to those skilled in the art from this description that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely a specific embodiment of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present disclosure should be covered in the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. The resource scheduling method is characterized by being applied to electronic equipment, wherein the electronic equipment comprises an intelligent scheduling system, a graphic processor GPU and a central processing unit CPU, and the method comprises the following steps:

responding to a first operation of a user, and displaying a first window by the electronic equipment, wherein the first window is a focus window; acquiring process information and first information of a first process corresponding to the first window, wherein the first information comprises at least one of the following information: GPU occupation information, peripheral events or power mode information of the first process;

determining a user scene where the electronic equipment is located according to the process information of the first process and the first information;

obtaining a first scheduling strategy according to the system load of the electronic equipment and the user scene;

adopting the first scheduling strategy to adjust the power consumption of the CPU, the process priority of the first process and the input/output I/O priority;

And when detecting that the intelligent scheduling system is abnormal, adopting a default CPU power consumption scheduling strategy of the electronic equipment to adjust the power consumption of the CPU.

2. The method according to claim 1, wherein the method further comprises:

starting the intelligent scheduling system;

and judging whether the intelligent scheduling system is abnormal or not by carrying out periodic heartbeat detection on the intelligent scheduling system.

3. The method according to claim 2, wherein the determining whether the smart scheduling system is abnormal by performing periodic heartbeat detection on the smart scheduling system comprises:

after the intelligent scheduling system is started, sending a heartbeat packet every a first period time length T;

when the first timer is overtime and the heartbeat packet is not detected, judging that the intelligent scheduling system is abnormal; or alternatively, the process may be performed,

when the first timer is not overtime and the heartbeat packet is detected, judging that the intelligent scheduling system is normal in operation;

wherein the first period duration T is less than or equal to the timing duration of the first timer.

4. A method according to claim 3, characterized in that the method further comprises:

Restarting the first timer if the first timer does not timeout and the heartbeat packet is detected.

5. The method according to claim 3 or 4, characterized in that the method further comprises:

stopping sending the heartbeat packet when the intelligent scheduling system has the first condition;

wherein the first condition comprises any one of: the intelligent scheduling system is closed; the intelligent scheduling system is offloaded; the intelligent scheduling system is in failure due to system breakdown during operation.

6. A method according to claim 2 or 3, wherein the electronic device further comprises a basic input output system BIOS and a microcontroller EC;

the method for judging whether the intelligent scheduling system is abnormal or not by detecting the periodic heartbeat of the intelligent scheduling system comprises the following steps:

after the intelligent scheduling system is started, the intelligent scheduling system sends a heartbeat packet to a basic input/output system BIOS every the first period duration T;

in response to receiving the heartbeat packet, the BIOS judges that the intelligent dispatching system is normal;

the basic input/output system BIOS sends a notification message that the intelligent scheduling system operates normally to the microcontroller EC;

In response to receiving the notification message, the microcontroller EC determines whether a first timer has been started;

in case the first timer has been started, the microcontroller EC determines whether the first timer has timed out;

if the first timer is overtime, the microcontroller EC sends an overtime event to the basic input output system BIOS;

and in response to receiving the timeout event, the BIOS judges that the intelligent dispatching system is abnormal.

7. The method of claim 6, wherein after the microcontroller EC determines whether the first timer has been started, the method further comprises:

in case the first timer is not started, the microcontroller EC controls the first timer to be started.

8. The method according to claim 6 or 7, wherein after the microcontroller EC determines whether the first timer has timed out, the method further comprises:

if the first timer does not time out, the microcontroller EC restarts the first timer.

9. The method according to any of claims 3 to 8, wherein the first transmission period T is 30 seconds and the timing duration of the first timer is 35 seconds.

10. The method of claim 6, wherein after the BIOS determines that the smart dispatch system is abnormal, the method further comprises:

and the basic input/output system BIOS adjusts the resource scheduling strategy of the electronic equipment into the default CPU power consumption scheduling strategy.

11. The method of claim 10, wherein the basic input output system BIOS adjusting the resource scheduling policy of the electronic device to the default CPU power consumption scheduling policy comprises:

the basic input output system BIOS obtains a first DTT strategy number for identifying the default CPU power consumption scheduling strategy from a preset DTT strategy table;

the preset DTT policy table includes a mapping relationship between a CPU power consumption scheduling parameter in the default CPU power consumption scheduling policy and the first DTT policy number.

12. The method according to claim 10 or 11, wherein the electronic device further comprises a dynamic tuning technique, DDT, driver;

after the BIOS adjusts the resource scheduling policy of the electronic device to the default CPU power consumption scheduling policy, the method further includes:

The BIOS sends a first message to the DDT driver, wherein the first message indicates that the resource scheduling strategy is changed;

in response to receiving the first message, the DDT driver sends a request to the BIOS to request to issue a latest resource scheduling policy;

in response to receiving the request, the basic input output system BIOS issues the first DTT policy number to the DDT driver;

in response to receiving the first DTT policy number, the DDT driver issues the first DTT policy number to the CPU.

13. The method of any of claims 1 to 12, wherein said adjusting the power consumption of the CPU with a default CPU power consumption scheduling policy of the electronic device comprises:

in response to receiving the first DTT policy number, the CPU determines a corresponding default CPU power consumption scheduling policy according to the first DTT policy number;

the CPU adjusts the power consumption of the CPU according to the CPU power consumption scheduling parameters in the default CPU power consumption scheduling strategy;

wherein the CPU power consumption scheduling parameters include at least one of: the CPU has default long-time-to-frequency power consumption, default short-time-to-frequency power consumption and default energy efficiency ratio EPP.

14. The method of any one of claims 1 to 13, wherein the first scheduling policy comprises an optimized CPU power consumption scheduling policy and an optimized operating system OS scheduling policy;

wherein the adjusting the power consumption of the CPU and the process priority and the input/output I/O priority of the first process using the first scheduling policy includes:

adjusting the power consumption of the CPU according to the optimized CPU power consumption scheduling strategy;

and adjusting the process priority and the I/O priority of the first process according to the optimized OS scheduling strategy.

15. The method according to any one of claims 1 to 14, further comprising:

and when the intelligent scheduling system is detected to be abnormal, adopting a default OS scheduling strategy of the electronic equipment to adjust the process priority and the input/output I/O priority of the first process.

16. The method according to any one of claims 1 to 15, characterized in that before said deriving a first scheduling policy from said system load and said user scenario, the method further comprises:

determining a second scheduling policy according to the user scene, wherein the second scheduling policy comprises a first process priority of the first process, a first input/output (I/O) priority, a first long-time (Rui) frequency power consumption (PL 1) of the CPU, a first short-time (Rui) frequency power consumption (PL 2) and a first energy efficiency ratio (EPP);

The obtaining a first scheduling policy according to the system load and the user scene includes:

obtaining the first scheduling policy according to the system load, the user scene and the second scheduling policy, wherein the first scheduling policy at least comprises a second process priority of the first process, a second I/O priority, a second PL1 of the CPU, a second PL2 of the CPU and a second EPP;

if the system load is greater than a preset first value, the second process priority is higher than or equal to the first process priority, the second I/O priority is higher than or equal to the first I/O priority, 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.

17. The method of any one of claims 1 to 16, wherein the optimized CPU power consumption scheduling policy comprises a first sub-policy and a second sub-policy, the second sub-policy being a dynamic tuning technique, DTT, policy determined from the first sub-policy;

the adjusting the power consumption of the CPU according to the optimized CPU power consumption scheduling policy includes:

determining a chip platform type of the CPU, wherein the chip platform type comprises a first type and a second type;

If the chip platform type is the first type, adjusting the power consumption of the CPU according to the first sub-strategy;

and if the chip platform type is the second type, adjusting the power consumption of the CPU according to the second sub-strategy.

18. The method according to any one of claims 1 to 17, wherein the GPU occupancy information of the first process comprises a GPU occupancy of the first process and a GPU engine;

the determining, according to the process information of the first process and the first information, a user scene where the electronic device is located includes:

determining the type of the first process according to the process information of the first process;

if the type of the first process is a video type, the GPU occupancy rate of the first process is greater than 0, the GPU engine is a GPU video process engine, and the user scene where the electronic is located is determined to be a video playing scene;

if the type of the first process is a video type, the occupancy rate of the GPU of the first process is greater than 0, the GPU engine is a GPU 3D engine, and the user scene where the electronic is located is determined to be a video browsing scene.

19. The method of claim 18, wherein the method further comprises:

If the type of the first process is a game type, the power mode is a game mode, the GPU occupancy rate of the first process is greater than 0, the GPU engine is a GPU 3D engine, and the user scene where the electronic device is located is determined to be a game scene.

20. The method of any one of claims 1 to 17, wherein the peripheral event comprises one or more of a keyboard input event, a mouse input event, a microphone input event, a camera input event;

determining the type of the first process according to the process information;

if the type of the first process is social, and the keyboard input event is detected, determining that the user scene where the electronic is located is a text chat scene;

if the type of the first process is social, detecting the microphone input event and not detecting the camera input event, and determining that a user scene where the electronic is located is a voice chat scene;

if the type of the first process is social, detecting the microphone input event and the camera input event, and determining that the user scene where the electronic is located is a video chat scene.

21. The method of claim 20, wherein the method further comprises:

if the type of the first process is office type, and the keyboard input event is detected, determining that the user scene where the electronic device is located is a document editing scene;

if the type of the first process is office, detecting the mouse input event and not detecting the keyboard input event, and determining that a user scene where the electronic device is located is a document browsing scene;

if the type of the first process is office, detecting the microphone input event and the camera input event, and determining that the user scene where the electronic device is located is a video conference scene.

22. An electronic device, the electronic device comprising: a memory and one or more processors;

wherein the memory is for storing computer program code, the computer program code comprising computer instructions; the computer instructions, when executed by the processor, cause the electronic device to perform the method of any one of claims 1 to 21.

23. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program which, when run on an electronic device, causes the electronic device to perform the method of any one of claims 1 to 21.