Processor resource management method and related apparatus

Abstract

Provided in the present application are a processor resource management method and a related apparatus. An electronic device can identify critical threads, critical dependency threads and non-critical threads. When running the critical threads and the critical dependency threads, the electronic device can dynamically adjust the frequency of a processor on the basis of task processing conditions of the critical threads and the critical dependency threads, so as to accurately supply processor resources to the critical threads and the critical dependency threads. The electronic device can constrain the supply of processor resources provided to the non-critical threads. The method can improve the utilization efficiency of processor resources. The electronic device can provide a user with a smooth experience when using the electronic device, and can also save power of the electronic device and reduce the instances of excessively rapid temperature rises in the electronic device, thereby achieving a balance among the requirements for a smooth device performance, a long battery life, and rapid cooling.

Description

Processor resource management method and related device

[0001] The present application claims priority to the Chinese patent application No. 202411758108.7, filed on November 29, 2024, and entitled "Processor resource management method and related device", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the technical field of terminal, and in particular to a processor resource management method and related device. BACKGROUND

[0003] With the development of electronic devices, the functions provided by the application programs (such as video playing application, game application, social application, etc.) in the electronic devices (such as mobile phones, tablets, smart watches, etc.) for users are becoming more and more rich, meeting the needs of users in daily life, work, travel, etc. The running of the application programs in the electronic devices depends on the computing power resources of the processor. The higher the computing power resources provided by the electronic devices for the application, the smoother the running of the application, but at the same time, it will also cause the power consumption of the electronic device to increase and the temperature of the device to rise. With the increasing demand of the application programs for computing power resources, how to improve the utilization efficiency of the processor resources is a problem that needs to be solved at present. SUMMARY

[0004] The present application provides a processor resource management method and related device. Among them, the electronic device can identify the key threads, the key dependent threads and the non-key threads. The electronic device can preferentially supply the processor resources to the key threads and the key dependent threads, and supply the processor resources to the non-key threads in a constrained manner. The above method can improve the utilization efficiency of the processor resources and provide users with a smooth experience of using the electronic device.

[0005] In a first aspect, the present application provides a processor resource management method. The method is applied to an electronic device, and the electronic device includes a first key thread list. When a first key thread is running, the electronic device identifies a key dependent thread of the first key thread, the first key thread is any one thread in the first key thread list, the key dependent thread of the first key thread includes a thread other than the first key thread on a first critical path, a node on the first critical path corresponds to a thread, the head node and the tail node on the first critical path both correspond to the first key thread, and there is an awakening relationship between any two adjacent nodes on the first critical path; and the electronic device improves the priority of the key dependent thread of the first key thread.

[0006] The above key thread list can refer to the key thread information shown in FIG. 3B and FIG. 4A of this application. The first key path can refer to the key path shown in FIG. 3C of this application: thread x1-thread x2-thread x4-thread x1.

[0007] As can be seen, the above method can identify the threads directly and indirectly dependent on the key thread, and preferentially supply processor resources to the threads dependent on the key thread, reducing the case that the indirectly dependent threads are blocked when the indirectly dependent threads are missed, causing the key thread to be blocked for a long time. This can improve the speed of the key thread running, thereby improving the smoothness of the electronic device and user interaction.

[0008] In combination with the first aspect, in some embodiments, the first key thread list is associated with a first application scenario, and before the electronic device improves the priority of the key dependent thread of the first key thread running, the electronic device determines that the electronic device is in the first application scenario according to the first application running in the foreground.

[0009] As can be seen, the electronic device can identify the key thread and the key dependent thread corresponding to the current application scenario, and improve the priority of the key dependent thread corresponding to the current application scenario. This can improve the smoothness of the foreground application running, and provide the user with a smooth experience of using the electronic device.

[0010] In combination with the first aspect, in some embodiments, the electronic device further includes a second key thread list, the second key thread list is associated with a second application scenario; after the electronic device improves the priority of the key dependent thread of the first key thread running, the electronic device determines that the electronic device is in the second application scenario according to the second application running in the foreground; the electronic device identifies the key dependent thread of the second key thread, the second key thread is any one thread in the second key thread list, the key dependent thread of the second key thread includes a thread other than the second key thread on a second key path, a node on the second key path corresponds to a thread, the head node and the tail node on the second key path both correspond to the second key thread, and there is a wake-up relationship between two adjacent nodes on the second key path; and the electronic device improves the priority of the key dependent thread of the second key thread running.

[0011] After the electronic device determines that the electronic device is in the second application scenario according to the application running in the foreground, the electronic device reduces the priority of the key dependent thread of the first key thread running.

[0012] As can be seen, when the application scenario is switched, the electronic device can improve the priority of the corresponding thread running, so as to preferentially supply processor resources to the key dependent thread of the application running in the foreground in real time. This can improve the smoothness of the foreground application running, and provide the user with a smooth experience of using the electronic device.

[0013] In some embodiments, the electronic device identifies the key dependent thread of the first key thread, the electronic device searches for the key dependent thread of the first key thread in a first key dependent thread list, the first key dependent thread list includes the key dependent thread of the first key thread, and the first key dependent thread list is obtained by the electronic device from a server.

[0014] The first key dependent thread list can refer to the thread protection list sent by the server 200 to the electronic device 100 shown in FIG. 3B of the present application.

[0015] As can be seen, the electronic device can directly search for the key dependent thread of the key thread in the first key dependent thread list obtained from the server. In this way, the speed of identifying the key dependent thread can be improved.

[0016] In some embodiments, the electronic device detects a first thread wake-up event, the first thread wake-up event is used to indicate a first wake-up relationship in which the first thread wakes up a second thread; the electronic device determines that the second thread is a key dependent thread of a first key thread according to a historical wake-up relationship of threads in the electronic device, the historical wake-up relationship includes a first historical number of occurrences of the first wake-up relationship, a second historical number of times that the first thread and the second thread are actually both key dependent threads of the first key thread in history when the first wake-up relationship occurs, wherein the first historical number is greater than a first number threshold, and a ratio of the second historical number to the first historical number is greater than a first probability threshold; the electronic device also searches for the key dependent thread of the first key thread in a second key dependent thread list, the second key dependent thread list includes the key dependent thread of the first key thread, and the second key dependent thread list is generated by the electronic device according to the historical wake-up relationship of the threads.

[0017] The first wake-up relationship can refer to the wake-up relationship 1 shown in FIG. 4B of the present application.

[0018] The historical wake-up relationship can refer to the historical transition matrix information shown in FIG. 4B of the present application. The first historical number can refer to the number of wake-up relationships shown in Table 2 of the present application. The second historical number can refer to the number of wake-up relationships shown in Table 3 of the present application.

[0019] As can be seen, the electronic device can obtain the latest wake-up relationship between threads in real time according to the running situation of the threads, thereby identifying the key dependent thread of the key thread in real time.

[0020] In some embodiments, the second key dependent thread list does not include the second thread, and after the electronic device determines that the second thread is a key dependent thread of a first key thread according to a historical wake-up relationship of threads in the electronic device, the electronic device adds the second thread to the second key dependent thread list.

[0021] In some embodiments, after the electronic device adds the second thread to the second key dependent thread list, the electronic device determines that the first wake-up relationship occurs a third number of times according to the historical wake-up relationship, and the first thread and the second thread are historically actual key dependent threads of the first key thread when the first wake-up relationship occurs a fourth number of times, wherein a ratio of the fourth number of times to the third number of times is less than the first probability threshold; and the electronic device removes the second thread from the second key dependent thread list.

[0022] It can be seen that the electronic device can obtain the latest wake-up relationship between threads in real time according to the running situation of the threads, thereby adaptively updating the key dependent threads. Moreover, as the use time of the electronic device increases, the electronic device can more accurately identify the key dependent threads.

[0023] In some embodiments, the second key dependent thread list is updated based on the first key dependent thread list, and the first key dependent thread list is obtained from a server by the electronic device, and the first key dependent thread list contains key dependent threads of one or more key threads in the first key thread list.

[0024] In some embodiments, the electronic device divides threads in the electronic device into a foreground group and a non-foreground group, the foreground group contains threads of foreground applications running in the foreground and threads of system services associated with the foreground applications, and the non-foreground group contains threads of system services not associated with the foreground applications and threads of background applications running in the background; the electronic device detects CPU load rates of threads in the foreground group; when the CPU load rates of the threads in the foreground group increase, the electronic device determines a first increase amount of the CPU time slice length according to an increase amount of the CPU load rates of the threads in the foreground group; and the electronic device increases the CPU time slice length of the threads in the foreground group according to the first increase amount, and decreases the CPU time slice length of the threads in the non-foreground group.

[0025] It can be seen that the threads in the foreground group are user-sensitive threads. Based on the above thread grouping, the electronic device can suppress the processor resources obtained by the threads in the non-foreground group when the CPU load rate of the foreground group is high, and provide the threads in the foreground group with longer CPU time slices. In this way, the threads in the foreground group can obtain more processor resources when the task amount is large, so as to complete the task faster and provide the user with a smooth device use experience. Moreover, when the CPU load rate of the foreground group decreases, the electronic device can provide the threads in the non-foreground group with longer CPU time slices, so that the tasks of the threads in the non-foreground group can be executed quickly. The above method can effectively improve the utilization efficiency of processor resources by grouping and controlling the CPU time slices of different thread groups, while ensuring the smoothness of device use, and allowing the threads in the non-foreground group to remain running.

[0026] In combination with the first aspect, in some embodiments, before the electronic device detects the CPU load rate of the threads in the foreground group, the electronic device detects a first foreground event, and the first foreground event includes a change in a foreground application running in the foreground.

[0027] It can be understood that when the above first foreground event occurs, the CPU load of the threads in the foreground group can change. The electronic device adjusts the ratio of the above CPU weights based on the change in the CPU load rate of the foreground group when detecting the foreground event, which can reduce the number of times the electronic device detects the CPU load rate of the foreground group, and improve the efficiency of controlling the CPU time slices of each thread group.

[0028] In combination with the first aspect, in some embodiments, the electronic device divides the threads in the electronic device into a foreground group and a non-foreground group, the foreground group includes threads of foreground applications running in the foreground and threads of system services associated with the foreground applications, and the non-foreground group includes threads of system services not associated with the foreground applications and threads of background applications running in the background; the electronic device detects the overall load of the electronic device and / or the device shell temperature, the overall load including the CPU load of the threads in the foreground group and the non-foreground group; when the overall load is a first load and / or the device shell temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and performs CPU bandwidth quota on the threads in the non-foreground group based on the first bandwidth quota.

[0029] It can be seen that the electronic device can perform bandwidth quota suppression on the threads in the non-foreground group according to the system load and / or the device temperature. The bandwidth quota can reduce the system load per unit time. Among them, the higher the system load, the higher the degree of bandwidth quota suppression on the threads in the non-foreground group by the electronic device; the higher the device temperature, the higher the degree of bandwidth quota suppression on the threads in the non-foreground group by the electronic device. The above bandwidth quota suppression method can control the system load and the device temperature of the electronic device, reduce the case that the threads in the non-foreground group affect the running of the threads in the foreground group when the system load is too high, and can reduce the case that the device temperature is too high.

[0030] In combination with the first aspect, in some embodiments, when the system load changes to a second load and / or the device shell temperature changes to a second temperature, the electronic device determines a second bandwidth quota amount according to the second load and / or the second temperature, and performs CPU bandwidth quota on the threads in the non-foreground group according to the second bandwidth quota amount; wherein if the second load is higher than the first load and / or the second temperature is higher than the first temperature, the second bandwidth quota amount is smaller than the first bandwidth quota amount.

[0031] In combination with the first aspect, in some embodiments, the electronic device divides the threads in the electronic device into a foreground group, a normal thread group and a restricted thread group, the foreground group includes threads of foreground applications running in the foreground and threads associated with the foreground applications in system services, the restricted thread group includes threads in system services that are not associated with the foreground applications and can be delayed, threads in background applications running in the background that can be delayed, and the normal thread group includes threads in system services that are not associated with the foreground applications and are not in the restricted thread group, threads in background applications that are not in the restricted thread group; the electronic device continuously performs CPU bandwidth quota on the threads in the restricted thread group according to a third bandwidth quota amount; the electronic device detects the system load and / or the device shell temperature of the electronic device, the system load including the CPU load of the threads in the foreground group, the non-normal thread group and the restricted thread group; when the system load is a first load and / or the device shell temperature is a first temperature, the electronic device determines a first bandwidth quota amount according to the first load and / or the first temperature, and performs CPU bandwidth quota on the threads in the normal thread group according to the first bandwidth quota amount.

[0032] It can be seen that the electronic device can perform persistent bandwidth quota suppression on the threads that can be delayed and have high CPU load to reduce the case of burst load. The electronic device can also perform dynamic bandwidth quota suppression on the threads in the non-foreground group other than the restricted thread group according to the system load and / or the device temperature. In this way, the system load and the device temperature of the electronic device can be controlled, the case that the threads in the non-foreground group affect the running of the threads in the forefront group when the system load is too high can be reduced, and the case that the device temperature is too high can be reduced.

[0033] In some embodiments, the electronic device divides threads in the electronic device into a foreground group and a non-foreground group, the foreground group including threads of foreground applications running in the foreground and threads of system services associated with the foreground applications, and the non-foreground group including threads of system services not associated with the foreground applications and threads of background applications running in the background; when detecting that a third thread is waiting for a fourth thread to release a first shared resource or to obtain a first running result from the fourth thread, the electronic device labels the fourth thread with a first label, the third thread being a thread of the foreground group and the fourth thread being a thread of the non-foreground group; and the electronic device performs one or more of the following operations on the thread with the first label: increasing a priority of running, increasing a length of a CPU time slice, and removing a CPU bandwidth quota; and when the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first label from the fourth thread.

[0034] The third thread waiting for the fourth thread to release the first shared resource or to obtain the first running result from the fourth thread can include a case where the third thread is waiting for the fourth thread to release a binder / thread lock.

[0035] It can be seen that the threads in the foreground group depend on the threads in the non-foreground group, and the electronic device can temporarily increase the priority of the threads in the non-foreground group that are depended on by the foreground group, increase the length of the CPU time slice of the threads, and remove the bandwidth quota suppression on the threads. In addition, moving the threads in the non-foreground group that are depended on by the foreground group to the foreground group requires a reaction and execution time. Compared with changing the thread group of the depended threads, the above method of setting the critical section can more efficiently reduce the priority inversion and improve the smoothness of running of the threads in the foreground group.

[0036] In some embodiments, the foreground group includes critical threads in a first critical thread list and critical dependent threads of the critical threads in the first critical thread list.

[0037] In some embodiments, the electronic device detects a whole-machine load and / or a device case temperature of the electronic device, the whole-machine load including loads of all threads in the electronic device; and the electronic device determines a first CPU frequency according to the whole-machine load and / or the device case temperature, and controls a CPU frequency of the CPU when running non-critical threads to be below the first CPU frequency, the non-critical threads including the critical threads in the first critical thread list and threads other than the critical dependent threads of the critical threads in the first critical thread list.

[0038] It can be seen that the electronic device can save the power of the electronic device and reduce the rapid heating of the electronic device by suppressing the CPU frequency of the non-critical threads while keeping the non-critical threads running.

[0039] With reference to the first aspect, in some embodiments, the first key thread is used to complete a multi-frame task, during running of the first key thread and a key dependent thread of the first key thread, the electronic device determines, according to a CPU frequency adjustment period, that a first frequency adjustment time is located in a time period in which a first frame task in the multi-frame task runs; at the first frequency adjustment time, the electronic device detects whether the first frame task is completed; if the first frame task is not completed, the electronic device adjusts the CPU frequency to a second CPU frequency according to a first frequency adjustment function; the first frequency adjustment function is a power function with CPU computing power as the dependent variable, a running time of a frame task in the multi-frame task as the independent variable, and an exponent being a positive number less than 1.

[0040] The first frequency adjustment function can refer to the optimal frequency adjustment function in the embodiments of the present application.

[0041] With reference to the first aspect, in some embodiments, if the first frame task is completed, the electronic device reduces the CPU frequency to a third CPU frequency.

[0042] With reference to the first aspect, in some embodiments, neither a time at which the first frame task starts running nor a time at which the first frame task completes running is a frequency adjustment time determined according to the CPU frequency adjustment period, when it is detected that the first frame task starts running, the electronic device adjusts the CPU frequency to a fourth CPU frequency; when it is detected that the first frame task completes running, the electronic device reduces the CPU frequency to a fifth CPU frequency.

[0043] It can be seen that the electronic device can real-time increase the CPU frequency when the frame task of the key thread and the key dependent thread starts, and real-time reduce the CPU frequency when the frame task of the key thread and the key dependent thread ends. During running of the frame task of the key thread and the key dependent thread, the electronic device can adjust the CPU frequency according to the optimal frequency adjustment function. In this way, the supply precision of the processor resources supplied to the key thread and the key dependent thread can be improved, so as to improve the utilization efficiency of the processor resources, and balance the requirements of smooth performance, long endurance and rapid cooling of the device.

[0044] With reference to the first aspect, in some embodiments, after the first frame task completes running, the electronic device determines, according to the CPU frequency adjustment period, that a second frequency adjustment time is located in a time period in which a second frame task in the multi-frame task runs; at the second frequency adjustment time, the electronic device detects whether the second frame task is completed; if the second frame task is not completed, the electronic device adjusts the CPU frequency to a sixth CPU frequency according to the first frequency adjustment function.

[0045] With reference to the first aspect, in some embodiments, the first key thread is a thread used to determine display content of a user interface, and a frame task in the multi-frame task includes determining display content of a frame of the user interface; or, the first key thread is a thread used to render the user interface, and a frame task in the multi-frame task includes rendering a frame of the user interface.

[0046] The first frequency modulation function is:

[0047] wherein u(t) is the computing power provided by the CPU of the electronic device at a time, maxUtil is the maximum computing power of the CPU of the electronic device, Time is the time from the current time to the time when the synchronization signal of the previous frame task is issued, the synchronization signal of the previous frame task is used to instruct the electronic device to run the previous frame task, deadline is the period of refreshing the user interface of the electronic device, margin is determined according to the time length of running one or more frame tasks before the current running frame task in the first key thread, kk and a are determined according to the historical running data of one or more threads and the CPU energy efficiency curve of the electronic device, and the one or more threads include the first key thread and the key dependent thread of the first key thread.

[0048] In a second aspect, the present application provides a processor resource management method. The electronic device divides threads in the electronic device into a foreground group and a non-foreground group, the foreground group containing threads of foreground applications running in the foreground and threads associated with the foreground applications in system services, and the non-foreground group including threads in system services not associated with the foreground applications and threads of background applications running in the background; the electronic device performs one or more of the following operations on the threads in the non-foreground group: adjusts the CPU time slice length of one or more threads in the non-foreground group according to the load rate change of the threads in the foreground group, performs CPU bandwidth quota on one or more threads in the non-foreground group, and controls the CPU frequency to be below the first CPU frequency when the CPU runs one or more threads in the non-foreground group.

[0049] It can be seen that the electronic device can group threads. The electronic device can use different processor resource management strategies for different thread groups to improve the accuracy of processor resource supply and achieve the balance between device performance smoothness, long battery life and rapid cooling.

[0050] In combination with the second aspect, in some embodiments, when the CPU load rate of the threads in the foreground group increases, the electronic device determines a first increase amount of the CPU time slice length according to the increase amount of the CPU load rate of the threads in the foreground group; and the electronic device increases the CPU time slice length of one or more threads in the foreground group according to the first increase amount, and reduces the CPU time slice length of one or more threads in the non-foreground group.

[0051] It can be seen that the threads in the foreground group are user-sensitive threads. Based on the above thread grouping, the electronic device can suppress the processor resources obtained by the threads in the non-foreground group when the CPU load rate of the foreground group is high, and provide the threads in the foreground group with longer CPU time slices. In this way, the threads in the foreground group can obtain more processor resources when the task amount is large, so as to complete the task faster and provide the user with a smooth device use experience. Moreover, when the CPU load rate of the foreground group decreases, the electronic device can provide the threads in the non-foreground group with longer CPU time slices, so that the tasks of the threads in the non-foreground group can be executed quickly. The above method can effectively improve the utilization efficiency of processor resources by grouping and controlling the CPU time slices of different thread groups, while ensuring the smoothness of device use, the threads in the non-foreground group can remain running.

[0052] In combination with the second aspect, in some embodiments, the electronic device detects the overall load of the electronic device and / or the device shell temperature, the overall load including the CPU load of the threads in the foreground group and the non-foreground group; when the overall load is a first load and / or the device shell temperature is a first temperature, the electronic device determines a first bandwidth quota amount according to the first load and / or the first temperature, and performs CPU bandwidth quota on one or more threads in the non-foreground group according to the first bandwidth quota amount.

[0053] It can be seen that the electronic device can perform bandwidth quota suppression on the threads in the non-foreground group according to the overall load and / or the device temperature. The bandwidth quota can reduce the overall load per unit time. Among them, the higher the overall load, the higher the degree of bandwidth quota suppression on the threads in the non-foreground group by the electronic device; the higher the device temperature, the higher the degree of bandwidth quota suppression on the threads in the non-foreground group by the electronic device. The above bandwidth quota suppression method can control the overall load of the electronic device and the device temperature, reduce the case that the threads in the non-foreground group affect the running of the threads in the foreground group when the overall load is too high, and can reduce the case that the device temperature is too high.

[0054] In combination with the second aspect, in some embodiments, when the overall load changes to a second load and / or the device shell temperature changes to a second temperature, the electronic device determines a second bandwidth quota amount according to the second load and / or the second temperature, and performs CPU bandwidth quota on one or more threads in the non-foreground group according to the second bandwidth quota amount; wherein if the second load is higher than the first load and / or the second temperature is higher than the first temperature, the second bandwidth quota amount is smaller than the first bandwidth quota amount.

[0055] In some embodiments, the non-foreground group includes a normal thread group and a restricted thread group, the restricted thread group including threads in system services that are not associated with foreground applications and that can be delayed, threads in background applications that are running in the background and that can be delayed, the normal thread group including threads in system services that are not associated with foreground applications and that are not in the restricted thread group, threads in background applications that are not in the restricted thread group; the electronic device performs CPU bandwidth quota on one or more threads in the non-foreground group, the electronic device continuously performing CPU bandwidth quota on one or more threads in the restricted thread group according to a third bandwidth quota amount; the electronic device detects a system load of the electronic device and / or a device case temperature, the system load including CPU loads of threads in the foreground group, the non-normal thread group, and the restricted thread group; when the system load is a first load and / or the device case temperature is a first temperature, the electronic device determines a first bandwidth quota amount according to the first load and / or the first temperature, and performs CPU bandwidth quota on one or more threads in the normal thread group according to the first bandwidth quota amount.

[0056] It can be seen that the electronic device can perform persistent bandwidth quota suppression on threads that can be delayed and have high CPU loads, so as to reduce the case of burst load. The electronic device can also perform dynamic bandwidth quota suppression on threads in the non-foreground group other than the restricted thread group according to the system load and / or the device temperature. In this way, the system load of the electronic device and the device temperature can be controlled, the case where threads in the non-foreground group affect the running of threads in the foreground group when the system load is too high can be reduced, and the case where the device temperature is too high can be reduced.

[0057] In some embodiments, the first CPU frequency is determined according to a system load of the electronic device and / or a device case temperature, the system load including loads of all threads in the electronic device.

[0058] In some embodiments, when it is detected that a third thread is waiting for a fourth thread to release a first shared resource or to obtain a first running result from the fourth thread, the electronic device tags the fourth thread with a first label, the third thread being a thread in the foreground group and the fourth thread being a thread in the non-foreground group; the electronic device performs one or more of the following operations on the thread with the first label: increasing a running priority, increasing a CPU time slice length, and removing CPU bandwidth quota; when the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first label of the fourth thread.

[0059] It can be seen that the thread in the foreground group depends on the thread in the non-foreground group, and the electronic device can temporarily increase the priority of the thread in the non-foreground group that is depended on by the foreground group, increase the CPU time slice length of the thread, and release the bandwidth quota suppression on the thread. Moreover, moving the thread in the non-foreground group that is depended on by the foreground group to the foreground group needs reaction and execution time. Compared with changing the thread group of the depended thread, the above method of setting the critical section can more efficiently reduce the priority inversion and improve the smoothness of the thread running in the foreground group.

[0060] In a third aspect, the present application provides an electronic device. The electronic device can include a memory and a processor. The memory can be used to store a computer program. The processor can be used to invoke the computer program to perform any possible implementation method in the first aspect or the second aspect.

[0061] In a fourth aspect, the present application provides a computer-readable storage medium storing instructions, which can be executed by a processor to implement any possible implementation method in the first aspect or the second aspect.

[0062] In a fifth aspect, the present application provides a computer program product, which can include computer instructions, when the computer instructions are executed on a processor, can implement any possible implementation method in the first aspect or the second aspect.

[0063] In a sixth aspect, the present application provides a chip applied to an electronic device, the chip including one or more processors configured to invoke computer instructions to cause the electronic device to perform any possible implementation method in the first aspect or the second aspect.

[0064] It can be understood that the electronic device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, the computer program product provided in the fifth aspect, and the chip provided in the sixth aspect are all used to execute the method provided in the embodiments of the present application. Therefore, the beneficial effects that can be achieved are referred to the beneficial effects in the corresponding method, which will not be described here. BRIEF DESCRIPTION OF DRAWINGS

[0065] FIG. 1 is a schematic diagram of processor resource management provided in an embodiment of the present application;

[0066] FIG. 2A is a flowchart of a thread scheduling method provided in an embodiment of the present application;

[0067] FIG. 2B is a schematic diagram of thread priority adjustment provided in an embodiment of the present application;

[0068] FIG. 3A and FIG. 3B are schematic diagrams of identifying a key dependent thread provided in an embodiment of the present application;

[0069] FIG. 3C is a diagram of a wake-up relationship tree according to an embodiment of the present application;

[0070] FIG. 4A and FIG. 4B are diagrams of identifying a key dependent thread according to an embodiment of the present application;

[0071] FIG. 4C-FIG. 4G are diagrams of some wake-up relationship trees according to an embodiment of the present application;

[0072] FIG. 5 is a diagram of thread grouping according to an embodiment of the present application;

[0073] FIG. 6A is a flowchart of a method of grouping and managing CPU time slices according to an embodiment of the present application;

[0074] FIG. 6B is a diagram of grouping and managing CPU time slices according to an embodiment of the present application;

[0075] FIG. 7A is a flowchart of a method of bandwidth quota suppression based on thread grouping according to an embodiment of the present application;

[0076] FIG. 7B is a flowchart of another method of bandwidth quota suppression based on thread grouping according to an embodiment of the present application;

[0077] FIG. 8 is a flowchart of a method of processor resource allocation according to an embodiment of the present application;

[0078] FIG. 9 is a flowchart of a method of CPU frequency suppression for non-key threads according to an embodiment of the present application;

[0079] FIG. 10 is a diagram of a frequency adjustment curve according to an embodiment of the present application;

[0080] FIG. 11A is a diagram of determining an optimal frequency adjustment function according to an embodiment of the present application;

[0081] FIG. 11B is a diagram of a CPU energy efficiency curve according to an embodiment of the present application;

[0082] FIG. 12A is a flowchart of a method of determining an optimal frequency adjustment function according to an embodiment of the present application;

[0083] FIG. 12B is a diagram of thread running according to an embodiment of the present application;

[0084] FIG. 12C is a flowchart of a method of determining frame loss data and power consumption of a key thread and a key dependent thread based on a set of slope parameters and curvature parameters according to an embodiment of the present application;

[0085] FIG. 12D is a diagram of frequency adjustment according to an embodiment of the present application;

[0086] FIG. 13A is a diagram of an interpolation scenario according to an embodiment of the present application;

[0087] FIG. 13B is a schematic diagram of a frame skipping scenario according to an embodiment of the present application;

[0088] FIG. 14A is a schematic diagram of an optimal frequency modulation curve according to an embodiment of the present application;

[0089] FIG. 14B is a schematic diagram of a comparison between an optimal frequency modulation curve and a non-optimal frequency modulation curve according to an embodiment of the present application;

[0090] FIG. 15 is a schematic diagram of frequency modulation according to an embodiment of the present application;

[0091] FIG. 16A is a schematic diagram of a hardware structure of an electronic device 100 according to an embodiment of the present application;

[0092] FIG. 16B is a schematic diagram of a software structure of an electronic device 100 according to an embodiment of the present application. DETAILED DESCRIPTION

[0093] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing the specific embodiments of the present application, and are not intended to be limiting on the present application. As used in the specification and the appended claims of the present application, the singular forms "a," "an," and "the" are intended to include plural forms, such as "one or more," unless the context clearly indicates otherwise. It should also be understood that, in the following embodiments of the present application, "at least one" and "one or more" refer to one or two or more (including two). The term "and / or" is used to describe the association relationship of the associated objects, which means that there can be three relationships; for example, A and / or B can represent the following three cases: A exists alone, A and B exist together, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after it.

[0094] Reference in the specification to "one embodiment" or "some embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase "in one embodiment" or "in some embodiments" in various places in the specification are not necessarily all referring to the same embodiment, although it can. The terms "including," "comprising," "having" and variations thereof are meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms "connected" and "coupled" are not restricted to direct connections or couplings but include indirect connections or couplings through another component or components. The terms "first," "second," and "third" are used to describe various elements, but can not be interpreted as implying relative importance or a number of the elements.

[0095] In the present application, the word "exemplary" or "for example" is used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, use of the word "exemplary" or "for example" is intended to present concepts in a concrete manner.

[0096] The present application provides a processor resource management method. As shown in FIG. 1, an electronic device can manage processor resources of the electronic device based on information intercommunication between a software level and a hardware level (i.e., soft and hard cooperation). The software level of the electronic device can include a system and a kernel of the electronic device. On the software level of the electronic device, the electronic device can identify a key thread, a key dependent thread, and a non-key thread. The key dependent thread can include a thread directly or indirectly dependent on the key thread. On the hardware level of the electronic device, the electronic device can adjust a frequency of a processor in combination with processor energy efficiency, device temperature, power consumption of other devices (e.g., a communication module, a camera, a screen, etc.), etc., to achieve management of processor resources. Wherein, when running the key thread and the key dependent thread, the electronic device can dynamically adjust the frequency of the processor according to a task processing situation of the key thread and the key dependent thread, to achieve accurate supply of processor resources to the key thread and the key dependent thread. The electronic device can supply processor resources to the non-key thread in a constrained manner. In this way, the running of the non-key thread can be ensured, and the situation that the non-key thread occupies too much processor resources when the task amount of the key thread and the key dependent thread is large, causing the key thread and the key dependent thread to be blocked, can be reduced.

[0097] It can be seen that the above method accurately identifies key threads, key dependent threads, and non-key threads, and accurately allocates appropriate processor resources to different threads. The above method can improve the utilization efficiency of processor resources, and reduce the over-provisioning or under-provisioning of processor resources for threads. In this way, the electronic device can provide a smooth experience for users to use the electronic device while saving the power of the electronic device and reducing the situation of the electronic device overheating too quickly, achieving a balance between the smooth performance of the device and the long battery life and rapid cooling of the device.

[0098] For ease of understanding, some concepts related to the present application are introduced here.

[0099] Thread: A thread is the smallest unit of operation scheduling by an operating system. A thread is an execution unit within a process. A thread can refer to a single sequential flow of control in a process. A process is an instance of a program running in an operating system, responsible for resource allocation and scheduling, and has an independent address space and other auxiliary data. A process can contain multiple threads, and the multiple threads can share the resources (such as memory resources, file descriptors, etc.) of the same process.

[0100] The life cycle of a thread can include a creation state, a running state, a ready state, a blocking state, and an end state. The creation state can indicate that the thread is being created. The running state can indicate that the thread is occupying the central processing unit (CPU) and is running. The ready state can indicate that the thread can run at present, but the specific time of running depends on when the scheduler schedules the thread. For example, in the case that the current CPU is occupied by other processes, the thread can be in the ready state to wait for the call of the scheduler. The blocking state can indicate that the thread is temporarily stopped running while waiting for the target event to occur (such as waiting for the resource to be accessed to be released by other threads, etc.), and actively gives up the CPU usage right. The end state can indicate the state of the end of the thread running.

[0101] Key thread: A key thread can represent a thread that has a relatively large impact on the user's perception of the smoothness of the electronic device's running. If a key thread is in a blocked state for a long time, the user will obviously perceive that the electronic device is running is stuck, and the user interaction is not smooth. In some embodiments, the key thread can include, but is not limited to, a user interface (UI) thread, a render service (RS) thread, an audio playback thread, a main thread of a foreground application, and the like. The UI thread can be used to be responsible for processing user interface interactions and determining the specific content displayed by the user interface. The RS thread can be used to render the user interface. If the UI thread and the RS thread are in a blocked state for a long time, the electronic device can have slow user operation response, frame loss, interface stuttering, and the like, affecting the user's experience. The RS thread can also be referred to as a graphics thread. The audio playback thread can be used to implement audio playback. If the audio playback thread is in a blocked state for a long time, the electronic device can have audio playback stuttering. The main thread of an application is the starting point of the application and is a thread created by the application when it starts. The main thread of the application can be used to perform initialization operations of the application, including resource allocation, environment setting, and the like. The main thread of the application can create one or more sub-threads. If the main thread of the foreground application is in a blocked state for a long time, the foreground application can have slow startup and running stuttering after startup.

[0102] Key dependent thread: A key dependent thread can include a thread that is directly or indirectly dependent on a key thread. For example, thread 1 is a key thread. Thread 1 depends on thread 2. Thread 2 depends on thread 3. Then, thread 2 and thread 3 are key dependent threads. Among them, thread 2 is a thread directly dependent on thread 1. Thread 3 is a thread indirectly dependent on thread 1. The electronic device accurately supplies processor resources to the key dependent thread, which can effectively reduce the blocking of the key thread and improve the smoothness of the electronic device and user interaction.

[0103] Non-key thread: A non-key thread can refer to a thread other than a key thread and a key dependent thread. The electronic device delays running the non-key thread, which usually does not affect the user's perception of the smoothness of the electronic device's running. For example, the non-key thread can include a background data download thread. Slow running of the background data download thread does not affect the user's interaction with the foreground application. In the case of limited processor resources, the electronic device suppresses the processor resources provided to the non-key thread, which can prioritize the fast running of the key thread and the key dependent thread and improve the smoothness of the electronic device and user interaction.

[0104] Dependency: Two threads have a dependency relationship can represent that one of the two threads runs in dependence on another thread releasing a shared resource / returning a running result / sending an event notification, etc. For example, thread 1 depends on thread 2. Thread 2 can be referred to as a dependent thread of thread 1. Thread 1 needs to wait for thread 2 to release a shared resource that thread 1 needs to access, or thread 2 to return a running result that thread 1 needs, or thread 2 to send a corresponding event notification to thread 1, before thread 1 can enter a ready state. When thread 2 runs, thread 1 is in a blocked state. If thread 2 cannot run in time due to insufficient priority or improper allocation of processor resources, thread 1 will be forced to wait and may be in a blocked state for a long time.

[0105] Dependency can include explicit dependency and implicit dependency. Explicit dependency can represent a dependency relationship that exists a direct calling relationship. For example, thread 1 calls thread 2 when running and waits for thread 2 to return a running result. Thread 2 can wake up thread 1 after obtaining the running result that thread 1 needs, and send the corresponding running result to thread 1. Thread 1 can continue to run according to the running result of thread 2. In the above process, thread 1 depends on thread 2, and the dependency relationship between the two can be referred to as explicit dependency. Implicit dependency can represent a dependency relationship that does not exist a direct calling relationship. For example, thread 1 needs to access resource A when running. Currently, resource A is being accessed by thread 3 (i.e., thread 3 holds the lock of resource A). Thread 1 needs to wait for thread 3 to release the lock of resource A before accessing resource A. Therefore, during the period when thread 3 holds the lock of resource A, thread 1 enters a blocked state. When thread 3 releases the lock of resource A, thread 1 can enter a ready state and access resource A after obtaining the use right of CPU. In the above process, thread 1 depends on thread 3, and the dependency relationship between the two can be referred to as implicit dependency.

[0106] Wakeup relationship: The wakeup relationship can include the above dependency relationship, and a relationship represented by one of two threads that do not have a dependency relationship waking up the other thread. For example, in the case that thread 1 explicitly depends on thread 2, thread 1 and thread 2 have a wakeup relationship. Among them, thread 1 wakes up thread 2 (i.e., thread 2 is the woken-up thread), and thread 2 also wakes up thread 1 (i.e., thread 1 is the woken-up thread) after running for a period of time. In the case that thread 1 implicitly depends on thread 3, thread 1 and thread 3 have a wakeup relationship. Among them, thread 1 can be equivalent to being woken up by thread 3. In the case that thread 1 and thread 4 do not have a dependency relationship, thread 1 can wake up thread 4 in the process of running. Thread 1 and thread 4 have a wakeup relationship. Among them, thread 1 will not enter a blocked state because of the running of thread 4. Thread 1 and thread 4 can run in parallel.

[0107] Processor resource: The processor resource can include the computing power of the CPU. The computing power of the CPU can be described in terms of dhrystone million instructions executed per second (DMIPS). Among them, the computing power of the CPU = the number of CPU cores * the frequency * DMPIS. The frequency of the CPU can represent the clock frequency at which the CPU core works. It can be seen that the higher the frequency of the CPU when working, the more computing power resources the CPU provides, and the smoother the thread runs. But the more computing power resources the CPU provides, the higher the power consumption of the CPU. The processor resource provided by the electronic device for the thread can include but is not limited to: adjusting the CPU time slice of the thread occupying the CPU, adjusting the frequency of the CPU when the thread runs. The CPU time slice can represent the duration that the thread can run on the CPU at a time.

[0108] Kernel: The kernel is the main component of the operating system (OS) and is also the core interface between the hardware of the electronic device and its processes. The kernel can provide the most basic functions of the OS and is responsible for managing the processes, memory, device drivers, files, and network systems of the system.

[0109] Referring to FIG. 2A, FIG. 2A exemplarily shows a method flowchart of thread scheduling provided by the present application.

[0110] S211, the application program issues a system call request.

[0111] The application program can be any application program in the electronic device, for example, an instant messaging application, a short video application, a shopping application.

[0112] The system call is an interface provided by the operating system for the application program to use. The application program obtains the service of the operating system through the system call request. In order to ensure the stability and security of the operating system and prevent the application program from performing illegal operations, the application program needs to make a service request to the operating system through the method of system call to complete it on behalf of the operating system. The process of the application program can switch the running state from the user mode to the kernel mode through the system call. When the system call is executed, the running state of the process switches back from the kernel mode to the user mode.

[0113] S212, the call request enters the kernel.

[0114] S213, the kernel receives the call request and allocates resources for the thread of the application program.

[0115] S214, creating a thread.

[0116] Applications can create threads based on the resources allocated to them in order to perform corresponding tasks (e.g., tasks that update the user interface, tasks that update audio, etc.).

[0117] S215. Identify critical threads and critical dependent threads, increase the scheduling priority of critical threads and critical dependent threads, and dynamically adjust the processor frequency when critical threads and / or critical dependent threads are running.

[0118] In some embodiments, the electronic device can determine whether the thread created in step S214 is a critical thread. The electronic device may store a list of critical threads corresponding to different application scenarios. The lists of critical threads for different application scenarios may be the same, partially different, or completely different. The electronic device can determine the current application scenario based on the application currently running in the foreground. For example, application scenarios may include: short video playback and switching scenarios, chat scenarios in instant messaging applications, browsing products in shopping applications, etc. If the thread created in step S214 is within the list of critical threads corresponding to the current application scenario, the electronic device can determine that the thread is a critical thread; otherwise, the thread is not a critical thread.

[0119] If the thread created in step S214 above is a critical thread, the electronic device can further identify the critical dependent threads of that critical thread.

[0120] If the thread created in step S214 above is not a critical thread, the electronic device can detect whether the thread is a critical dependent thread.

[0121] The method for identifying critical dependent threads will be described in subsequent embodiments. It will not be elaborated here.

[0122] Electronic devices can elevate the scheduling priority of critical threads and critical dependent threads. After the scheduling priority is increased, the electronic device can prioritize the execution of critical threads and critical dependent threads. Optionally, for high-priority threads, the electronic device can also allocate longer CPU time slices so that these threads can complete their execution quickly.

[0123] As shown in Figure 2B, the scheduler in the electronic device can schedule threads sequentially according to their order in the thread run queue, allocating processor access to the currently scheduled thread. Before the electronic device identifies critical threads and critical dependent threads, these threads are at the tail of the thread run queue. After identifying critical threads and critical dependent threads, the electronic device can increase their priority. For example, the electronic device can move critical threads and critical dependent threads from the tail to the head of the thread run queue. In this way, the scheduler in the electronic device can prioritize scheduling critical threads and critical dependent threads.

[0124] In some embodiments, the electronic device may also dynamically adjust the processor frequency while critical threads and / or critical dependent threads are running.

[0125] For example, when critical threads or critical dependent threads have a large workload, electronic devices can increase the processor frequency so that these threads can complete their tasks within a certain timeframe. This reduces the likelihood of insufficient processor resources being allocated to critical threads and critical dependent threads, which could lead to delays and stuttering.

[0126] For example, when critical threads or critical dependent threads have a small workload, or when they have completed their target task but need to wait for subsequent tasks to be executed, electronic devices can reduce the processor frequency to reduce power consumption. This reduces the waste of processor resources caused by excessive allocation of processor resources to critical threads and critical dependent threads, which helps improve the battery life of electronic devices and reduce overheating.

[0127] The method for dynamically adjusting the processor frequency of an electronic device will be described in subsequent embodiments. It will not be elaborated here.

[0128] It should be noted that the above-mentioned increase in the scheduling priority of critical threads is optional. That is, the electronic device can also dynamically adjust the processor frequency only when critical threads and / or critical dependent threads are running.

[0129] In some embodiments, if the thread created in step S214 above is a non-critical thread, the electronic device can constrain the supply of processor resources provided by the non-critical thread when running it. The specific method for constraining the supply will be described in subsequent embodiments. It will not be elaborated here.

[0130] S216, Thread execution.

[0131] S217, user interface / audio and other updates.

[0132] The tasks performed by the thread may include user interface / audio updates. This application does not limit the type of the tasks described above.

[0133] As described above, this method accurately identifies critical threads, critical dependent threads, and non-critical threads, thereby prioritizing critical threads and critical dependent threads and precisely allocating appropriate processor resources to different threads. This improves processor resource utilization efficiency and reduces situations where processor resources are over- or under-supplied to threads. In this way, electronic devices can provide users with a smooth user experience while conserving power, reducing overheating, and achieving a balance between smooth performance, long battery life, and rapid cooling.

[0134] The following describes a method for identifying critical dependent threads provided in an embodiment of this application.

[0135] In some embodiments, electronic devices can identify critical dependent threads based on an offline mode. Offline mode can mean that critical dependent threads are identified on the server side based on critical thread information and historical wake-up relationship data of application threads. The server can send the critical dependent thread information to the user-side electronic device (e.g., mobile phone, tablet, smartwatch, etc.). The user-side electronic device can then identify whether the currently running thread is a critical dependent thread based on the aforementioned critical dependent thread information, and thus determine the corresponding processor resource allocation strategy.

[0136] Figures 3A and 3B exemplarily illustrate a schematic diagram of identifying critical dependent threads provided in this application.

[0137] As shown in Figures 3A and 3B, the offline function module can be a module deployed in server 200. The offline function module can receive historical wake-up relationship data and key thread information of application threads, and output a thread protection list. The thread protection list may contain information about critical dependent threads.

[0138] The historical wake-up relationship data of the application threads can include various wake-up relationships between threads collected based on big data statistics. In some embodiments, when the application runs on a user-side electronic device, the event tracker in the electronic device can track the running state of the threads and generate a trace file. The aforementioned event tracker can be a Function Trace module (which may be abbreviated as the ftrace module). The aforementioned trace file can include data such as the thread execution time and the dependencies between threads. The historical wake-up relationship data of the application threads can be the data contained in the aforementioned trace file.

[0139] Key thread information can include the names of key threads corresponding to different application scenarios. The offline function module can identify the key dependent threads of key threads in different application scenarios.

[0140] The information about critical dependent threads in the above thread protection list may include the application scenario to which the critical dependent thread belongs and the name of the critical dependent thread.

[0141] As shown in Figure 3B, the offline function module may include a wake-up relationship analysis module, a statistical integration module, and a selection module.

[0142] The wake-up relationship analysis module can be used to construct a wake-up relationship tree based on the historical wake-up relationship data of application threads. This wake-up relationship tree can be constructed based on a directed acyclic graph (DAG). Then, the wake-up relationship analysis module can reverse-engineer the critical path from the wake-up relationship tree based on key thread information to obtain critical path data.

[0143] Figure 3C illustrates a schematic diagram of a wake-up relationship tree.

[0144] As shown in Figure 3C, the wake-up relationship analysis module can construct a wake-up relationship tree containing threads x1 to x7 based on the historical wake-up relationship data of application threads. Black circles represent key threads, and white circles represent threads. A solid line connecting two circles indicates a dependency relationship between the threads represented by those two circles. A dashed line connecting two circles indicates a wake-up relationship between the threads represented by those two circles.

[0145] As shown in Figure 3C, thread x1 wakes up threads x2 and 3, thread x2 wakes up threads x4 and x6, thread x3 wakes up thread x5, thread x4 wakes up thread x1, and thread x5 wakes up thread x7. The wake-up relationship analysis module can determine the critical path in the wake-up relationship data through a reverse inference method. The critical path can be a path in the wake-up path where the starting point and ending point are the same critical thread. For example, thread x1 is the critical thread. Starting with thread x1, the wake-up relationship analysis module can find the thread that wakes up thread x1 in the wake-up relationship tree, which is thread x4. Further, starting with thread x4, the wake-up relationship analysis module can find the thread that wakes up thread x4 in the wake-up relationship tree, which is thread x2. Further, starting with thread x2, the wake-up relationship analysis module can find the thread that wakes up thread x2 in the wake-up relationship tree, which is thread x1. In this way, the wake-up relationship analysis module can determine the critical path as thread x1—thread x2—thread x4—thread x1. The threads other than the critical thread in this critical path (i.e., threads x2 and thread x4) are critical dependent threads.

[0146] The wake-up relationship analysis module can send wake-up path data and critical path data to the statistics integration module. Wake-up path data can include the number of times each wake-up relationship occurs in the wake-up relationship tree, the priority of each thread among all threads in the wake-up relationship tree, and the runtime of threads in the wake-up relationship tree. Critical path data can include dependencies on the critical path and the priority of threads on the critical path among all threads on the critical path.

[0147] The statistics integration module can statistically integrate wake-up path data and critical path data to generate a list of critical dependent threads. The list of critical dependent threads may include the names of the critical dependent threads. Optionally, the list may also include one or more of the following information: the frequency of the critical dependent thread on the critical path, the number of times the critical dependent thread appears in the wake-up relationship, the priority of the critical dependent thread on the critical path, the priority of the critical dependent thread among all threads in the wake-up relationship tree, and the duration of the critical dependent thread's execution.

[0148] The list of critical dependent threads can be found in Table 1 below.

[0149] Table 1

[0150] The overall priority in Table 1 represents the priority of the critical dependency thread among all threads in the wake-up relationship tree. Table 1 is merely an illustrative example of this application and should not be construed as limiting the application.

[0151] In some embodiments, the statistics and integration module can send a list of critical dependent threads to the selection module. The selection module can filter out a subset of critical dependent threads from all critical dependent threads based on one or more of the following information: the frequency of critical dependent threads appearing on the critical path, the number of times critical dependent threads appear in wake-up relationships, the priority of critical dependent threads on the critical path, the overall priority of critical dependent threads, and the runtime of critical dependent threads, and generate a thread protection list.

[0152] Server 200 can send a thread protection list to electronic device 100. Electronic device 100 can store the thread protection list and determine whether its running threads are critical threads or critical dependent threads based on the thread protection list. Electronic device 100 can be a user-side electronic device. In some embodiments, server 200 can send the aforementioned thread protection list to electronic device 100 when the system version of electronic device 100 is upgraded. Optionally, server 200 can update the aforementioned thread protection list periodically or irregularly and send the updated thread protection list to electronic device 100. This can improve the accuracy of electronic device 100 in identifying critical threads and critical dependent threads.

[0153] Alternatively, server 200 can directly send information about all critical dependent threads to electronic device 100. That is, server 200 can filter critical dependent threads without using a selection module.

[0154] As shown in Figure 3B, the electronic device 100 may include an application, a kernel, and memory. Upon receiving a thread protection list from the server 200, the electronic device 100 may store the thread protection list in memory. The memory may also store critical thread information. The kernel may include an event tracker and a scheduler. The application may initiate a system call request to the kernel. The system call request can be referred to the description of step S211 shown in Figure 2A above. The event tracker can use the aforementioned system call request to track and obtain the running information of the corresponding thread. The scheduler can be used to obtain critical thread information and the thread protection list, and determine whether thread priority adjustment is necessary based on the thread protection list.

[0155] Optionally, the electronic device 100 may also include an application scenario detection module. This module can detect the current application scenario of the electronic device 100 based on information such as the application currently running in the foreground and received user operations. Based on key thread information, the thread protection list, and the current application scenario, the module can determine the key threads and key dependent threads corresponding to the current application scenario. The module can then send these key threads and key dependent threads to the scheduler. The scheduler can then increase the priority of the key threads and key dependent threads corresponding to the current application scenario.

[0156] In some embodiments, the electronic device can identify critical dependent threads based on an online mode. The online mode can mean that the user-side electronic device collects and records the wake-up relationships of its running threads, and identifies whether a currently running thread is a critical thread based on the critical thread information and the wake-up relationships recorded by the electronic device. As the number of running threads on the electronic device increases, the number of wake-up relationships recorded by the electronic device also increases. The electronic device can periodically or irregularly update its identified critical dependent threads (e.g., reclassifying threads that were previously non-critical as critical dependent threads, or reclassifying previously identified critical dependent threads as non-critical threads).

[0157] Figures 4A and 4B exemplarily illustrate another schematic diagram of identifying critical dependent threads provided in this application.

[0158] As shown in Figure 4A, the electronic device 100 may include applications, a kernel, and memory. The kernel may include an event tracker, a scheduler, and online function modules. The memory may store critical thread information and a thread protection list.

[0159] In electronic device 100, applications can initiate system call requests to the kernel. An event tracker can track and obtain the execution information of the corresponding thread based on these system call requests. The event tracker can determine the thread wake-up event corresponding to the application's system call request based on the thread's execution information. The event tracker can send the thread wake-up event to the online functional module. The online functional module can obtain critical thread information from memory and determine whether the woken thread is a critical dependent thread based on the thread wake-up event and the critical thread information. If the currently woken thread is a critical dependent thread, the online functional module can instruct the scheduler to increase the priority of the currently woken thread.

[0160] Optionally, the electronic device 100 may also include an application scenario detection module. This module can detect the current application scenario of the electronic device 100 based on information such as the application currently running in the foreground and received user operations. Based on key thread information, the module can determine the key thread corresponding to the current application scenario. The module can then send the key thread corresponding to the current application scenario to the online function module. The online function module can identify the key dependent threads corresponding to the current scenario based on thread wake-up events and the key thread.

[0161] In some embodiments, the online functional module can update the thread protection list based on the identification results of critical threads or critical dependent threads of multiple threads over a period of time. The scheduler can adjust the priority of corresponding threads based on the critical dependent threads in the thread protection list. In addition, the scheduler can also obtain critical thread information and increase the priority of critical threads.

[0162] The online functional module can identify whether a thread is a critical thread or a critical dependent thread in accordance with the method shown in Figure 4B.

[0163] S411. Received a thread wake-up event. The thread wake-up event corresponds to wake-up relationship 1.

[0164] The wake-up relationship 1 can include a waking thread and a woken-up thread. For example, wake-up relationship 1 can be that thread x1 (i.e., the waking thread) wakes up thread x2 (i.e., the woken-up thread). Alternatively, wake-up relationship 1 can be that thread x2 (i.e., the waking thread) wakes up thread x4 (i.e., the woken-up thread). This application embodiment does not limit the wake-up relationship 1.

[0165] S412. Check if a wake-up relationship tree is currently being created.

[0166] If a wake-up relationship tree is already being created, the online function module can perform the following step S413.

[0167] If there is no wake-up relationship tree being created at present, the online function module can perform the following step S414.

[0168] S413. Update the wake-up relationship tree based on wake-up relationship 1.

[0169] In some embodiments, if wake-up relationship 1 does not exist in the wake-up relationship tree, and the wake-up thread in wake-up relationship 1 is an existing thread in the wake-up relationship tree, the online function module can add wake-up relationship 1 to the wake-up relationship tree and perform the following step S415.

[0170] If wake-up relationship 1 already exists in the wake-up relationship tree, then the wake-up relationship tree does not need to be updated.

[0171] If the wake-up thread in wake-up relation 1 is not an existing thread in the wake-up relation tree, the online functional module does not need to add wake-up relation 1 to the wake-up relation tree. In this case, the online functional module does not need to check whether wake-up relation 1 is on the critical path (i.e., it does not need to execute subsequent steps S415-S419).

[0172] S414. Create a wake-up relationship tree based on wake-up relationship 1.

[0173] For example, if wake-up relationship 1 is thread x1 waking up thread x2, and the online functional module detects that no wake-up relationship tree is currently being created, then the online functional module can create the wake-up relationship tree shown in Figure 4C. As shown in Figure 4C, the circle representing thread x1 points to the circle representing thread x2, which can indicate that thread x1 wakes up thread x2.

[0174] In some embodiments, if the wake-up thread in wake-up relationship 1 is a critical thread, the online functional module can create a wake-up relationship tree starting from that critical thread. If the wake-up thread in wake-up relationship 1 is not a critical thread, the online functional module does not need to create a wake-up relationship tree. That is to say, if there is no wake-up relationship tree being created and the wake-up thread in wake-up relationship 1 is not a critical thread, the online functional module does not need to check whether wake-up relationship 1 is on the critical path.

[0175] The wake-up relation tree can be stored in memory as a tree data structure during runtime. The online functional module allows for CRUD operations on the wake-up relation tree.

[0176] S415. Detect whether the wake-up relationship tree has ended.

[0177] The online function module can detect whether the wake-up relationship tree has ended based on wake-up relationship 1. Specifically, if the wake-up thread in wake-up relationship 1 is an existing thread in the wake-up relationship tree, and the wake-up thread in wake-up relationship 1 is a key thread in the wake-up relationship tree, then the wake-up relationship tree has ended. Otherwise, the wake-up relationship tree has not yet ended.

[0178] If the wake-up relationship tree is not finished, the online function module can perform the following step S416.

[0179] If the wake-up relationship tree ends, the online function module can execute the following step S418.

[0180] S416. Update the historical transition matrix information and read the historical transition matrix information. The historical transition matrix information includes the historical wake-up transition matrix and the critical path wake-up transition matrix. The historical wake-up transition matrix contains the historical number of times the wake-up relationship has occurred, and the critical path wake-up transition matrix contains the historical number of times the wake-up relationship has occurred on the critical path.

[0181] The historical wake-up transition matrix can be found in Table 2 below.

[0182] Table 2

[0183] Taking threads x1, x2 and x4 on the critical path as an example, the critical path wake-up transition matrix can be found in Table 3 below.

[0184] Table 3

[0185] If wake-up relationship 1 already exists in the current wake-up relationship tree, the online function module can increment the count of wake-up relationship 1 by 1 in the historical wake-up transition matrix.

[0186] For example, if wake-up relationship 1 is thread x1 waking up thread x2, and the online function module detects that there is already a wake-up relationship tree as shown in Figure 4D, then the online function module does not need to adjust the wake-up relationship tree, but will increment the number of wake-up relationships corresponding to thread x1 waking up thread x2 in the historical wake-up transition matrix by 1.

[0187] For example, if wakeup relationship 1 involves thread x2 waking up thread x4, and the online functional module detects an existing wakeup relationship tree as shown in Figure 4D, then the online functional module can update the wakeup relationship tree shown in Figure 4D to generate the wakeup relationship tree shown in Figure 4E. As shown in Figure 4E, the online functional module adds a branch from thread x2 to thread x4 based on the wakeup relationship tree shown in Figure 4D. If the historical wakeup transition matrix already contains a row and column corresponding to thread x4, the online functional module does not need to update the historical wakeup transition matrix. If the historical wakeup transition matrix does not contain a row and column corresponding to thread x4, the online functional module can add the row and column corresponding to thread x4 to the historical wakeup transition matrix.

[0188] If wakeup relationship 1 is on an existing critical path, the online functional module can increment the count of wakeup relationship 1 by 1 in the critical path wakeup transition matrix. The aforementioned critical path can be determined by the online functional module based on previous wakeup relationships and critical thread information.

[0189] For example, if wake-up relationship 1 is thread x2 waking up thread x4, and the existing critical path is thread x1—thread x2—thread x4—thread x1, then the online functional module can increment the number of wake-up relationship 1 by 1 in the critical path wake-up transition matrix.

[0190] For example, if wake-up relationship 1 involves thread x3 waking up thread x5, and the online functional module detects an existing wake-up relationship tree as shown in Figure 4D, then the online functional module can update the wake-up relationship tree shown in Figure 4D to generate the wake-up relationship tree shown in Figure 4F. As shown in Figure 4F, the online functional module adds a branch from thread x3 to thread x5 based on the wake-up relationship tree shown in Figure 4D. The online functional module can update the historical wake-up transition matrix according to the description in the previous embodiment. If the critical path is thread x1—thread x2—thread x4—thread x1, then wake-up relationship 1 is not in the existing critical path; therefore, the online functional module does not need to update the critical path wake-up transition matrix.

[0191] S417. Detect whether wake-up relationship 1 is on the critical path based on the historical transition matrix information.

[0192] In some embodiments, the online functional module can detect the probability of historical wake-up relationship 1 occurring on the critical path based on the historical wake-up transition matrix and the critical path wake-up transition matrix. The probability of wake-up relationship 1 occurring on the critical path can be predicted using a Markov modeling probability prediction method. Alternatively, the probability of wake-up relationship 1 occurring on the critical path can be: the number of times wake-up relationship 1 appears on the critical path in the critical path wake-up transition matrix ÷ the number of times wake-up relationship 1 appears in the historical wake-up transition matrix. The online functional module can detect whether the historical probability of wake-up relationship 1 occurring on the critical path is greater than a preset probability threshold, and whether the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​greater than a preset frequency threshold. For example, the probability threshold can be 0.7, 0.8, etc., and the frequency threshold can be 10, 20, etc. This application embodiment does not limit the values ​​of the probability threshold and the frequency threshold.

[0193] If the probability of wake-up relationship 1 on the critical path is greater than a probability threshold in the past, and the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​greater than a frequency threshold, then the online functional module can determine that wake-up relationship 1 is on the critical path. That is, the thread in wake-up relationship 1 is a critical thread or a critical dependent thread.

[0194] If the probability of wake-up relationship 1 on the critical path is less than or equal to a probability threshold, or if the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​less than or equal to a frequency threshold, then the online functional module can determine that wake-up relationship 1 is not on the critical path. That is, the thread woken up in wake-up relationship 1 is not a critical dependent thread.

[0195] Understandably, the currently constructed wake-up relationship tree is not yet complete, and the online functional module cannot yet deduce the critical path of the currently constructed wake-up relationship tree. Since the critical path may change (e.g., the threads that the critical thread depends on may change), wake-up relationship 1 may have been on the critical path but is not currently on it, or it may have been not on the critical path but is currently on it. The online functional module can predict whether wake-up relationship 1 is on the critical path of the currently constructed wake-up relationship tree based on the aforementioned historical transition matrix information. The probability that wake-up relationship 1 was on the critical path historically reflects the probability that wake-up relationship 1 was on a previously determined critical path. The higher the historical probability of wake-up relationship 1 being on the critical path, the higher the probability that wake-up relationship 1 is on the critical path of the currently constructed wake-up relationship tree. The more times wake-up relationship 1 appears historically, the more frequently the thread in wake-up relationship 1 is awakened, and the higher the probability that the thread in wake-up relationship 1 is a critical dependent thread.

[0196] If wake-up relationship 1 is determined to be on the critical path, the online functional module can instruct the scheduler to increase the priority of the awakened threads in wake-up relationship 1.

[0197] S418. Based on the wake-up relationship tree and key thread information, reverse the critical path and update the historical transition matrix information.

[0198] For example, after determining the end of the wake-up relationship tree in step S415 above, the online functional module constructs the wake-up relationship tree shown in Figure 4G. The online functional module then reverse-engineers the critical path from this wake-up relationship tree. The method for reverse-engineering the critical path can be referred to the description in the foregoing embodiments. Here, we still take thread x1 as the critical thread as an example. According to the wake-up relationship tree shown in Figure 4G, the online functional module can determine that the critical path is thread x1—thread x2—thread x8—thread x1.

[0199] If the critical path previously determined by the online functional module was thread x1—thread x2—thread x4—thread x1, then the online functional module can update the critical path to the critical path shown in Figure 4G (i.e., thread x1—thread x2—thread x8—thread x1). It can be seen that the wake-up relationship corresponding to thread x2 waking up thread x4 was once on the critical path, but it is not on the critical path during the current execution of critical thread x1.

[0200] Specifically, when the critical path is updated to thread x1—thread x2—thread x8—thread x1, the online functional module can update the above critical path wake-up transition matrix. The online functional module can add the row and column corresponding to thread x8 to the critical path wake-up transition matrix. The row and column corresponding to thread x4 can still be retained in the critical path wake-up transition matrix.

[0201] S419, Delete the wake-up relationship tree.

[0202] Once the wake-up relationship tree ends, the online functional module can delete it. The module can then recreate the wake-up relationship tree the next time a wake-up relationship event is received.

[0203] In some embodiments, based on the updated historical transition matrix information in step S418, the online functional module can update the thread protection list. Specifically, the online functional module can calculate the probability of each wake-up relationship in the critical path wake-up transition matrix historically occurring on the critical path, and the corresponding number of times these wake-up relationships appear in the historical wake-up transition matrix. The probability of a wake-up relationship historically occurring on the critical path can be calculated as: the number of times the wake-up relationship appears on the critical path in the critical path wake-up transition matrix ÷ the number of times the wake-up relationship appears in the historical wake-up transition matrix.

[0204] If a wake-up relationship has a probability greater than a probability threshold on the critical path in the past, and the number of times this wake-up relationship appears in the historical wake-up transition matrix is ​​greater than a number threshold, then the online functional module can add the threads other than the critical thread in this wake-up relationship to the thread protection list as critical dependent threads.

[0205] If the probability of a wake-up relationship corresponding to a thread that was previously added to the thread protection list on the critical path is less than or equal to the probability threshold, or if the number of times the wake-up relationship corresponding to the thread is in the historical wake-up transition matrix is ​​less than or equal to the number threshold, the online functional module can remove the thread from the thread protection list.

[0206] This application does not limit the timing of when the online functional module updates the thread protection list. For example, the online functional module can update the thread protection list periodically. Alternatively, the online functional module can update the thread protection list after each wake-up relation tree is constructed and the critical path is derived.

[0207] As can be seen, both the offline and online modes described above can accurately identify threads that are directly and indirectly dependent on the critical thread. This reduces the likelihood of indirect dependent threads being blocked and causing the critical thread to be blocked for an extended period when they are missed. Specifically, in offline mode, the electronic device 100 can directly use the thread protection list sent from the server 200 to identify critical dependent threads. This improves the speed of critical dependent thread identification. In online mode, the electronic device 100 can obtain the latest wake-up relationships between threads in real time based on thread execution, thereby adaptively updating critical dependent threads. Moreover, as the electronic device 100 is used for longer periods, it can identify critical dependent threads more accurately.

[0208] In some embodiments, the electronic device 100 may store general critical thread information. This general critical thread information may include thread names that serve as critical threads in multiple application scenarios. For example, the general critical thread information may include the RS thread. When a critical thread in the aforementioned general critical thread information is detected to be running, the electronic device 100 may identify the critical dependent threads of the critical thread based on the aforementioned offline mode and / or online mode. Then, the electronic device 100 may increase the running priority of the aforementioned critical dependent threads.

[0209] In some embodiments, the critical threads corresponding to different application scenarios may be different. The electronic device 100 can store critical thread information for different application scenarios. The electronic device can determine the critical thread based on the current application scenario, and then identify the critical dependent threads of the critical thread in the current application scenario. The method for identifying application scenarios can be found in the description of the foregoing embodiments.

[0210] For example, when application 1 is running in the foreground of electronic device 100, electronic device 100 can identify the current application scenario as application scenario 1. Key thread information associated with application scenario 1 may include: the RS thread and the UI thread of application 1. The UI thread of application 2 can be used to determine the display content contained in the user interface of application 1. Electronic device 100 can identify the key dependent threads of the UI thread of application 1 and increase the running priority of the key dependent threads of the UI thread of application 1. When the application running in the foreground of electronic device 100 is switched from application 1 to application 2, electronic device 100 can identify the current application scenario change to application scenario 2. Key thread information for application scenario 2 may include the RS thread and the UI thread of application 2. The UI thread of application 2 can be used to determine the display content contained in the user interface of application 2. Electronic device 100 can identify the key dependent threads of the UI thread of application 2 and increase the running priority of the key dependent threads of the UI thread of application 2. Wherein, after the application running in the foreground is switched from application 1 to application 2, application 1 becomes a background application. Electronic device 100 can decrease the running priority of the key dependent threads of the UI thread of application 1. Furthermore, since the RS thread is a critical thread in both application scenario 1 and application scenario 2, the electronic device 100 can set the critical dependent threads of the RS thread to high priority in both application scenario 1 and application scenario 2.

[0211] In some embodiments, the electronic device can combine the offline and online modes described above to identify critical dependent threads. The electronic device 100 can store the thread protection list sent by the server 200 as shown in Figure 3B. The online function module in the electronic device 100 can update the thread protection list based on the actual critical path during thread execution within the electronic device 100, using the thread protection list sent by the server 200 as a basis.

[0212] In some embodiments, the electronic device 100 may store a thread priority configuration file. This application embodiment does not limit the format of the thread priority configuration file. For example, the thread priority configuration file may be an Extensible Markup Language (XML) file.

[0213] Electronic device 100 can determine a thread priority configuration file based on the thread protection list shown in Figure 3B or Figure 4A. The thread priority configuration file may contain priority configuration policies for critical threads and critical dependent threads. The scheduler can increase the priority of critical threads and critical dependent threads based on the aforementioned thread priority configuration file. This allows for the priority allocation of processor resources to critical threads and critical dependent threads.

[0214] When the above thread protection list is updated, the thread priority configuration file can be updated accordingly.

[0215] In some embodiments, the scheduler in the electronic device 100 creates a related thread group (RTG). The RTG provides the ability to optimize the scheduling of a group of threads, supports individual load statistics and prediction for threads within the RTG group, and allows setting priority CPU clusters. This enables the selection of the optimal CPU for threads within the RTG group and the selection of appropriate CPU frequency adjustment points based on the group's load. The scheduler in the electronic device 100 can add critical threads and critical dependent threads to the RTG group and ensure processor resource supply for critical threads and critical dependent threads based on the RTG group's internal mechanisms. The scheduler can update the threads within the RTG group based on updates to the protected thread list. This application does not limit the implementation method of the RTG group.

[0216] The methods described above for prioritizing critical threads and critical dependent threads based on thread priority configuration files or RTG grouping are merely illustrative examples of this application. The electronic device 100 may also employ other methods to prioritize critical threads and critical dependent threads. This application does not limit these methods.

[0217] In some embodiments, electronic devices can group threads. Different processor resource management strategies can be applied to different thread groups to improve the accuracy of processor resource allocation and achieve a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0218] Figure 5 illustrates a schematic diagram of a thread grouping provided in this application.

[0219] As shown in Figure 5, threads in an electronic device can include threads for foreground applications, threads for system services, and threads for background applications. Foreground applications can include applications running in the foreground of the electronic device. The electronic device can display the user interface of the foreground application on the screen or play audio from the foreground application. Foreground applications can receive user actions and interact with the user. System services can include programs that perform specified system functions to support the operation of other applications. System services typically run in the background. For example, system services may include, but are not limited to: services that manage open application windows on the device, power management services, services that provide location information, network connectivity services, etc. Background applications can include applications that run in the background of the electronic device, excluding system services. When an application runs in the background, it typically cannot interact with the user. In some embodiments, a foreground application becomes a background application after being moved to the background; a background application can also be brought to the foreground and become a foreground application. For example, an electronic device runs a shopping application in the foreground (i.e., displays the user interface of the shopping application) and an instant messaging application in the background. In response to an operation that brings up the user interface of the instant messaging application, the electronic device can display the user interface of the instant messaging application on the screen and cancel the display of the user interface of the shopping application. In this way, shopping applications change from front-end applications to back-end applications, and instant messaging applications change from back-end applications to front-end applications.

[0220] In some embodiments, electronic devices can divide threads into different service groups based on parameters such as the foreground / background running status of the application or service to which the thread belongs, and the type of task the thread needs to perform.

[0221] For example, an electronic device can categorize foreground application threads, system service threads, and background application threads into one or more of the following service groups: foreground services, foreground-related services, system-resident services, system-delayable services, background-delayable services, and background insignificant services. Foreground services may include threads of foreground applications. Foreground-related services may include a portion of the system service threads that need to be invoked by the foreground service. System-resident services may include threads in the system service that need to run persistently for a long time. System-delayable services may include threads in the system service that can run with a delay. Background-delayable services may include threads in the background application that can run with a delay. Background insignificant services may include threads in the background application that are not part of the background-delayable services.

[0222] Optionally, the aforementioned foreground services and related foreground services can also be grouped into a single service group. Similarly, the aforementioned system-delayable services and background-delayable services can also be grouped into a single service group. System-delayable services and background-delayable services may include, but are not limited to: threads for upload / download services, threads for application compilation and installation services, threads for software upgrade and update services, etc. This application does not limit the method for identifying system-delayable services and background-delayable services.

[0223] In some embodiments, the threads in one or more of the aforementioned service groups can be dynamically changed. For example, when application 1 is running in the foreground and application 2 is running in the background, the threads of application 1 can be assigned to a foreground service, and the threads of application 2 can be assigned to a background deferred service or a background insignificant service. When application 2 changes to running in the foreground and application 1 changes to running in the background, the threads of application 1 can be moved from the foreground service to a background deferred service or a background insignificant service, and the threads of application 2 can be moved to the foreground service. The threads in the foreground associated service can also change from threads associated with application 1 to threads associated with application 2.

[0224] In some embodiments, the electronic device can also divide threads into different CPU groups based on the urgency of allocating processor resources to the threads. The electronic device can divide the CPU groups based on the aforementioned service groups. The more important a thread is or the higher its user sensitivity, the higher the urgency of allocating processor resources to that thread by the electronic device. Higher user sensitivity to a thread means that it is more easily noticed by the user if the thread is blocked or delayed.

[0225] For example, the electronic device can classify the aforementioned service groups into one or more of the following CPU groups: top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group. The CPU groups, ordered from highest to lowest importance in allocating processor resources to threads, can be: top-level thread group, secondary thread group, normal system thread group, normal background thread group, and restricted thread group. The top-level thread group can include threads in foreground services. The top-level thread group can also be called the top-app group. The secondary thread group can include threads in foreground related services. The secondary thread group can also be called the foreground group. The normal system thread group can include threads in system resident services. The normal system thread group can also be called the system group. The restricted thread group can include threads in system time-delayed services and background time-delayed services. The restricted thread group can also be called the limit-background group. The normal background thread group can include threads in background unimportant services. The normal background thread group can also be called the background group. The names of the aforementioned CPU groups are merely illustrative examples of this application and should not be construed as limiting this application.

[0226] Optionally, the top-level thread group and the secondary thread group can also be grouped into one CPU group. The normal system thread group, the restricted thread group, and the normal background thread group can also be grouped into one CPU group. Alternatively, the normal system thread group and the normal background thread group can be grouped into one CPU group.

[0227] In some embodiments, the threads described above may have priorities. A thread's priority determines its importance when it is scheduled. Higher-priority threads can be scheduled more frequently when competing for processor resources to ensure timely responses.

[0228] Electronic devices may include a real-time (RT) scheduler and a completely fair scheduler (CFS). The RT scheduler and the CFS scheduler can employ different scheduling strategies to schedule threads. The RT scheduler and the CFS scheduler can be used to schedule threads with different priorities. For example, the CFS scheduler can be used to schedule threads with priorities in priority range 1. The RT scheduler can be used to schedule threads with priorities in priority range 2. This application does not limit the values ​​of priority range 1 and priority range 2. For example, priority range 1 can be [1, 40]. Priority range 2 can be [41, 139]. That is, if a thread's priority is greater than or equal to 1 and less than or equal to 40, then the thread can be scheduled by the CFS scheduler. If a thread's priority is greater than or equal to 41 and less than or equal to 139, then the thread can be scheduled by the RT scheduler.

[0229] The CFS scheduler can be used to determine the processor resource requirements of threads based on parameters such as thread type and thread priority, and then allocate processor resources to each thread as needed, so as to achieve a relatively fair allocation of processor resources to each thread.

[0230] The RT scheduler can be used to schedule threads based on their priority. The highest priority thread will acquire processor resources first. Furthermore, high-priority threads can preempt lower-priority resources.

[0231] In the CPU groupings described above, the top-level thread group and the secondary thread group can contain threads with priorities in priority range 1 and threads with priorities in priority range 2. Threads in the top-level thread group and the secondary thread group with priorities in priority range 1 can be scheduled by the CFS scheduler. Threads in the top-level thread group and the secondary thread group with priorities in priority range 2 can be scheduled by the RT scheduler. Threads in the normal system thread group, the restricted thread group, and the normal background thread group can all be threads with priorities in priority range 1; therefore, all threads in these groups can be scheduled by the CFS scheduler.

[0232] In some embodiments, the electronic device can identify critical threads, critical dependent threads, and non-critical threads. For details, please refer to the description in the foregoing embodiments. If the electronic device identifies a thread in any of the following service groups as a critical dependent thread: a system resident service, a system time-delayable service, a background time-delayable service, or a background unimportant service, the electronic device can move this thread from the ordinary system thread group / restricted thread group / ordinary background thread group to the top-level thread group / secondary thread group. Optionally, if the electronic device identifies a thread in a foreground service or a foreground associated service as a non-critical dependent thread, the electronic device can move this thread from the top-level thread group / secondary thread group to the ordinary system thread group / restricted thread group / ordinary background thread group.

[0233] It should be noted that the above-described service grouping and CPU grouping of threads are merely illustrative examples of this application and should not be construed as limiting the application. Electronic devices may also divide threads into more or fewer service groups and more or fewer CPU groups.

[0234] In some embodiments, based on the CPU grouping shown in FIG5 above, the electronic device can manage the CPU time slices allocated to threads by grouping.

[0235] Figure 6A illustrates an exemplary flowchart of a method for grouping and managing CPU time slices.

[0236] S611. Initialize the ratio of CPU weights in each group of CPU groups to equal weights. The CPU weight corresponding to a group is used to indicate the length of the CPU time slice allocated by the scheduler to the threads in that group.

[0237] In some embodiments, the CPU groups of threads may include a top-level thread group, a secondary thread group, a normal system thread group, a restricted thread group, and a normal background thread group. The electronic device can initialize the CPU weights of the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group to 1:1:1:1:1. As shown in Figure 6B, the CPU time slice ratio for each of the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group can be 20%. The length of the CPU time slice allocated to a CPU group is: total CPU time * CPU time slice ratio of the CPU group. The total CPU time can be the total duration of CPU time slices that the scheduler can allocate, i.e., the size of the scheduler's scheduling region. The scheduling region can also be called a scheduling cycle.

[0238] The scheduler can allocate CPU time slices to multiple threads within a CPU group based on the length of the CPU time slice allocated to that group. The CPU time slice lengths allocated to multiple threads within a CPU group can be the same or different.

[0239] It should be noted that the CPU weight ratio of the aforementioned groups can be used as the basis for the CFS scheduler to allocate CPU time slices to the threads it manages. Specifically, the CPU time slice ratio of the top-level thread group can be the proportion of CPU time slices occupied by threads managed by the CFS scheduler within the CFS scheduler's scheduling area. Similarly, the CPU time slice ratio of the second-level thread group can be the proportion of CPU time slices occupied by threads managed by the CFS scheduler within the CFS scheduler's scheduling area. The CPU time slices of threads managed by the RT scheduler in both the top-level and second-level thread groups can be allocated by the RT scheduler, and are not determined by the CPU weights of the aforementioned groups.

[0240] S612. When a foreground event is detected, calculate the CPU load rate of the foreground group, which includes the top-level thread group and the secondary thread group.

[0241] Foreground events can be used to indicate events corresponding to tasks performed by foreground applications, including but not limited to: application startup events, audio / video switching events, page update or switching events, etc. The aforementioned page update or / or switching events may include events where the foreground application changes (e.g., the user interface displayed on the electronic device changes from the user interface of application 1 to the user interface of application 2). This application does not limit the method for detecting foreground events.

[0242] When a foreground event is detected, the electronic device can calculate the CPU load rate of the foreground group. The CPU load of a thread can represent the number of times a thread needs to perform CPU operations. The more tasks a thread needs to execute, the higher its CPU load. This application does not limit the method for detecting the CPU load of a thread. For example, the CPU load can be calculated based on the CPU window-assist load tracing (WALT) scheduling cycle.

[0243] In some embodiments, the CPU load rate of the foreground group may specifically include: the proportion of the CPU load of the threads managed by the CFS scheduler in the top-level thread group and the secondary thread group to the CPU load of all threads managed by the CFS scheduler.

[0244] Alternatively, the CPU load rate of the foreground group can include: the proportion of the CPU load of all threads in the top-level thread group and the second-level thread group to the CPU load of all threads in the electronic device.

[0245] S613. Adjust the CPU weight ratio of each group in the CPU group according to the change of CPU load rate of the foreground group.

[0246] In some embodiments, when the CPU load rate of the foreground group increases, the electronic device may proportionally increase the proportion of CPU time slices allocated to the foreground group.

[0247] As shown in Figure 6B, when the CPU load rate of the foreground group increases by 10%, the CPU time slice ratio of the foreground group can increase by 10% accordingly. It can be seen that before the CPU load rate of the foreground group increases, the combined CPU time slice ratio of the top-level thread group and the secondary thread group is 40%. After the CPU load rate of the foreground group increases by 10%, the combined CPU time slice ratio of the top-level thread group and the secondary thread group is 50%, an increase of 10%. Correspondingly, after the CPU load rate of the foreground group increases by 10%, the CPU time slice ratio of the non-foreground group (i.e., the normal system thread group, the restricted thread group, and the normal background thread group) decreases from 60% to 50%.

[0248] In some embodiments, since the foreground group includes a top-level thread group and a secondary thread group, the electronic device can increase the CPU time slice ratio of the top-level thread group and the secondary thread group based on the increase in the CPU time slice ratio of the foreground group. For example, the increase in the CPU time slice ratio of the top-level thread group and the secondary thread group can be the same. If the CPU time slice ratio of the foreground group increases by 10%, the CPU time slice ratio of both the top-level thread group and the secondary thread group can increase by 5% (i.e., both increase from 20% to 25%). Alternatively, the electronic device can determine the CPU time slice ratio of the top-level thread group and the secondary thread group based on the CPU load of the top-level thread group and the CPU load of the secondary thread group. If the CPU load of the top-level thread group is greater than the CPU load of the secondary thread group, the increase in the CPU time slice ratio of the top-level thread group can be greater than the increase in the CPU time slice ratio of the secondary thread group. Similarly, since the non-foreground group includes a normal system thread group, a restricted thread group, and a normal background thread group, the electronic device can reduce the CPU time slice ratio of the normal system thread group, the restricted thread group, and the normal background thread group based on the decrease in the CPU time slice ratio of the non-foreground group. The CPU time slice ratios for normal system thread groups, restricted thread groups, and normal background thread groups can be reduced equally or unevenly.

[0249] As shown in Figure 6B, when the load rate of the foreground group increases by 10%, the electronic device can change the CPU weights of the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group from 1:1:1:1:1 to 3:3:2:2:2. The electronic device's CFS scheduler can allocate CPU time slices to threads in each CPU group according to the 3:3:2:2:2 CPU weights.

[0250] In some embodiments, when the CPU load rate of the foreground group decreases, the electronic device can proportionally reduce the CPU time slice ratio of the foreground group. The method for proportionally reducing the CPU time slice ratio of the foreground group can refer to the method for proportionally increasing the CPU time slice ratio of the foreground group described above. It will not be repeated here.

[0251] This application does not limit the method by which the electronic device adjusts the CPU weight ratio based on changes in the CPU load rate of the foreground group. Besides proportionally increasing or decreasing the CPU time slice ratio of the foreground group, the electronic device can also increase or decrease the CPU time slice ratio of the foreground group at different ratios. For example, if the CPU load rate of the foreground group increases by X%, the electronic device can increase the CPU time slice ratio of the foreground group by 2X%. When the CPU load rate of the foreground group decreases by X%, the electronic device can decrease the CPU time slice ratio of the foreground group by 0.5X.

[0252] Understandably, when the aforementioned foreground events occur, the CPU load of threads in the foreground group may change. When the electronic device detects a foreground event, adjusting the CPU weight ratio based on the change in the CPU load rate of the foreground group can reduce the number of times the electronic device detects the CPU load rate of the foreground group, thereby improving the efficiency of managing the CPU time slices of each thread group.

[0253] In some embodiments, beyond the detection of foreground events described above, the electronic device can also calculate the CPU load rate of the foreground group at other times. For example, the electronic device can periodically calculate the CPU load rate of the foreground group and adjust the CPU weight ratio as the CPU load rate of the foreground group changes, thereby adjusting the CPU time slice length allocated to each thread group. This application embodiment does not limit the timing of the electronic device calculating the CPU load rate of the foreground group and adjusting the CPU weight ratio.

[0254] S614. When the front-end event ends, restore the CPU weights of each group in the CPU group to their initial weights.

[0255] The end of a foreground event indicates that the task corresponding to the foreground event has been completed. When the foreground time ends, the electronic device can restore the CPU weights of each group in the CPU group to their initial weights, such as proportional weights.

[0256] As the above method shows, threads in the foreground group are those with high user sensitivity. Based on this CPU grouping, electronic devices can suppress processor resources allocated to threads outside the foreground group when the CPU load rate of the foreground group is high, providing longer CPU time slices for threads in the foreground group. This allows foreground threads to obtain more processor resources when the workload is heavy, enabling them to complete tasks faster and providing a smooth user experience. Furthermore, when the CPU load rate of the foreground group decreases, the electronic device can provide longer CPU time slices to threads outside the foreground group, allowing their tasks to execute quickly. This method, by grouping and managing CPU time slices for different CPU groups, effectively improves processor resource utilization efficiency, ensuring smooth device operation while allowing threads outside the foreground group to continue running.

[0257] In some embodiments, based on the CPU groups shown in FIG5 above, the electronic device can suppress the bandwidth quota of the processor resources obtained by different CPU groups.

[0258] Bandwidth quota is a mechanism that limits CPU execution time slices on an absolute time basis. As described in the previous embodiments, electronic devices can allocate CPU time slices to threads. Bandwidth quota can represent that within the CPU time slice allocated to a thread, the thread is only allowed to run for a fixed time quota. When the time quota is exceeded, the thread will be restricted from running. After obtaining the next CPU time slice, the thread can continue to run within the corresponding time quota.

[0259] Figure 7A illustrates an exemplary flowchart of a method for bandwidth quota suppression based on thread grouping.

[0260] S711. Obtain the overall load and / or temperature of the electronic device.

[0261] Overall system load represents the proportion of CPU computing power consumed by all threads running in an electronic device over a given period of time, relative to the maximum computing power the CPU can provide. A higher overall system load indicates greater CPU computing power consumption, and consequently, faster power consumption and temperature rise of the electronic device.

[0262] Device temperature can be the temperature of the electronic device's casing, such as the temperature of the back cover. Alternatively, device temperature can also be the temperature of the electronic device's processor.

[0263] S712. Determine the processor's bandwidth quota based on the overall system load and / or device temperature, and apply bandwidth quotas to one or more groups among the normal system thread group, restricted thread group, and normal background thread group based on the bandwidth quota.

[0264] In some embodiments, the electronic device may store a correspondence between overall load and / or device temperature and bandwidth quota. Based on this correspondence, the electronic device can determine the current bandwidth quota of the processor.

[0265] The relationship between the overall load and the bandwidth quota can be found in Table 4 below.

[0266] Table 4

[0267] Table 4 shows that when the overall system load is greater than 90%, the bandwidth quota can be 10%. A 10% bandwidth quota means that the electronic device allows a thread to run for 10% of its CPU time slice. For example, if the electronic device allocates a CPU time slice of 100ms to a thread, then the time quota for the thread is 10ms. When the overall system load is greater than 80% and less than or equal to 90%, the bandwidth quota can be 30% (i.e., a time quota of 30% of the corresponding CPU time slice). When the overall system load is greater than 60% and less than or equal to 80%, the bandwidth quota can be 50% (i.e., a time quota of 50% of the corresponding CPU time slice). It can be seen that the higher the overall system load, the lower the bandwidth quota, and the greater the degree of bandwidth quota suppression imposed on threads by the electronic device.

[0268] The relationship between equipment temperature and bandwidth quota can be found in Table 5 below.

[0269] Table 5

[0270] As shown in Table 5, when the device temperature is greater than 46℃, the bandwidth quota can be 10%. When the device temperature is greater than 42℃ and less than or equal to 46℃, the bandwidth quota can be 30%. When the device temperature is greater than 38℃ and less than or equal to 42℃, the bandwidth quota can be 50%. It can be seen that the higher the device temperature, the lower the bandwidth quota, and the greater the degree of bandwidth quota suppression of threads by electronic devices.

[0271] Tables 4 and 5 above are merely illustrative examples of this application and should not be construed as limiting the application. In addition to the above table lookup methods, electronic devices can also determine the bandwidth quota corresponding to the current overall load or device temperature based on relevant models or calculation formulas.

[0272] In some embodiments, the electronic device can determine the bandwidth quota by combining the overall load and the device temperature. For example, based on the correspondence between overall load and bandwidth quota shown in Table 4 above, and the correspondence between device temperature and bandwidth quota shown in Table 5 above, the electronic device can use the smaller value between the bandwidth quota corresponding to the current overall load and the bandwidth quota corresponding to the current device temperature for bandwidth quota allocation, or the electronic device can use the average value between the bandwidth quota corresponding to the current overall load and the bandwidth quota corresponding to the current device temperature for bandwidth quota allocation. This application does not limit the method for determining the bandwidth quota based on overall load and device temperature.

[0273] When the overall load and / or device temperature change, the electronic device can dynamically adjust the degree of bandwidth quota suppression on the thread.

[0274] In some embodiments, the electronic device can apply bandwidth quotas to one or more groups among the general system thread group, the restricted thread group, and the general background thread group. Since the threads in the top-level thread group and the secondary thread group shown in Figure 5 are relatively important threads, the electronic device may not need to apply bandwidth quotas to the top-level thread group and the secondary thread group.

[0275] In some embodiments, when the overall load is less than a preset threshold (e.g., 60%), and / or the device temperature is less than a preset threshold (e.g., 38°C), the electronic device may stop applying bandwidth quotas to the normal system thread group, the restricted thread group, and the normal background thread group. This application embodiment does not limit the value of the above threshold.

[0276] As described above, electronic devices can apply bandwidth quotas to threads in non-foreground groups based on overall system load and / or device temperature. Bandwidth quotas can reduce the overall system load per unit time. Specifically, the higher the overall system load, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups; similarly, the higher the device temperature, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups. This bandwidth quota suppression method can control the overall system load and device temperature of the electronic device, reducing the impact of threads in non-foreground groups on the operation of threads in the foreground group when the overall system load is too high, and also reducing the risk of excessively high device temperatures.

[0277] Figure 7B illustrates an exemplary flowchart of another method for bandwidth quota suppression based on thread grouping.

[0278] S721: Persistently allocate bandwidth quotas to the restricted thread group based on the processor's bandwidth quota of 1.

[0279] The bandwidth quota of 1 can be preset. This application embodiment does not limit the value of the bandwidth quota of 1. For example, the bandwidth quota of 1 can be 10%.

[0280] In some embodiments, the electronic device can identify threads in a restricted thread group that are delayable and have high CPU load. The CPU load of a thread can be referred to in the description of Figure 6A above. Threads with high CPU load may include threads whose CPU load exceeds a preset load threshold. The electronic device can use a bandwidth quota of 1 to persistently allocate bandwidth to the aforementioned delayable threads with high CPU load.

[0281] S722. Determine the processor's bandwidth quota 2 based on the overall system load and / or device temperature, and apply bandwidth quotas to the normal system thread group and the normal background thread group based on the bandwidth quota 2.

[0282] The method for determining the bandwidth quota based on the overall load and / or equipment temperature can be found in the description of the method shown in Figure 7A above.

[0283] As demonstrated by the methods described above, electronic devices can persistently suppress bandwidth quotas for threads with high CPU load and low latency to reduce sudden load spikes. Furthermore, electronic devices can dynamically suppress bandwidth quotas for threads outside the restricted thread groups in non-foreground groups based on overall system load and / or device temperature. This allows for control over the overall system load and temperature of the electronic device, reducing the impact of non-foreground threads on foreground threads when the overall system load is too high, and also mitigating the risk of overheating.

[0284] In some embodiments, the electronic device can persistently allocate bandwidth quotas to ordinary system thread groups, restricted thread groups, and ordinary background thread groups according to a preset bandwidth quota. This application embodiment does not limit the value of the preset bandwidth quota.

[0285] In some embodiments, priority inversion may occur during thread execution. Priority inversion can mean that when a high-priority thread needs to access a shared resource, that resource is already held by a low-priority thread, and this low-priority thread may be preempted by other medium-priority threads while accessing the shared resource, thus causing the high-priority thread to be blocked by many lower-priority threads.

[0286] To address the priority inversion issue, electronic devices can set up critical sections and add threads that are dependent on by the foreground group from non-foreground groups to these critical sections. Electronic devices can achieve faster execution of threads within critical sections through one or more of the following measures: increasing the priority of threads in the critical section, removing bandwidth quota restrictions on threads in the critical section, increasing the CPU time slice length for threads in the critical section, etc.

[0287] Figure 8 illustrates an exemplary flowchart of a processor resource allocation method.

[0288] S811. When it is detected that thread 1 in the foreground group is waiting for the binder / thread lock held by thread 2 in the non-foreground group to be released, thread 2 is marked as a critical section. The non-foreground group includes the normal system thread group, the restricted thread group, and the normal background thread group.

[0289] Binder is a mechanism for inter-process communication, allowing data transfer and method calls between different processes. In some embodiments, if thread 1 needs to use the result of thread 2 during its execution, thread 1 can wake up thread 2 based on the binder. At this time, thread 2 holds the binder that thread 1 depends on, and thread 1 needs to wait for thread 2 to release the binder before it can continue running.

[0290] Thread locks can be used to lock shared resources to prevent multiple threads from accessing or modifying them simultaneously. When multiple threads need to modify or access a shared resource, a thread lock ensures that only one thread can perform read and write operations on the shared resource at a time. In some embodiments, if thread 2 holds a thread lock on a shared resource, thread 1 must wait for thread 2 to release the lock when it needs to access the shared resource.

[0291] In some embodiments, the electronic device can detect whether a thread in the foreground group is waiting for a binder / thread lock held by a thread in a non-foreground group to be released. As can be seen from the foregoing embodiments, the electronic device may perform operations such as CPU time slice reduction and / or bandwidth quota suppression on threads in non-foreground groups. If a thread in the foreground group is waiting for a binder / thread lock held by a thread in a non-foreground group to be released, the aforementioned CPU time slice reduction and / or bandwidth quota suppression may cause the thread in the foreground group to be blocked for a long time, affecting the smoothness of the electronic device's operation.

[0292] This example illustrates the scenario where thread 1 in the foreground group waits for the binder / thread lock held by thread 2 in the non-foreground group to be released. The electronic device can label thread 2 as a critical section. Labeling thread 2 as a critical section indicates that thread 2 is added to the critical section. This application does not limit the implementation method of the aforementioned critical section label.

[0293] S812. Perform one or more of the following operations on threads with critical section labels: increase priority, increase CPU time slice length, or remove bandwidth quota suppression.

[0294] In some embodiments, the CFS scheduler in the electronic device may perform one or more of the following operations on thread 2: increase priority, increase CPU time slice length, and remove bandwidth quota suppression.

[0295] Increasing the priority of thread 2 can reduce the likelihood of processor resources being preempted by other higher-priority threads while thread 2 is running. This can also reduce the possibility of threads with lower priority than thread 1 starting to run before thread 1 due to their higher priority than thread 2, thus preventing thread 1 from being blocked for a long time while waiting for thread 2 to release the binder / thread lock.

[0296] Increasing the CPU time slice length and removing bandwidth quota suppression can both enable thread 2 to run quickly, so that thread 2 can release the binder / lock that thread 1 depends on as soon as possible.

[0297] S813. When thread 2 releases the binder / thread lock, remove the critical section label of thread 2.

[0298] When thread 2 releases the binder / thread lock that thread 1 depends on, the electronic device can remove the critical section label from thread 2. Removing the critical section label from thread 2 indicates that thread 2 is being removed from the critical section. When the critical section label of thread 2 is removed, the CFS scheduler in the electronic device can restore the priority and CPU time slice length of thread 2 to their initial state (i.e., the state before thread 2 was added to the critical section). Furthermore, the electronic device can apply bandwidth quota suppression to thread 2 according to the method shown in Figure 7A or Figure 7B above.

[0299] As described above, when threads in a foreground group (e.g., top-level thread group / secondary thread group) depend on threads in a non-foreground group (e.g., normal system thread group / restricted thread group / normal background thread group), the electronic device can temporarily increase the priority of the non-foreground thread that is depended on by the foreground group, increase the CPU time slice length of that thread, and remove bandwidth quota restrictions on that thread. Furthermore, it can move the non-foreground thread that is depended on by the foreground group to the foreground group where the required response and execution time is available. Compared to changing the thread group of the dependent thread, the above method of setting critical sections can more efficiently reduce priority inversion and improve the smoothness of thread execution in the foreground group.

[0300] In some embodiments, based on the non-critical threads identified in the foregoing embodiments, the electronic device can suppress the CPU frequency of the non-critical threads.

[0301] Figure 9 illustrates an exemplary flowchart of a method for suppressing the CPU frequency of non-critical threads.

[0302] S911. Determine the maximum CPU frequency for non-critical threads based on parameters such as overall system load and / or device temperature.

[0303] The overall load and device temperature can be referenced in Figure 7A above. Non-critical threads can include threads running the electronic device other than critical threads and critical dependent threads. The method for identifying critical dependent threads can be referenced in Figures 3A and 3B above, or in Figures 4A and 4B above.

[0304] In some embodiments, the electronic device may store a correspondence between the overall load and / or device temperature and the maximum CPU frequency corresponding to non-critical threads.

[0305] The relationship between overall system load and the maximum CPU frequency corresponding to non-critical threads can be found in Table 6 below.

[0306] Table 6

[0307] The relationship between device temperature and the maximum CPU frequency for non-critical threads can be found in Table 7 below.

[0308] Table 7

[0309] Tables 6 and 7 above are merely illustrative examples of this application and should not be construed as limiting this application.

[0310] It should be noted that the higher the overall system load, the lower the maximum CPU frequency for non-critical threads, and the greater the degree of CPU frequency suppression for non-critical threads by the electronic device. Similarly, the higher the device temperature, the lower the maximum CPU frequency for non-critical threads, and the greater the degree of CPU frequency suppression for non-critical threads by the electronic device.

[0311] In some embodiments, the electronic device can determine the maximum CPU frequency for non-critical threads by combining overall system load and device temperature. When the overall system load and / or device temperature change, the electronic device can dynamically adjust the CPU frequency suppression level for non-critical threads.

[0312] Beyond overall system load and device temperature, electronic devices can also determine the maximum CPU frequency for non-critical threads based on other factors. For example, an electronic device can also determine the maximum CPU frequency for non-critical threads based on its current power consumption. Specifically, the higher the current power consumption of the electronic device, the lower the maximum CPU frequency for non-critical threads.

[0313] S912. When running non-critical threads, the CPU operating frequency is controlled below the maximum CPU frequency corresponding to the non-critical thread.

[0314] In some embodiments, when running non-critical threads, the CPU operating frequency may vary dynamically, and the CPU operating frequency shall not exceed the maximum CPU frequency corresponding to the non-critical thread.

[0315] S913. When one or more non-critical threads are identified as critical dependent threads, the CPU frequency suppression on these one or more non-critical threads is lifted.

[0316] As shown in Figures 4A and 4B, the electronic device can detect critical dependent threads in real time based on an online mode. When one or more threads are detected to have changed from non-critical to critical, the electronic device can operate on these threads without controlling the CPU frequency below the maximum CPU frequency corresponding to the non-critical threads (i.e., releasing CPU frequency suppression). The threads that change from non-critical to critical can include threads newly added to the thread protection list when the thread protection list shown in Figure 4A is updated.

[0317] In some embodiments, when a thread changes from a critical dependent thread to a non-critical thread, the electronic device can control the CPU's operating frequency below the maximum CPU frequency corresponding to the non-critical thread while this thread is running (i.e., suppress the CPU frequency of this thread). The thread that changes from a critical dependent thread to a non-critical thread may include threads removed from the thread protection list when the thread protection list shown in Figure 4A is updated.

[0318] As can be seen from the above methods, by suppressing the CPU frequency of non-critical threads, electronic devices can save power and reduce the rapid overheating of electronic devices while keeping non-critical threads running.

[0319] In some embodiments, the electronic device may further divide the threads within the electronic device into Group 1 and Group 2. Group 1 may include key threads in the current application scenario and their critical dependent threads, as well as threads of the foreground application. Group 2 may include other threads outside of Group 1. The electronic device may calculate the CPU load rate of Group 1 and adjust the ratio of CPU weights between Group 1 and Group 2 based on changes in the load rate of Group 1, thereby adjusting the CPU time slice length of threads in Group 1 and Group 2 (see the method shown in Figure 6A above for details).

[0320] Optionally, the electronic device can allocate CPU bandwidth quotas to the threads in group 2 (see the method shown in Figure 7A above). The electronic device can also identify delayable threads in group 2 and allocate persistent CPU bandwidth quotas to these delayable threads.

[0321] Optionally, the electronic device can also detect whether a thread in group 1 is waiting for the release of a binder / thread lock held by a thread in group 2. For example, if thread a1 in group 1 is waiting for the release of a binder / thread lock held by thread a2 in group 2, the electronic device can add thread a2 to the critical section (see Figure 8 above for details).

[0322] Optionally, the electronic device can suppress the frequency of the threads in group 2 (see Figure 9 above for details).

[0323] In some embodiments, the electronic device can dynamically adjust the frequency of critical threads and critical dependent threads in the electronic device to achieve precise allocation of processor resources to critical threads and critical dependent threads.

[0324] In subsequent embodiments of this application, the dynamic frequency modulation method is specifically described using a thread related to drawing frames (hereinafter referred to as the drawing frame thread) as an example. Here, a drawing frame can refer to the user interface displayed by the electronic device. The number of times the electronic device refreshes and draws an image on the screen per unit time can be determined by the refresh rate of the electronic device's screen. For example, if the refresh rate of the electronic device is 120 Hz, then the electronic device can refresh the screen once every 8.3 ms, that is, draw one frame of image every 8.3 ms. Threads related to drawing frames may include the UI thread, the RS thread, critical dependency threads that the UI thread depends on, and critical dependency threads that the RS thread depends on.

[0325] Figure 10 illustrates a schematic diagram of a frequency modulation curve. An electronic device can dynamically modulate the frame drawing thread according to the frequency modulation curve shown in Figure 10.

[0326] The frequency modulation function corresponding to the frequency modulation curve shown in Figure 10 can be found in the following formula (1):

[0327] Here, u(t) represents the CPU computing power provided to the thread at a certain moment. maxUtil represents the maximum computing power that the CPU can provide. For example, maxUtil can be 1024. Time represents the duration that the electronic device has been drawing a frame of an image, that is, the duration from the moment the frame drawing instruction (such as the frame synchronization signal) is issued to the current moment. deadline represents the frame duration or frame period, which can be determined by the screen refresh rate. For example, if the screen refresh rate is 120Hz, the deadline can be 8.3ms. If the screen refresh rate is 60Hz, the deadline can be 16.67ms. margin represents the duration of each frame in history for completing its corresponding frame task. For example, margin can be a cumulative amount determined by the historical average runtime. If a historical frame times out (e.g., the frame drawing task is not completed within 8.3ms), the margin will increase. If the historical frame runtime is shortened (e.g., the frame drawing task is completed in less than 8.3ms), the margin will decrease.

[0328] In the coordinate system shown in Figure 10, the vertical axis can be u(t), and the horizontal axis can be the aforementioned Time. It can be seen that, with a fixed margin, the CPU computing power provided to the frame-drawing thread during the process of drawing one frame of an image by the electronic device increases linearly with time. The electronic device can store a frequency-based computing power table. Based on the computing power determined by the aforementioned frequency modulation curve, the electronic device can adjust the CPU frequency.

[0329] The frequency point computing power table can be found in Table 8 below.

[0330] Table 8

[0331] In some embodiments, the CPU of an electronic device may include multiple CPU cores. Different CPU cores may operate at different frequencies. Different CPU cores may run different threads simultaneously, handling different tasks. The aforementioned frequency-based computing power table may include the frequencies of different CPU cores under a given CPU computing power. Thus, the electronic device can adjust the frequency of the CPU core running that thread based on the computing power provided to that thread.

[0332] In addition to the frequency computing power table mentioned above, electronic devices can also adjust the CPU frequency according to computing power in other ways.

[0333] As shown in the frequency modulation curves in Figure 10, the electronic device provides less computing power to the frame-drawing thread in the early stages of drawing an image frame, resulting in a slower task completion speed. If the frame-drawing thread has a large workload to complete for drawing one image frame, the task may not be completed in time, leading to dropped frames. Furthermore, the electronic device provides more computing power to the frame-drawing thread in the background of drawing an image frame. If the workload to complete for drawing one image frame is small, the task may have already been completed, while the electronic device continues to provide high computing power, resulting in a waste of processor resources. Therefore, the frequency modulation curves shown in Figure 10 are not conducive to the efficient utilization of processor resources.

[0334] In order to improve the utilization efficiency of processor resources, electronic devices can perform dynamic frequency modulation based on the frequency modulation function shown in the following formula (2).

[0335] Where kk is the slope parameter, which can be used to change the slope of the frequency modulation function. α is the curvature parameter, which can be used to change the curvature of the frequency modulation function.

[0336] In some embodiments, the server can perform simulations based on historical CPU load data to determine the values ​​of kk and α under the optimal frequency modulation function. The server can then send the optimal frequency modulation function to the user-side electronic device. The user-side electronic device can use the optimal frequency modulation function to dynamically adjust the frequency of critical threads such as the frame-drawing thread and critical dependent threads. The method for determining the optimal frequency modulation function provided in this application is described in detail below.

[0337] Figure 11A illustrates a schematic diagram for determining the optimal frequency modulation function.

[0338] As shown in Figure 11A, server 200 may include a task generation module and a frequency modulation simulator.

[0339] The task generation module can generate a task data list based on historical CPU load data and frequency computing power tables. Historical CPU load data can include thread execution duration and CPU frequency during thread execution. In some embodiments, historical CPU load data can be trace files generated by tracking the running threads of an electronic device. For example, historical CPU load data can include thread execution data (such as runtime and CPU frequency) after one or more applications are launched on an electronic device over a period of time (e.g., 12 hours, 24 hours, etc.).

[0340] The task data list can include the frame task volume of critical threads and critical dependent threads. For example, the historical CPU load data mentioned above can include the multi-frame task volume of the drawing thread drawing multiple frames of images. Each frame task volume can correspond to a frame sequence number. The frame task volume for drawing one frame of an image can be calculated from the runtime of the drawing thread executing this frame task volume and the computing power corresponding to the CPU frequency.

[0341] The task generation module can send a list of task data to the frequency modulation simulator.

[0342] The frequency modulation simulator can determine the optimal frequency modulation function based on the task data list and CPU energy efficiency curve.

[0343] CPU energy efficiency curves can be used to reflect the relationship between CPU computing power and power consumption during operation. Different CPU models may have different CPU energy efficiency curves.

[0344] Figure 11B illustrates a schematic diagram of a CPU energy efficiency curve.

[0345] As shown in Figure 11B, the horizontal axis *u* of the CPU energy efficiency curve represents the computing power provided by the CPU, and the vertical axis *g(u)* represents the power consumption of the CPU at a certain computing power, that is, the power consumption required for the CPU to complete a unit of task. It can be seen that the greater the computing power provided by the CPU, the higher the CPU power consumption. Furthermore, the CPU energy efficiency curve is a convex curve. This indicates that as the computing power provided by the CPU increases, the increase in CPU power consumption is greater for every unit increase in computing power.

[0346] For example, the optimal energy efficiency portion of the CPU energy efficiency curve can be the part corresponding to the computing power between u1 and u2, as shown in Figure 11B. It is understandable that in the part of the CPU energy efficiency curve where the computing power is less than u1, although the CPU power consumption is low, the CPU computing power is too small, leading to slow thread execution and sluggish device performance. In the part of the CPU energy efficiency curve where the computing power is greater than u2, the increase in CPU power consumption for each unit increase in computing power is too high, meaning the power consumption cost of increasing computing power is too great. Therefore, the computing power provided by the electronic device within the range of u1 to u2 is beneficial for fast thread execution and allows for the execution of more tasks with less power consumption, saving the electronic device's power. The values ​​of u1 and u2 mentioned above are related to the functional expression of the CPU energy efficiency curve. This application does not limit the values ​​of u1 and u2 in its embodiments.

[0347] The CPU energy efficiency curve shown in Figure 11B is merely an illustrative example of this application and should not be construed as limiting the scope of this application.

[0348] The frequency modulation simulator can traverse the range of values ​​for the slope and curvature parameters of the frequency modulation function based on the simulation granularity, and determine the frequency modulation function under different combinations of slope and curvature parameter values.

[0349] The slope parameter is kk in formula (2) above. The curvature parameter is α in formula (2) above. The simulation granularity, the range of values ​​for kk, and the range of values ​​for α can all be preset. For example, the range of values ​​for kk can be greater than or equal to 0.1 and less than or equal to 20. The range of values ​​for α can be greater than or equal to 0.1 and less than or equal to 5. The simulation granularity can be 0.1. Based on this simulation granularity, the frequency modulation simulator can determine 200 values ​​from the range of values ​​for kk and 50 values ​​from the range of values ​​for α, thereby determining 10,000 different combinations of values ​​for kk and α (i.e., 10,000 different frequency modulation functions). The simulation granularity, the range of values ​​for kk, and α above are merely exemplary descriptions of this application and should not be construed as limiting this application. In some embodiments, the simulation granularity used for taking values ​​within the range of values ​​for kk and the simulation granularity used for taking values ​​within the range of values ​​for α can be different.

[0350] The frequency modulation simulator can traverse the task data list, simulate frame loss and power consumption of critical threads and critical dependent threads under different frequency modulation functions, and determine the optimal frequency modulation function based on the frame loss data and power consumption. The power consumption of the critical threads and critical dependent threads can be determined based on the CPU energy efficiency curve.

[0351] Server 200 can send the optimal frequency modulation function determined by the frequency modulation emulator to electronic device 100. The CPU energy efficiency curve used by the frequency modulation emulator in server 200 can be the CPU energy efficiency curve of the CPU in electronic device 100. In this way, electronic device 100 can accurately allocate processor resources based on this optimal frequency modulation function when running critical threads and critical dependent threads.

[0352] The method for determining the optimal frequency modulation function of server 200 shown in Figure 11A will be described in detail below.

[0353] Figure 12A illustrates an exemplary flowchart of a method for determining the optimal frequency modulation function.

[0354] S1211. Obtain historical CPU load data, CPU energy efficiency curve, and frequency point computing power table. Historical CPU load data includes thread runtime and CPU frequency during thread runtime.

[0355] S1212. Extract the runtime and CPU frequency of key threads and key dependent threads from historical CPU load data.

[0356] In some embodiments, the task generation module in server 200 can extract the runtime and CPU frequency of the drawing frame thread from historical load data, such as the runtime and CPU frequency of the UI thread and its critical dependent threads, the RS thread and its critical dependent threads.

[0357] Figure 12B provides an exemplary schematic diagram of the operation of the UI thread and the RS thread.

[0358] As shown in Figure 12B, the electronic device can send frame synchronization signals based on the frame period. These frame synchronization signals can be used to instruct the UI thread and RS thread to execute corresponding frame-drawing tasks frame by frame. For example, with a screen refresh rate of 120Hz, the frame period can be 8.3ms. The frame-drawing tasks executed by the UI thread may include determining the specific content displayed in each frame of the user interface. The frame-drawing tasks executed by the RS thread may include rendering and displaying each frame of the user interface based on the specific content determined by the UI thread. When the UI thread executes frame-drawing tasks within a frame period, it may need to rely on the operation of one or more critical dependent threads. Similarly, when the RS thread executes frame-drawing tasks within a frame period, it may need to rely on the operation of one or more critical dependent threads.

[0359] For example, as shown in Figure 12B, when frame synchronization signal 1 is received, the UI thread can determine the display content of the first frame of the user interface and send a drawing instruction for drawing the first frame of the user interface to the RS thread via interprocess communication (IPC). When frame synchronization signal 2 is received, the RS thread can draw the first frame of the user interface according to the aforementioned drawing instruction. The RS thread can instruct the graphics processing unit (GPU) to draw the user interface. Furthermore, when frame synchronization signal 2 is received, the UI thread can determine the display content of the second frame of the user interface and send a drawing instruction for drawing the second frame of the user interface to the RS thread via IPC. The time interval between frame synchronization signal 1 and frame synchronization signal 2, and the time interval between frame synchronization signal 2 and frame synchronization signal 3, are the frame period. When frame synchronization signal 3 is received, the RS thread can draw the second frame of the user interface according to the aforementioned drawing instruction. And so on, the UI thread and RS thread can refresh the user interface on the screen frame by frame.

[0360] The runtime of the UI thread can include the runtime for the UI thread to execute each frame rendering task. The runtime for the UI thread to execute a single frame rendering task is related to the workload of that frame. With a fixed CPU processing power, the more workload a single frame rendering task has, the longer the runtime for the UI thread to execute that frame. For example, the runtime for the UI thread to execute a single frame rendering task may be less than 8.3ms, or it may exceed 8.3ms. It should be noted that the runtime for the UI thread to execute a single frame rendering task may include the time the UI thread spends waiting for its critical dependent threads to run while executing that frame.

[0361] The runtime of the RS thread can be referenced from the runtime of the UI thread mentioned above.

[0362] S1213. Based on the frequency point computing power table, the runtime of the critical thread and the critical dependent thread, and the CPU frequency during runtime, determine the task data list of the critical thread and the critical dependent thread. The task data list includes the frame task volume of the critical thread and the critical dependent thread.

[0363] The task generation module in server 200 can determine the CPU computing power corresponding to the CPU frequency of the critical thread and critical dependent threads based on the frequency computing power table. The task generation module can calculate the frame task volume for each frame of tasks executed by the critical thread and critical dependent threads, and then generate a task data list. The task data list can be found in Table 9 below.

[0364] Table 9

[0365] The frame sequence number can be arranged sequentially according to the execution order of each frame task. For example, in the frame tasks executed by the UI thread and the RS thread, the frame sequence number can be the sequence number of the frame synchronization signal shown in Figure 12B. The task quantity of a frame task can be the product of the runtime of the frame task and the computing power of the CPU during the runtime of the frame task, or it can be the integral of the computing power of the CPU during the runtime of the frame task over the runtime of the frame task. In some embodiments, the above-mentioned frame task quantity can be the task quantity after normalization.

[0366] The task data list above may include the number of tasks executed by the UI thread for each frame, and the number of tasks executed by the RS thread for each frame.

[0367] The frame tasks executed by the UI thread and RS thread can be referred to the description in Figure 12B above. In some embodiments, if the critical thread is the audio playback thread, the workload of one frame task executed by the audio playback thread may include the workload of playing one frame of audio. This application embodiment does not limit the task type of each frame task executed by the critical thread and the critical dependent thread.

[0368] S1214. Obtain the form of the frequency modulation function, as well as the value range and simulation granularity of the slope and curvature parameters in the frequency modulation function.

[0369] The form of the frequency modulation function can be found in the aforementioned formula (2).

[0370] S1215. Determine the frequency modulation function based on the range of values ​​for the slope parameter and curvature parameter during the simulation granularity traversal.

[0371] S1216. Traverse the task data list and simulate the frame loss data and power consumption of critical threads and critical dependent threads when using the frequency adjustment function to dynamically adjust the frequency of critical threads and critical dependent threads according to the CPU energy efficiency curve.

[0372] The method for determining the frame loss data and power consumption of critical threads and critical dependent threads can be referred to the method shown in Figure 12C later in this application.

[0373] S1217. Determine whether the range of values ​​for the slope parameter and curvature parameter has been traversed.

[0374] If the range of values ​​for the slope parameter and curvature parameter has been traversed, the frequency modulation simulator in server 200 can execute the following step S1218.

[0375] If the range of values ​​for the slope parameter and curvature parameter has not been fully traversed, the frequency modulation simulator in server 200 can continue to execute the above step S1215.

[0376] S1218. Determine the optimal frequency modulation function based on the frame loss data and power consumption corresponding to the frequency modulation function under multiple different combinations of slope and curvature parameters.

[0377] A frequency modulation (FM) simulator can determine different frequency modulation functions based on different combinations of slope and curvature parameters. The FM simulator can simulate the frame loss and power consumption corresponding to different FM functions when FMing the same critical thread and critical dependent threads.

[0378] In some embodiments, the frequency modulation simulator can first select the frequency modulation function with the minimum frame loss data, and then determine the frequency modulation function with the minimum power consumption among the frequency modulation functions with the minimum frame loss data as the optimal frequency modulation function. Alternatively, the frequency modulation simulator can first select the frequency modulation function with the minimum power consumption, and then determine the frequency modulation function with the minimum frame loss data among the frequency modulation functions with the minimum power consumption as the optimal frequency modulation function. Alternatively, the frequency modulation simulator can perform a weighted summation of the frame loss data and power consumption corresponding to the frequency modulation function, and determine the frequency modulation function with the minimum weighted sum value as the optimal frequency modulation function.

[0379] The method described above for determining the optimal frequency modulation function based on the frame loss data and power consumption corresponding to the frequency modulation function is merely an illustrative example of this application and should not be construed as limiting this application.

[0380] Figure 12C illustrates an exemplary flowchart of a method for determining frame loss data and power consumption of critical threads and critical dependent threads based on a set of slope parameters and curvature parameters.

[0381] S1221. Determine the frame-CPU frequency modulation allocation result based on the frame period and CPU frequency modulation period.

[0382] In some embodiments, the frame period can represent the time interval between two consecutive frame synchronization signals. The frame synchronization signal can be referred to in the description shown in Figure 12B above. The CPU frequency adjustment period can represent the time interval between two consecutive adjustments to the CPU frequency.

[0383] The CPU frequency adjustment period and the frame period can be different. For example, the frame period can be 8.3ms, while the CPU frequency adjustment period can be 4ms. Therefore, the timing of CPU frequency adjustment by an electronic device may occur at different times within different frame periods.

[0384] For example, an electronic device might perform the first CPU frequency adjustment at 4ms, the second at 8ms, the third at 12ms, and the fourth at 16ms. The critical thread of the electronic device runs the first frame task from 0 to 8.3ms and the second frame task from 8.3ms to 16.6ms. Therefore, the first CPU frequency adjustment could occur at 4ms of the frame period containing the first frame task. The second CPU frequency adjustment could occur at 8ms of the frame period containing the first frame task. The third CPU frequency adjustment could occur at 3.7ms of the frame period containing the second frame task. The fourth CPU frequency adjustment could occur at 7.7ms of the frame period containing the second frame task.

[0385] The frame-CPU frequency modulation allocation result can be used to indicate the correspondence between the CPU frequency modulation cycle and the frame cycle, so as to determine which frame cycle the current CPU frequency modulation is in. In this way, the electronic device can determine whether to increase or decrease the frequency based on whether the frame task in the frame cycle in which the current CPU frequency modulation is located has been completed.

[0386] S1222. Determine the frequency modulation function 1 corresponding to the CPU computing power, slope parameter 1, and curvature parameter 1 of the first frame.

[0387] The CPU computing power of the first frame can be preset. The frequency modulation emulator can determine the CPU frequency of the first frame corresponding to the computing power of the first frame according to the frequency modulation computing power table. This application embodiment does not limit the value of the CPU computing power of the first frame.

[0388] S1223. Determine whether the task data list has been processed.

[0389] Once the task data list is processed, it indicates that the frequency modulation simulator has simulated all frame tasks in the task data list using frequency modulation function 1. Specifically, simulating a single frame task using frequency modulation function 1 means that during the execution of a frame task, the frequency modulation simulator uses frequency modulation function 1 to adjust the CPU frequency, thereby determining the execution duration and power consumption of that frame task under the influence of frequency modulation function 1.

[0390] In some embodiments, the frequency modulation simulator can use frequency modulation function 1 to simulate each frame of the task in the task data list in sequence according to the frame number arrangement in the task data list.

[0391] If the task data list is processed, the frequency modulation simulator can execute the following step S1227.

[0392] If the task data list has not been processed, the frequency modulation simulator can perform the following step S1224.

[0393] S1224. Based on the current frame number, the remaining task quantity of the previous frame, the historical CPU computing power simulation list, and the frame-CPU frequency modulation allocation result, determine the runtime simulation result and computing power simulation result corresponding to the current frame task when using frequency modulation function 1 for frequency modulation.

[0394] The frequency modulation simulator can obtain the current frame sequence number and then determine the task load of the current frame based on the frame sequence number.

[0395] In some embodiments, the previous frame task of the current frame task may not have completed all its tasks within its running frame period (e.g., 8.3ms). In this case, the remaining tasks from the previous frame can continue within the frame period corresponding to the current frame task. Specifically, within the frame period corresponding to the current frame task, the frequency modulation simulator can first complete the remaining tasks from the previous frame before starting the current frame task. If there are no remaining tasks from the previous frame task, the frequency modulation simulator can directly start running the current frame task within the frame period corresponding to the current frame task.

[0396] The historical CPU computing power simulation list can include all frame tasks preceding the current frame task, their execution time under the influence of frequency modulation function 1, and the computing power corresponding to each execution stage. The frequency modulation simulator can determine the value of the margin in frequency modulation function 1 based on the existing data in the historical CPU computing power simulation list, and then simulate the current frame task based on the frequency modulation function 1 corresponding to that margin. In some embodiments, the value of the margin can be the average execution time of the currently existing frame tasks in the historical CPU computing power simulation list.

[0397] Figure 12D illustrates a schematic diagram of simulating different frame tasks of a thread based on frequency modulation function 1.

[0398] As shown in Figure 12D, the CPU frequency adjustment cycle is 4ms. The CPU frequency adjustment cycle can also be called the computing power control cycle. The frame rendering cycle can be 8.3ms. The frame rendering cycle can be the frame cycle of the frame rendering thread (e.g., UI thread, RS thread). The CPU computing power of the first frame can be u12. The frequency adjustment emulator can start running the first frame task of the frame rendering thread from 0ms.

[0399] The frequency modulation simulator can start running the first frame task of the drawing thread at 0ms, that is, to simulate the first frame task.

[0400] Within 0-4ms, the CPU computing power provided by the frequency modulation emulator to the frame drawing thread can be u12. The 4ms mark is the CPU frequency adjustment point. At the 4ms mark, the frequency modulation emulator can determine whether the first frame task has been completed. If not, the frequency modulation emulator can increase the CPU computing power provided to the frame drawing thread from u12 to u14 as shown in Figure 12D, i.e., increase the CPU frequency, according to frequency modulation function 1. Within 4-8ms, the CPU computing power provided by the frequency modulation emulator to the frame drawing thread can be u14. When using frequency modulation function 1 for frequency adjustment during the execution of the first frame task, the margin value in frequency modulation function 1 can be preset. For example, the margin value can be 6ms. Furthermore, when performing CPU frequency adjustment at the aforementioned 4ms mark, since the execution time of the first frame task is 4ms, the Time value in frequency modulation function 1 can be 4ms. Thus, the frequency modulation emulator can calculate the adjusted CPU frequency at the 4ms mark based on frequency modulation function 1.

[0401] As shown in Figure 12D, the completion time of the first frame task is 6.2ms. It can be understood that 6.2ms may include the time it takes for the drawing thread (such as the UI thread or RS thread) to run the first frame task and the time it takes for the drawing thread to wait for its critical dependent threads to run in order to run the first frame task.

[0402] The 8ms interval can be the CPU frequency adjustment time. Since the 8ms interval is still within the first frame drawing cycle, the frequency adjustment emulator can determine whether the first frame task is completed. If completed, the frequency adjustment emulator can reduce the CPU computing power provided to the drawing thread from u14 to u11 as shown in Figure 12D, that is, reduce the CPU frequency. Within the 8-12ms interval, the CPU computing power provided by the frequency adjustment emulator to the drawing thread can be u11. The value of u11 can be preset. In the embodiments of this application, the value of u11 is not limited.

[0403] The frequency modulation simulator can start running the second frame task of the drawing thread at 8.3ms, that is, to simulate the second frame task.

[0404] The 12ms mark is the CPU frequency adjustment point. Since the 12ms mark falls within the second frame rendering cycle, the frequency adjustment emulator can determine whether the second frame task has been completed. If not, the frequency adjustment emulator can increase the CPU computing power provided to the rendering thread from u11 to u13 as shown in Figure 12D according to frequency adjustment function 1. When using frequency adjustment function 1 to adjust the frequency during the execution of the second frame task, the value of margin in frequency adjustment function 1 can be the runtime of the first frame task (e.g., 6.2ms). Furthermore, when performing CPU frequency adjustment at the aforementioned 12ms mark, since the execution time of the second frame task is 3.7ms (i.e., 12ms - 8.3ms), the value of Time in frequency adjustment function 1 can be 3.7ms. Thus, the frequency adjustment emulator can calculate the adjusted CPU frequency when performing CPU frequency adjustment at the 12ms mark according to frequency adjustment function 1.

[0405] As shown in Figure 12D, the completion time of the second frame task is 7.5ms. It can be seen that the second frame task completes at 15.8ms (i.e., 8.3ms + 7.5ms). It is understandable that the 7.5ms can include the time taken for the rendering thread (e.g., the UI thread, or the RS thread) to run the second frame task, as well as the time taken for that rendering thread to wait for its critical dependent threads to run.

[0406] The 16ms mark is the CPU frequency adjustment time. Since the 16ms mark falls within the second frame drawing cycle, the frequency adjustment emulator can determine whether the second frame task is complete. If complete, the frequency adjustment emulator can reduce the CPU computing power provided to the frame drawing thread from u13 to u11 as shown in Figure 12D.

[0407] Similarly, the frequency modulation simulator can start running the third frame task of the drawing thread at 16.6ms, that is, to simulate the third frame task. During the execution of the third frame task, when frequency modulation function 1 is used, the margin value in frequency modulation function 1 can be the average runtime of the first and second frame tasks, i.e., (6.2+7.5) / 2 = 6.85ms. And so on, the frequency modulation simulator can use frequency modulation function 1 to complete the simulation of all frame tasks in the task data list.

[0408] When using frequency modulation function 1 to simulate each frame task, the frequency modulation simulator can use the simulation results of the runtime and computing power of each frame task when frequency modulation function 1 is used for frequency modulation.

[0409] For example, as shown in Figure 12D, when using frequency modulation function 1, the simulation result of the runtime of the first frame task is 6.2ms. The simulation result of computing power can include: the CPU computing power of the first frame task is u12 in the first 0-4ms and u14 in the second 4-6.2ms.

[0410] When using frequency modulation function 1, the simulation result of the runtime of the second frame task is 7.5ms. The simulation result of computing power can include: the CPU computing power is u11 during the first 0-3.7ms of the second frame task and u13 during the first 3.7-7.5ms.

[0411] The computing power adjustment process shown in Figure 12D is merely an illustrative example of this application and should not be construed as limiting this application.

[0412] S1225. Determine the remaining task quantity for the current frame, update the thread runtime list based on the runtime simulation results corresponding to the current frame task, and update the historical computing power simulation list based on the computing power simulation results corresponding to the current frame task.

[0413] If the workload of the current frame task is not completed within the frame period corresponding to the current frame task (e.g., 8.3ms), the remaining workload of the current frame task can be completed within the frame period corresponding to the next frame task. The simulation result of the runtime corresponding to the current frame task can be expressed as the time taken to complete all the workload of the current frame task when using frequency modulation function 1 for frequency modulation.

[0414] The list of thread runtimes can be found in Table 10 below.

[0415] Table 10

[0416] The historical computing power simulation list can be found in Table 11 below.

[0417] Table 11

[0418] Tables 10 and 11 above are merely illustrative examples of this application and should not be construed as limiting this application.

[0419] The frequency modulation simulator can add the runtime simulation results corresponding to the current frame task to the above thread runtime list, and add the computing power simulation results corresponding to the current frame task to the above historical computing power simulation list.

[0420] S1226, Increment the frame number by 1.

[0421] The frequency modulation simulator can increment the frame number of the current frame task by 1 in steps S1223 and S1225 above, and then execute step S1223 to determine whether the task data list has been processed. If the task data list does not contain the frame number obtained by incrementing the frame number by 1, the frequency modulation simulator can determine that the task data list has been processed. If the task data list contains the frame number obtained by incrementing the frame number by 1, the frequency modulation simulator can determine this frame number as the currently processed frame number and use frequency modulation function 1 to simulate the current frame task according to the methods in steps S1224 and S1225 above.

[0422] S1227. Based on the thread runtime list and the historical computing power simulation list, determine the frame loss data and power consumption of the critical thread and the critical dependent thread when using frequency modulation function 1 for frequency modulation.

[0423] After simulating all frame tasks in the task data list using frequency modulation function 1, the frequency modulation simulator can determine the frame loss data and power consumption of critical threads and critical dependent threads when using frequency modulation function 1, based on the thread runtime list and the historical computing power simulation list.

[0424] In some embodiments, the thread runtime list and the historical computing power simulation list may include the runtime data of the multi-frame tasks of the UI thread under the action of frequency modulation function 1. The frequency modulation simulator can calculate the frame loss data and power consumption of the UI thread under the action of frequency modulation function 1. The frame loss data may include the number of frames lost (or the amount of frames lost).

[0425] The number of frames dropped by the UI thread under the action of frequency modulation function 1 can be calculated according to the following formula (3).

[0426] Where n1 represents the total number of frame tasks in the UI thread in the task data list. For example, if the task data list contains 100 frame tasks in the UI thread, then n1 is 100. The simulation result of the runtime of the i-th frame task in the UI thread can be obtained by looking up the thread runtime list. The duration threshold 1 can be preset. For example, the duration threshold 1 can be 8.33ms, 16.66ms, or 33.33ms, etc. The embodiments of this application do not limit the value of the duration threshold 1.

[0427] If the simulation result of the runtime of the i-th frame task is greater than the duration threshold 1, it indicates that the i-th frame task has experienced frame dropping. It is understandable that after the UI thread completes a frame task, it will instruct the RS thread to draw the image corresponding to the frame. The runtime of a frame task of the UI thread is greater than the drawing frame period, so there may not actually be any frame dropping in the user interface. Therefore, the duration threshold 1 can be greater than the drawing frame period (e.g., 8.3ms). The power consumption of the UI thread under the action of frequency modulation function 1 can be calculated according to the following formula (4).

[0428] Where m represents the total number of frequency adjustments during the execution of the UI thread's frame task in the task data list. Computational power i represents the computational power value after the i-th frequency adjustment. Runtime i represents the runtime of the UI thread's frame task after the i-th frequency adjustment. Referring to Table 11 above, for example, the first frame task is the UI thread's frame task. The computational power value of the frequency adjustment emulator after the first frequency adjustment is u12, and the runtime of the UI thread's frame task is 4ms. Therefore, computational power 1 × runtime 1 = 4 × u12. The computational power value of the frequency adjustment emulator after the second frequency adjustment is u14, and the runtime of the UI thread's frame task is 2.2ms. Therefore, computational power 2 × runtime 2 = 2.2 × u12. f() can be the conversion formula between power consumption and computational power. f() can be determined by the CPU energy efficiency curve.

[0429] In some embodiments, the thread runtime list and the historical computing power simulation list may include the running data of the multi-frame tasks of the RS thread under the action of frequency modulation function 1. The frequency modulation simulator can calculate the frame loss data and power consumption of the RS thread under the action of frequency modulation function 1.

[0430] The number of frames dropped by the RS thread under the action of frequency modulation function 1 can be calculated according to the following formula (5).

[0431] Here, n2 represents the total number of frame tasks in the RS thread in the task data list. For example, if the task data list contains 100 frame tasks in the RS thread, then n2 is 100. The simulation result of the runtime of the i-th frame task in the RS thread can be obtained by looking up the thread runtime list. The runtime threshold 2 can be preset. The runtime threshold 2 can be the same as or different from the runtime threshold 1 mentioned above. It is understandable that the frame tasks of the RS thread are directly related to the rendering and display of the user interface. The runtime of a frame task in the RS thread is longer than the drawing frame period, and the probability of frame dropping in the user interface is relatively high. Therefore, the value of the runtime threshold 2 can be less than the value of the runtime threshold 1 mentioned above. This can more accurately reflect the number of dropped frames.

[0432] The power consumption of the RS thread under the action of frequency modulation function 1 can be calculated by referring to the above formula (4).

[0433] Since both the UI thread and the RS thread are frame-drawing threads, the frequency modulation emulator can determine the total number of dropped frames based on the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1. For example, the frequency modulation emulator can determine the total number of dropped frames by summing the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1. Alternatively, the frequency modulation emulator can determine the total number of dropped frames by performing a weighted sum of the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1.

[0434] The frequency modulation emulator can also determine the total power consumption based on the power consumption of the UI thread and the RS thread under the action of frequency modulation function 1. For example, the frequency modulation emulator can determine the total power consumption by summing the power consumption of the UI thread and the RS thread under the action of frequency modulation function 1.

[0435] The method for using frequency modulation simulators with frequency modulation functions corresponding to other slope and curvature parameters can refer to the above method for using frequency modulation function 1 for simulation.

[0436] The frequency modulation simulator can determine the optimal frequency modulation function based on the total number of dropped frames and total power consumption of the UI thread and RS thread in the task data list when using different frequency modulation functions. These different frequency modulation functions can include those with different combinations of slope and curvature parameters.

[0437] In some embodiments, not limited to the UI thread and RS thread, the frequency modulation emulator can also combine the number of dropped frames and power consumption of other types of critical threads (such as the audio playback thread) under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function. Optionally, the frequency modulation emulator can use only the number of dropped frames and power consumption of the UI thread under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function. Alternatively, the frequency modulation emulator can use only the number of dropped frames and power consumption of the RS thread under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function.

[0438] In some embodiments, when the frequency modulation simulator uses a frequency modulation function (e.g., frequency modulation function 1) to simulate a frame task, it may also consider frame insertion scenarios and / or frame skipping scenarios to improve the accuracy of the simulation results.

[0439] Frame interpolation can be used to advance short-frame tasks so that subsequent long-frame tasks can complete within their respective frame periods. Frame interpolation can reduce frame drops caused by timeouts in frame tasks. Short-frame tasks refer to frames with a small number of tasks that can be completed ahead of schedule within the frame period. Long-frame tasks refer to frames with a large number of tasks that cannot be completed within the frame period.

[0440] Figure 13A illustrates a schematic diagram of a frame interpolation scenario.

[0441] As shown in Figure 13A, the UI thread's first and second frame tasks are both short frame tasks, while the third frame task is a long frame task. Without frame interpolation, the UI thread can start running the third frame task upon receiving frame synchronization signal 3. However, due to the large workload of the third frame task, the UI thread may not have completed its task when it receives frame synchronization signal 4.

[0442] When using a frame interpolation strategy, electronic devices can detect the completion time of each frame task. When a short frame task completes ahead of schedule within the frame period, the electronic device can send a virtual synchronization signal to the UI thread to instruct the UI thread to start running the next frame task.

[0443] For example, as shown in Figure 13A, when the completion of the first frame task is detected at time t11, the electronic device can send a virtual frame synchronization signal 2 to the UI thread. Time t11 can be a time within the frame period corresponding to frame synchronization signal 1 and frame synchronization signal 2. According to virtual frame synchronization signal 2, the UI thread can start running the second frame task. When the completion of the second frame task is detected at time t12, the electronic device can send a virtual frame synchronization signal 3 to the UI thread. Time t12 is earlier than the time when frame synchronization signal 3 is sent. According to virtual frame synchronization signal 3, the UI thread can start running the third frame task. It can be seen that since the UI thread has already started running the third frame task before the arrival of frame synchronization signal 3, the UI thread can complete all the tasks of the third frame task before the arrival of frame synchronization signal 4. This avoids the existence of remaining tasks in the third frame task that need to be run in the next frame period.

[0444] When using frequency modulation (FM) functions to simulate frame tasks, the FM simulator can employ a frame interpolation strategy. Since frame interpolation advances the execution time of one or more frame tasks, the FM simulator can determine which frame task is actually running each time FM is applied, thereby determining the execution period of each frame task and the CPU computing power required during execution.

[0445] Frame skipping can be used to discard tasks that have been waiting for too long. Frame skipping can reduce the number of dropped frames by reducing the backlog of frame tasks.

[0446] Figure 13B illustrates a schematic diagram of a frame skipping scenario.

[0447] This section uses RS thread frame skipping as an example to introduce the frame skipping scenario.

[0448] As shown in Figure 13B, the UI thread can run the corresponding frame task according to the received frame synchronization signal. As described in Figure 12B above, after the UI thread completes a frame task, it sends the drawing instruction corresponding to this frame task to the RS thread to instruct the RS thread to draw the user interface corresponding to this frame task.

[0449] For example, after receiving frame synchronization signal 3, the UI thread can run its third frame task (e.g., determining the content displayed in the third frame of the user interface). The workload of the third frame task is relatively large. After receiving frame synchronization signal 4, the UI thread can continue to run the remaining workload of the third frame task, and after the third frame task has finished running, it can start running its fourth frame task.

[0450] After the UI thread finishes its 3rd frame task, it can send a drawing frame instruction to the RS thread to render the 3rd frame of the user interface. Based on this drawing frame instruction, the RS thread can run its 3rd frame task (e.g., rendering and displaying the 3rd frame of the user interface). The RS thread's 3rd frame task is also quite demanding. The RS thread's 3rd frame task is not yet complete until it receives frame synchronization signal 6. Therefore, after receiving frame synchronization signal 6, the RS thread can continue running its 3rd frame task.

[0451] After receiving frame synchronization signal 5, the UI thread can run its 5th frame task, and after receiving frame synchronization signal 6, it can run its 6th frame task. Specifically, after completing its 4th frame task, the UI thread can send a drawing command to the RS thread to render the 4th frame of the user interface, and after completing its 5th frame task, it can send a drawing command to the RS thread to render the 5th frame of the user interface. However, since the RS thread is currently running its 3rd frame task, both the RS thread's 4th frame task (e.g., rendering and displaying the 4th frame of the user interface) and 5th frame task (e.g., rendering and displaying the 5th frame of the user interface) must wait for the RS thread's 3rd frame task to complete.

[0452] In some embodiments, when the waiting time for a task frame exceeds a preset time threshold, the thread can skip this frame and directly run the next task frame. This application embodiment does not limit the value of the aforementioned time threshold. For example, when the third task frame of the RS thread completes execution, the waiting time for the fourth task frame of the RS thread is T4, and the waiting time for the fifth task frame of the RS thread is T5. If both T4 and T5 are greater than the aforementioned time threshold, the RS thread can skip the fourth and fifth tasks frame frame of the RS thread. After running the third task frame of the RS thread, the RS thread can run the sixth task frame of the RS thread according to the frame synchronization signal 7 (e.g., rendering and displaying the sixth frame user interface).

[0453] When simulating frame tasks using frequency modulation functions, frequency modulation emulators can employ a frame skipping strategy. Frame skipping cancels the execution of one or more frame tasks. The frequency modulation emulator can determine the number of dropped frames based on the number of skipped frames. The number of dropped frames can include the number of skipped frames. Furthermore, since skipped frame tasks are not executed, the frequency modulation emulator does not need to calculate the power consumption corresponding to the skipped frame tasks when calculating the power consumption of threads.

[0454] Understandably, in real-world thread execution scenarios, electronic devices may employ frame interpolation and / or frame skipping strategies for thread frame tasks. When using a frequency modulation (FM) simulator for simulation, employing frame interpolation and / or frame skipping strategies can more realistically simulate the actual thread execution process, thereby finding the optimal FM function more accurately.

[0455] Based on the simulation of the frequency modulation simulator, the optimal frequency modulation function determined by the frequency modulation simulator has the following characteristics: the curvature parameter of the optimal frequency modulation function is less than 1 (i.e., the frequency modulation curve corresponding to the optimal frequency modulation function is an upward convex curve), the convexity of the frequency modulation curve corresponding to the optimal frequency modulation function is positively correlated with the convexity of the CPU energy efficiency curve, and the increase of the optimal frequency modulation function slows down with the increase of the frame task running time (i.e., Time in the aforementioned formula (2)), which is consistent with the trend that the task load of the frame task decreases with the increase of the frame task running time. The frequency modulation curve corresponding to the optimal frequency modulation function can be called the optimal frequency modulation curve.

[0456] Figure 14A illustrates a schematic diagram of an optimal frequency modulation curve.

[0457] As shown in Figure 14A, the optimal frequency modulation curve is an upward-convex curve. The coordinate axis of the optimal frequency modulation curve can be referenced from the description of the coordinate axis of the frequency modulation curve in Figure 10 above. It can be seen that during the initial period of frame task execution (i.e., when time t is relatively small), the increase in computing power u(t) is significant. As time t (i.e., Time in the frequency modulation function) increases, the increase in computing power u(t) gradually decreases.

[0458] The slope and curvature parameters of the optimal frequency modulation curve are related to the CPU energy efficiency curve. Different CPU energy efficiency curves may correspond to different optimal frequency modulation curves. In some embodiments, the server 200 can simulate the optimal frequency modulation function corresponding to any CPU model based on the frequency modulation simulator shown in Figure 11A. The frequency modulation simulator can determine the optimal frequency modulation function for a CPU model based on historical CPU load data of a CPU model operating over a period of time, and the CPU energy efficiency curve of that CPU model. The method for determining the optimal frequency modulation function can refer to the methods shown in Figures 12A and 12C above.

[0459] Figure 14B illustrates a schematic diagram comparing an optimal frequency modulation curve with a non-optimal frequency modulation curve.

[0460] As shown in Figure 14B, the black line represents the optimal frequency modulation (FM) curve, and the gray line represents the non-optimal FM curve. The non-optimal FM curve can be referenced from the FM curve shown in Figure 10 above. It is understood that all FM curves other than the optimal FM curve are non-optimal FM curves. The non-optimal FM curve shown in Figure 14B is merely one example of a non-optimal FM curve.

[0461] Comparing the optimal and non-optimal frequency modulation (FM) curves reveals that they intersect at time t3. Before time t3, the optimal FM curve has higher computing power at the same time. After time t3, the optimal FM curve has lower computing power at the same time.

[0462] A shorter time interval t represents the period at which a task frame has just begun running; at this point, the task frame definitely has tasks yet to be completed. A longer time interval t represents the period after a task frame has been running for some time; at this point, the task frame may have already completed its tasks.

[0463] Compared to suboptimal frequency scaling curves, optimal frequency scaling curves can more quickly increase CPU computing power when time t is relatively short (i.e., at the beginning of a task frame). This not only improves the running speed of the task frame, allowing it to complete its workload more quickly, but also reduces the likelihood of abruptly increasing the frequency at the end of a task frame. Conversely, optimal frequency scaling curves can slow down the rate of CPU computing power growth when time t is relatively long (i.e., at the end of a task frame). This reduces the likelihood of rapidly increasing CPU computing power after a task frame has been completed, thus minimizing wasted CPU resources.

[0464] As shown in Figure 11B above, the CPU has the best energy efficiency when the computing power is between u1 and u2 (that is, the CPU can execute the most tasks under the same power consumption).

[0465] As shown in Figure 14B, the optimal frequency modulation curve corresponds to a computing power of u1 at time t1 and u2 at time t5. The non-optimal frequency modulation curve corresponds to a computing power of u1 at time t2 and u2 at time t4. Time t1 is earlier than time t2, and time t5 is later than time t4. Compared to the non-optimal frequency modulation curve, when frequency modulation is based on the optimal curve, the CPU can maintain its optimal energy efficiency for a longer period. This is beneficial for efficiently utilizing CPU resources, enabling the CPU to complete more tasks with less power consumption.

[0466] As can be seen, the optimal frequency modulation curve described above can improve the running speed of frame tasks, enabling them to complete within the corresponding frame period. This reduces performance issues such as stuttering caused by dropped frames. Furthermore, the optimal frequency modulation curve can reduce the power consumption of electronic devices during frame task execution, thereby increasing battery life and reducing the risk of excessively rapid temperature rise.

[0467] In some embodiments, the task generation module and frequency modulation simulator shown in Figure 11A can serve as an optimal frequency modulation function determination tool for developers. This tool can help developers determine the optimal frequency modulation function for any CPU model. Specifically, the tool provides an input interface for developers to input historical CPU load data, CPU energy efficiency curves, the value ranges of slope and curvature parameters, and simulation granularity. Based on the parameters input by the developer, the tool can generate and output the optimal frequency modulation function.

[0468] In some embodiments, in addition to using the optimal frequency modulation function, the electronic device can also combine one or more other frequency modulation strategies for frequency modulation. For example, the electronic device can also detect the start and end times of each frame of critical threads and critical dependent threads. Besides using the optimal frequency modulation function according to a preset CPU frequency modulation cycle, the electronic device can also increase the frequency at the start of a frame of task execution and decrease the frequency at the end of a frame of task execution. This can better conserve the power of the electronic device.

[0469] Figure 15 illustrates an exemplary frequency modulation diagram provided in this application.

[0470] Here, we will still take a CPU frequency adjustment period of 4ms and a frame drawing period of 8.3ms as an example to illustrate the schematic diagram of CPU frequency adjustment during the operation of the frame drawing thread.

[0471] As shown in Figure 15, the electronic device can start running the first frame task of the frame drawing thread at 0ms. When it detects that 0ms is the start time of the first frame task, the electronic device can increase the CPU computing power to u22. Specifically, according to the frequency computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u22. This adjustment of the CPU frequency may include adjusting the frequency of the CPU core of the first frame task of the frame drawing thread. This embodiment does not limit the amount of CPU computing power (i.e., u22) increased by the electronic device at the start time of the frame task.

[0472] During the first 4ms, the CPU used to run the first frame task of the rendering thread can maintain the CPU frequency corresponding to u22. Within this first 4ms, if a critical thread within the rendering thread (e.g., the UI thread or the RS thread) pauses execution and waits for a critical dependent thread within the rendering thread (e.g., a critical dependent thread of the UI thread or a critical dependent thread of the RS thread) to run, the critical dependent thread will receive more processor resources and run faster, thus reducing the waiting time of the critical thread.

[0473] The 4ms interval can be the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. At the 4ms interval, the electronic device can determine whether the first frame task has been completed. If not, the electronic device can increase the CPU computing power to u24 according to the optimal frequency adjustment function. The method for determining u24 can refer to the method for determining u14 shown in Figure 12D above. Specifically, based on the frequency point computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u24.

[0474] As shown in Figure 15, the completion time of the first frame task is 6.2ms. When the end time of the first frame task is detected at 6.2ms, the electronic device can reduce the CPU computing power to u21. Specifically, according to the frequency point computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u21. This embodiment does not limit the amount of CPU computing power (i.e., u21) reduced by the electronic device at the end time of the frame task.

[0475] The 8ms mark can be considered the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 8ms mark is still within the first frame's rendering cycle, the electronic device can determine whether the first frame's task is complete. It can be seen that the first frame's task was completed before the 8ms mark. Because the electronic device has already downclocked the CPU when the first frame's task was completed, it does not need to adjust the CPU frequency according to the optimal frequency adjustment function at the 8ms mark.

[0476] The electronic device can start running the second frame task of the drawing thread at 8.3ms. When it detects that 8.3ms is the start time of the second frame task, the electronic device can increase the CPU computing power to u22.

[0477] The 12ms interval can be the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 12ms interval falls within the second frame drawing cycle, the electronic device can determine whether the second frame task is completed. If not, the electronic device can increase the CPU computing power to u23 according to the optimal frequency adjustment function. The method for determining u23 can refer to the method for determining u13 shown in Figure 12D above. Specifically, based on the frequency point computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u23.

[0478] As shown in Figure 15, the completion time of the second frame task is 7.5ms. When the end time of the second frame task is detected at 15.8ms (i.e., 8.3ms + 7.5ms), the electronic device can reduce the CPU computing power to u21.

[0479] The 16ms mark can be considered the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 16ms mark falls within the second frame rendering cycle, the electronic device can determine whether the second frame task is complete. It can be seen that the second frame task was completed before the 16ms mark. Because the electronic device has already downclocked the CPU when the second frame task is completed, the electronic device does not need to adjust the CPU frequency according to the optimal frequency adjustment function at the 16ms mark.

[0480] As shown in Figure 15, the electronic device can increase the CPU frequency in real time at the start of the frame task of the critical thread and the critical dependent thread, and decrease the CPU frequency in real time at the end of the frame task of the critical thread and the critical dependent thread. During the execution of the frame task of the critical thread and the critical dependent thread, the electronic device can adjust the CPU frequency according to the optimal frequency adjustment function. This can improve the accuracy of the processor resource allocation to the critical thread and the critical dependent thread, thereby improving the utilization efficiency of processor resources and achieving a balance between the needs of smooth device performance, long battery life and rapid cooling.

[0481] The structure of the electronic device involved in this application is described below.

[0482] Figure 16A illustrates a schematic diagram of the hardware structure of an electronic device 100.

[0483] As shown in Figure 16A, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

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

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

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

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

[0488] In this application, a computer program may be stored in the memory to enable a controller or processor to implement the audio transmission method of this application through an interface or protocol. Exemplarily, the computer program stored in the memory may be used to: identify critical threads, critical dependent threads, and non-critical threads; increase the priority of critical threads and critical dependent threads; manage CPU time slices allocated to threads in groups; allocate CPU bandwidth quotas to threads in a target group; perform one or more of the following operations on threads temporarily dependent on by threads in the foreground group: increase priority, increase CPU time slice length, remove bandwidth quota suppression; suppress CPU frequency for threads in the target group; and dynamically adjust the CPU frequency according to an optimal frequency adjustment function during the operation of critical threads and critical dependent threads.

[0489] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

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

[0491] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0492] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0493] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0494] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0495] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0496] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering.

[0497] The display screen 194 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0498] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0499] The ISP is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye.

[0500] Camera 193 is used to capture still images or videos. In some embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0501] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0502] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

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

[0504] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0505] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0506] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0507] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0508] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a telephone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0509] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C.

[0510] The 170D headphone jack is used to connect wired headphones.

[0511] In this application, the speaker 170A, receiver 170B, and microphone 170C are all optional.

[0512] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, gravity sensors, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, angle sensors, etc.

[0513] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0514] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and detach from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The electronic device 100 interacts with the network through the SIM card to achieve functions such as calls and data communication. In some examples, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be removed from it.

[0515] Electronic device 100 can be a mobile phone, tablet computer, smartwatch, smart bracelet, speaker, television, etc. This application embodiment does not limit the type of electronic device 100.

[0516] Figure 16B illustrates a schematic diagram of the software structure of an electronic device 100.

[0517] The electronic device 100 may run an operating system. This operating system can be any operating system currently used in the industry, including but not limited to: operating systems based on OpenHarmony, such as HarmonyOS; or other operating systems, such as… A mobile operating system can also refer to various open-source operating systems or their derivatives, such as Linux OS and other embedded operating systems; it can also be a future-oriented operating system, such as an AI operating system based on artificial intelligence. An operating system is a set of interconnected system software programs that manage and control the operation of electronic devices, utilize and run hardware and software resources, and provide public services to organize user interaction. In electronic devices, the operating system occupies a crucial position, connecting to the physical hardware layer below and providing a runtime environment for application software above.

[0518] The software structure of the electronic device 100 is illustrated below using HarmonyOS as an example. Those skilled in the art can deduce the implementations of the embodiments of this application under other specific operating systems based on this.

[0519] As shown in Figure 16B, the software structure of electronic device 100 can be divided into several layers. In some embodiments, from bottom to top, these layers are: kernel layer, system service layer, framework layer, and application layer. Layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem level depending on the deployment scenario of different device forms. Each subsystem can also be tailored, added, or combined at the functional level. Electronic device 100 may also include a hardware layer. The hardware layer may include hardware devices such as CPU, GPU, flash memory, liquid crystal display (LCD), Bluetooth, camera, battery, and heat dissipation module. Applications in the application layer of electronic device 100 can control the hardware devices in the hardware layer through the framework layer, system service layer, and kernel layer.

[0520] The kernel layer can include the Kernel Abstraction Layer (KAL), kernel subsystems, and driver subsystems. The KAL provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral management. Kernel subsystems can support the selection of suitable OS kernels for different resource-constrained devices, and are not limited to Linux, HarmonyOS, LiteOS, etc. The driver subsystem can include driver frameworks. Driver frameworks are the foundation for an open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. Driver frameworks include: display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, etc. The kernel layer may also include a scheduler. The scheduler can be used to schedule the execution order of threads and allocate resources such as CPU computing power to threads.

[0521] The system service layer comprises the core capabilities of the system, providing services to applications through the framework layer. This layer includes, but is not limited to, the following subsystems:

[0522] The system's basic capability subsystems provide the foundational capabilities for the operation, scheduling, and migration of distributed applications across multiple devices. For example, they may include a global resource scheduling subsystem, distributed data management, a distributed soft bus, and a compiler / runner; they may also include a multi-modal input subsystem, a graphics subsystem, and a security subsystem.

[0523] Basic software service subsystems: provide common and general software services; for example, event notification subsystem, telephone service subsystem, multimedia subsystem, etc.

[0524] Enhanced software service subsystem suite: Provides differentiated capability-enhancing software services for different devices; for example, it may include proprietary business subsystems for smart screens, wearable devices, and IoT devices.

[0525] Hardware service subsystem set: provides hardware services; for example, it may include location service subsystem, user IAM (Identity and Access Management) subsystem, wearable proprietary hardware service subsystem, biometric identification, IoT proprietary hardware service subsystem, etc.

[0526] The global resource scheduling subsystem can be used to manage and schedule the hardware and software resources, such as processor resources, in the electronic device 100.

[0527] In some embodiments, the global resource scheduling subsystem can set parameters related to thread execution priorities so that the scheduler in the kernel layer can adjust thread priorities.

[0528] In some embodiments, the global resource scheduling subsystem can also adjust the CPU weight ratio of thread groups based on the CPU load rate of threads in different thread groups, so that the scheduler in the kernel layer can adjust the CPU time slice length allocated to different thread groups.

[0529] In some embodiments, the global resource scheduling subsystem can also set parameters related to the CPU bandwidth quota of a thread so that the scheduler in the kernel layer can allocate bandwidth quotas to the thread when scheduling the corresponding thread.

[0530] In some embodiments, the global resource scheduling subsystem may also label the threads that the threads in the foreground group temporarily depend on as critical sections, so that the scheduler in the kernel layer can prioritize scheduling threads with critical section labels, allocate longer CPU time slices to threads with critical section labels, and remove bandwidth quota suppression on threads with critical section labels.

[0531] In some embodiments, the global resource scheduling subsystem can also adjust the CPU frequency at the kernel layer. For example, when running non-critical threads, the CPU frequency can be controlled below a preset maximum frequency. This suppresses the CPU frequency of non-critical threads, saving power and reducing rapid overheating. As another example, when running critical threads and critical dependent threads, the CPU frequency can be dynamically adjusted based on an optimal frequency adjustment function. This allows for precise allocation of processor resources to critical and critical dependent threads, reducing oversupply or undersupply of processor resources. These CPU frequency adjustments can improve processor resource utilization efficiency while ensuring the smooth operation of critical and critical dependent threads, providing users with a smooth experience using electronic devices.

[0532] Distributed data management enables data synchronization, data storage, data sharing, and data access across all scenarios and devices.

[0533] The distributed soft bus provides communication-related capabilities, including WLAN service capabilities, Bluetooth service capabilities, soft bus, inter-process communication RPC (Remote Procedure Call) and other communication capabilities.

[0534] A compiler / runner is a unified compilation and runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms. For example, a compiler / runner could be the ArkCompiler.

[0535] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. Examples include the UI framework module (which provides a complete infrastructure for UI development of system applications, including UI functionalities such as components, layouts, animations, and interactive events, as well as real-time interface preview tools), the user application framework, and the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities). Different devices may run different operating systems, and therefore support different APIs.

[0536] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. Examples include: Audio API (audio service), Push API (push service), and Account API (account service).

[0537] Applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social apps, travel apps, short video apps, shopping apps, etc.

[0538] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0539] This application also provides a computer program product, including a computer program that, when run on a processor, can implement the steps in the various method embodiments described above.

[0540] This application also provides a chip system, which includes a processing circuit and an interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to implement the steps of any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0541] It is understood that the user interfaces described in the embodiments of this application are merely example interfaces and do not constitute a limitation on the solution of this application. In other embodiments, the user interface may adopt different interface layouts, may include more or fewer controls, and may add or remove other functional options, as long as they are based on the same inventive concept provided in this application, they are all within the protection scope of this application.

[0542] It should be noted that, without causing contradictions or conflicts, any feature in any embodiment of this application, or any part of any feature, can be combined, and the combined technical solution is also within the scope of the embodiments of this application.

[0543] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A processor resource management method, characterized in that, The method is applied to an electronic device, and the method includes: The first critical thread is run. The electronic device identifies the critical dependent threads of the first critical thread. The critical dependent threads of the first critical thread include threads other than the first critical thread on the first critical path. One node on the first critical path corresponds to one thread. The head node and the tail node on the first critical path both correspond to the first critical thread. There is a wake-up relationship between two adjacent nodes on the first critical path. The electronic device increases the priority of critical dependent threads of the first critical thread.

2. The method according to claim 1, characterized in that, Before the electronic device elevates the priority of critical dependent threads of the first critical thread, which is associated with the first application scenario, the method further includes: The electronic device determines that it is in the first application scenario based on the first application running in the foreground.

3. The method according to claim 2, characterized in that, After the electronic device raises the priority of the critical dependent threads of the first critical thread, the method further includes: The electronic device determines that it is in a second application scenario based on a second application running in the foreground. The electronic device identifies the key dependent threads of the second key thread. The second key thread is associated with the second application scenario. The key dependent threads of the second key thread include threads other than the second key thread on the second key path. One node on the second key path corresponds to one thread. The head node and tail node on the second key path both correspond to the second key thread. There is a wake-up relationship between two adjacent nodes on the second key path. The electronic device increases the priority of the critical dependent threads of the second critical thread.

4. The method according to claim 3, characterized in that, After the electronic device determines that it is in a second application scenario based on the application running in the foreground, the method further includes: The electronic device reduces the priority of critical dependent threads of the first critical thread.

5. The method according to any one of claims 1-4, characterized in that, The electronic device identifies the critical dependent threads of the first critical thread, including: The electronic device obtains the critical dependent threads of the first critical thread according to the first critical dependent thread list. The first critical dependent thread list includes the critical dependent threads of the first critical thread. The first critical dependent thread list is obtained by the electronic device from the server, or the first critical dependent thread list is generated or updated by the electronic device.

6. The method according to any one of claims 1-4, characterized in that, The electronic device identifies the critical dependent threads of the first critical thread, including: The electronic device detects a first thread wake-up event, which is used to indicate a first wake-up relationship corresponding to the first thread waking up the second thread. The electronic device acquires a first historical number of times the first wake-up relationship occurs and a second historical number of times the first wake-up relationship occurs on the first critical path; In response to the first historical count being greater than the first count threshold, and the ratio of the second historical count to the first historical count being greater than the first probability threshold, the electronic device identifies the threads other than the first critical thread among the first thread and the second thread as critical dependent threads of the first critical thread.

7. The method according to claim 5, characterized in that, The first critical dependency thread list is generated or updated by the electronic device, and the method further includes: The electronic device detects a first thread wake-up event, which is used to indicate a first wake-up relationship corresponding to the first thread waking up the second thread. The electronic device acquires a first historical number of times the first wake-up relationship occurs and a second historical number of times the first wake-up relationship occurs on the first critical path; In response to the first historical count being greater than the first count threshold, and the ratio of the second historical count to the first historical count being greater than the first probability threshold, the electronic device adds the first thread and the threads in the second thread other than the first critical thread to the first critical dependent thread list.

8. The method according to claim 5 or 7, characterized in that, The first critical dependency thread list includes a third thread, and the method further includes: The electronic device detects a second thread wake-up event, which is used to instruct a third thread to wake up other threads or other threads to wake up the third thread in a second wake-up relationship. The electronic device acquires the third historical number of times the second wake-up relationship occurs and the fourth historical number of times the second wake-up relationship occurs on the first critical path; In response to the third historical count being less than or equal to the second count threshold, or the ratio of the fourth historical count to the third historical count being less than or equal to the second probability threshold, the electronic device removes the third thread from the first critical dependent thread list.

9. The method according to any one of claims 5-8, characterized in that, The first critical thread is any thread in the first critical thread list, and the first critical dependent thread list contains critical dependent threads of one or more critical threads in the first critical thread list.

10. The method according to any one of claims 1-9, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. The electronic device detects the CPU load rate of the threads in the foreground group; When the CPU load rate of the threads in the foreground group increases, the electronic device determines a first increase in the CPU time slice length based on the increase in the CPU load rate of the threads in the foreground group. The electronic device increases the CPU time slice length of the threads in the foreground group according to the first increase amount, and decreases the CPU time slice length of the threads in the non-foreground group.

11. The method according to claim 10, characterized in that, Before the electronic device detects the CPU load rate of the threads in the foreground group, the method further includes: The electronic device detects a first foreground event, the first foreground event including a change in a foreground application running in the foreground.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. The electronic device detects the overall load of the electronic device and / or the device case temperature, wherein the overall load includes the CPU load of the threads in the foreground group and the non-foreground group; When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads of the non-foreground group based on the first bandwidth quota.

13. The method according to claim 12, characterized in that, The method further includes: When the overall load changes to a second load and / or the device casing temperature changes to a second temperature, the electronic device determines a second bandwidth quota based on the second load and / or the second temperature, and applies CPU bandwidth quotas to the threads of the non-foreground group based on the second bandwidth quota. If the second load is higher than the first load and / or the second temperature is higher than the first temperature, then the second bandwidth quota is less than the first bandwidth quota.

14. The method according to any one of claims 1-11, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into a foreground group, a normal thread group, and a restricted thread group. The foreground group includes threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The restricted thread group includes threads of system services that are not associated with the foreground applications and can be delayed, and threads of background applications running in the background that can be delayed. The normal thread group includes threads of system services that are not associated with the foreground applications and are not in the restricted thread group, and threads of background applications that are not in the restricted thread group. The electronic device continuously allocates CPU bandwidth quotas to the threads of the restricted thread group based on the third bandwidth quota. The electronic device detects the overall load and / or the device case temperature of the electronic device. The overall load includes the CPU load of the threads in the foreground group, the non-normal thread group, and the restricted thread group. When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads of the ordinary thread group based on the first bandwidth quota.

15. The method according to any one of claims 1-14, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. When it is detected that a third thread is waiting for a fourth thread to release a first shared resource or waiting to obtain a first running result from the fourth thread, the electronic device will tag the fourth thread with a first tag. The third thread is a thread in the foreground group, and the fourth thread is a thread in the non-foreground group. The electronic device performs one or more of the following operations on the thread with the first tag: increases the running priority, increases the CPU time slice length, and removes the CPU bandwidth quota. When the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first tag of the fourth thread.

16. The method according to any one of claims 10-15, characterized in that, The foreground group includes the key threads in the first key thread list, and the key dependent threads of the key threads in the first key thread list.

17. The method according to claim 2, characterized in that, The electronic device detects the overall load of the electronic device and / or the device housing temperature, wherein the overall load includes the load of all threads in the electronic device; The electronic device determines a first CPU frequency based on the overall load and / or device case temperature, and controls the CPU frequency when running non-critical threads to be below the first CPU frequency. The non-critical threads include critical threads in the first critical thread list and threads other than critical dependent threads of the critical threads in the first critical thread list.

18. The method according to any one of claims 1-17, characterized in that, The first critical thread is used to complete multi-frame tasks, and the method further includes: During the execution of the first critical thread and the critical dependent thread of the first critical thread, the electronic device determines the first frequency modulation moment based on the CPU frequency modulation cycle, which falls within the time period of the execution of the first frame task in the multi-frame task. At the first frequency modulation moment, the electronic device detects whether the first frame task has been completed; If the first frame task is not completed, the electronic device will increase the CPU frequency to the second CPU frequency according to the first frequency modulation function; The first frequency modulation function is a power function with CPU computing power as the dependent variable, the running time of one frame task in the multi-frame task as the independent variable, and the exponent being a positive number less than 1.

19. The method according to claim 18, characterized in that, The method further includes: If the first frame task is completed, the electronic device will reduce the CPU frequency to a third CPU frequency.

20. The method according to claim 18, characterized in that, The method further includes the following: The start time and completion time of the first frame task are not the frequency adjustment time determined according to the CPU frequency adjustment cycle. When the first frame task is detected to have started running, the electronic device increases the CPU frequency to the fourth CPU frequency; When the completion of the first frame task is detected, the electronic device reduces the CPU frequency to the fifth CPU frequency.

21. The method according to any one of claims 18-20, characterized in that, After the first frame task completes execution, the method further includes: The electronic device determines the time period during which the second frequency modulation moment falls within the second frame task in the multi-frame task based on the CPU frequency modulation cycle. At the second frequency modulation moment, the electronic device detects whether the second frame task has been completed; If the second frame task is not completed, the electronic device increases the CPU frequency to the sixth CPU frequency according to the first frequency modulation function.

22. The method according to any one of claims 18-21, characterized in that, The first key thread is a thread used to determine the content displayed in the user interface, and one frame task in the multi-frame task includes determining the content displayed in one frame of the user interface; or, the first key thread is a thread used to render the user interface, and one frame task in the multi-frame task includes rendering one frame of the user interface.

23. The method according to claim 22, characterized in that, The first frequency modulation function is: Where u(t) is the computing power provided by the CPU of the electronic device at a certain moment, maxUtil is the maximum computing power of the CPU of the electronic device, Time is the time from the current moment to the time when the synchronization signal of the current frame task is issued, the synchronization signal of the current frame task is used to instruct the electronic device to run the current frame task, deadline is the period for the electronic device to refresh the user interface, margin is determined according to the duration of the completion of one or more frames of tasks in the first key thread before the currently running frame task, kk and α are determined according to the historical running data of one or more threads and the CPU energy efficiency curve of the electronic device, the one or more threads include the first key thread and the key dependent threads of the first key thread.

24. The method according to any one of claims 5-9, characterized in that, The first critical dependency thread list is generated based on one or more of the following: the frequency of critical dependency threads appearing on the critical path, the number of times critical dependency threads appear in wake-up relationships, the priority of critical dependency threads on the critical path, the overall priority of critical dependency threads, or the runtime of critical dependency threads.

25. A processor resource management method, characterized in that, The method includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. The electronic device performs one or more of the following operations on the threads in the non-foreground group: adjusts the CPU time slice length of one or more threads in the non-foreground group according to the load rate change of the threads in the foreground group, applies CPU bandwidth quotas to one or more threads in the non-foreground group, and controls the CPU frequency below a first CPU frequency when the CPU is running one or more threads in the non-foreground group.

26. The method according to claim 25, characterized in that, The step of adjusting the CPU time slice length of one or more threads in the non-foreground group based on the load rate change of the threads in the foreground group specifically includes: When the CPU load rate of the threads in the foreground group increases, the electronic device determines a first increase in the CPU time slice length based on the increase in the CPU load rate of the threads in the foreground group. The electronic device increases the CPU time slice length of one or more threads in the foreground group and decreases the CPU time slice length of one or more threads in the non-foreground group according to the first increase amount.

27. The method according to claim 25 or 26, characterized in that, The CPU bandwidth quota allocation for one or more threads in the non-foreground group specifically includes: The electronic device detects the overall load of the electronic device and / or the device case temperature, wherein the overall load includes the CPU load of the threads in the foreground group and the non-foreground group; When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to one or more threads in the non-foreground group based on the first bandwidth quota.

28. The method according to claim 27, characterized in that, The method further includes: When the overall load changes to a second load and / or the device casing temperature changes to a second temperature, the electronic device determines a second bandwidth quota based on the second load and / or the second temperature, and applies CPU bandwidth quotas to one or more threads in the non-foreground group based on the second bandwidth quota. If the second load is higher than the first load and / or the second temperature is higher than the first temperature, then the second bandwidth quota is less than the first bandwidth quota.

29. The method according to claim 25 or 26, characterized in that, The non-foreground group includes a normal thread group and a restricted thread group. The restricted thread group includes threads in the system service that are not associated with the foreground application and can be delayed, and threads in background applications that can be delayed. The normal thread group includes threads in the system service that are not associated with the foreground application and are not in the restricted thread group, and threads in background applications that are not in the restricted thread group. The step of allocating CPU bandwidth quotas to one or more threads in the non-foreground group specifically includes: The electronic device continuously applies CPU bandwidth quotas to one or more threads in the restricted thread group based on a third bandwidth quota. The electronic device detects the overall load and / or the device case temperature of the electronic device. The overall load includes the CPU load of the threads in the foreground group, the non-normal thread group, and the restricted thread group. When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to one or more threads in the normal thread group based on the first bandwidth quota.

30. The method according to any one of claims 25-29, characterized in that, The first CPU frequency is determined based on the overall load of the electronic device and / or the device case temperature, wherein the overall load includes the load of all threads in the electronic device.

31. The method according to any one of claims 25-30, characterized in that, The method further includes: When it is detected that a third thread is waiting for a fourth thread to release a first shared resource or waiting to obtain a first running result from the fourth thread, the electronic device will tag the fourth thread with a first tag. The third thread is a thread in the foreground group, and the fourth thread is a thread in the non-foreground group. The electronic device performs one or more of the following operations on the thread with the first tag: increases the running priority, increases the CPU time slice length, and removes the CPU bandwidth quota. When the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first tag of the fourth thread.

32. An electronic device, characterized in that, The electronic device includes a memory and a processor, wherein the memory is used to store a computer program; the processor executes the computer program to implement the method of any one of claims 1-31.

33. A computationally readable storage medium storing instructions, characterized in that, When the instructions are executed by the processor, they implement the method of any one of claims 1-31.

34. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method of any one of claims 1-31.

Images