An abnormal thread identification method and a computer device

Abstract

The application provides an abnormal thread identification method and a computer device, which can be applied to the field of operating systems and comprises the following steps: firstly, determining the thread power consumption of a thread, which can be an application thread or a system thread; the thread power consumption is used to represent the processor power consumption (such as CPU power consumption) or hardware peripheral (such as a DDS device) power consumption consumed by the thread during a statistical period; determining whether the thread power consumption reaches a preset threshold; if yes, determining that the thread is a suspected abnormal thread; finally, determining whether the suspected abnormal thread meets a preset screening condition; if yes, determining that the suspected abnormal thread is an abnormal thread. The application directly calculates the thread power consumption of a thread in a current statistical period, preliminarily screens a suspected thread causing high power consumption / high heat, and does not need to distinguish whether the thread is an application thread or a system thread in the preliminary screening process, so that the application is more comprehensive; then, a preset screening condition is set to perform secondary screening, so as to reduce false positives and realize accurate identification of abnormal threads.

Description

Technical Field

[0001] This application relates to the field of operating systems, and more particularly to a method for identifying abnormal threads and a computer device. Background Technology

[0002] In terminal products, battery life (Daily Use, DoU) is one of the core Key Performance Indicators (KPIs). Abnormal power consumption threads (or simply abnormal threads) are a critical factor that significantly impacts battery life. However, with the continuous development of terminal products, the challenges to power consumption are increasing, and in practical applications, the probability of abnormal power consumption threads occurring is becoming more and more frequent.

[0003] On the one hand, this is due to the high computational demands of applications: As application functions become increasingly complex, especially in computationally demanding tasks such as Artificial Intelligence (AI) computing and image processing, the consumption of resources such as the Central Processing Unit (CPU), Graphics Processing Unit (GPU), and memory often increases. The probability of applications using incorrect interfaces or infinite loops leading to significant power wastage also increases. On the other hand, the parallelism of applications is increasing: Many third-party applications execute multiple tasks or concurrent processes in the background, especially in applications such as social media, instant messaging, and file synchronization. Concurrency errors are prone to occur, and improper thread synchronization can lead to busy waiting, increasing the probability of high load spikes.

[0004] Identifying and managing threads with abnormal power consumption is the last line of defense for device battery life, ensuring a superior user experience. However, identifying the key abnormal threads causing high power consumption is difficult. Current solutions mainly include the following two approaches: Solution a: Treating application threads with high load values ​​as abnormal threads. However, besides application threads, system threads may also generate abnormalities, requiring careful verification of whether system threads can be managed. Furthermore, high-load threads are not necessarily abnormal threads. Scenario 1: The thread itself has a heavy load, such as game rendering engine threads or web main threads. Scenario 2: The high-load thread is not the primary source of power consumption, such as a background thread running on the lowest frequency of a small core, where the power consumption impact is minimal. In addition, this solution only identifies application-level anomalies and cannot identify system threads. Solution b: Identifying abnormal threads based on CPU duty cycle. However, power consumption varies when threads run on different cores and at different frequencies, leading to a high false positive rate. Summary of the Invention

[0005] This application provides a method and computer device for identifying abnormal threads. It is used to directly and accurately calculate the power consumption of each thread (which can be an application thread or a system thread) running in the current statistical period to initially screen out suspicious threads (i.e. suspected abnormal threads) that cause high power consumption / high heat. In the initial screening process, there is no need to distinguish between application threads and system threads, so the coverage is more comprehensive. Afterwards, preset screening conditions are set for a second screening to reduce false alarms, thereby achieving accurate identification of abnormal threads.

[0006] Based on this, the embodiments of this application provide the following technical solutions:

[0007] Firstly, this application provides a method for identifying abnormal threads. Specifically, this method may include: firstly, determining the power consumption of each thread running (i.e., having run) within the current statistical period. This thread can be an application thread or a system thread; this application does not limit this. Thread power consumption characterizes the processor power consumption (e.g., CPU power consumption, GPU power consumption, etc.) or hardware peripheral power consumption (e.g., the power consumption of a Direct Digital Synthesizer (DDS) device) consumed by the corresponding thread during its operation within the current statistical period. After obtaining the power consumption of each thread that has run within the current statistical period, it can be further determined whether the thread power consumption reaches a preset threshold. If so, the thread is identified as a suspected abnormal thread. Identifying a thread as a suspected abnormal thread is only a preliminary screening process based on thread power consumption. Therefore, after identifying a thread as a suspected abnormal thread, it is necessary to further determine whether the suspected abnormal thread is a true abnormal thread (i.e., a fine screening process) through other means, that is, to further determine whether the suspected abnormal thread meets preset screening conditions. If so, the suspected abnormal thread is identified as an abnormal thread.

[0008] In the above embodiments of this application, the thread power consumption of each thread running in the current statistical period is directly and accurately calculated to initially screen out suspicious threads that cause high power consumption / high heat, i.e. suspected abnormal threads; and in the initial screening process, the threads do not need to be distinguished as application threads or system threads, so the coverage is more comprehensive; then, preset screening conditions are set for further screening (i.e. fine screening) to reduce false alarms, thereby achieving accurate identification of abnormal threads.

[0009] In one possible implementation of the first aspect, after determining that the suspected abnormal thread is an abnormal thread, the method may further include: limiting the runtime of the abnormal thread in the next statistical period.

[0010] Existing solutions suffer from poor control and coarse-grained management, which can affect normal threads. Common methods involve directly killing abnormal threads, which impacts other normal threads within the same process. If the abnormal thread is a foreground application, it can cause application crashes; if it's a critical system process, it may lead to a system restart. In the embodiments described in this application, after identifying an abnormal thread, fine-grained thread-level resource allocation is implemented. This involves limiting the maximum runtime of the abnormal thread in the next cycle, thereby controlling bandwidth. This fine-grained management method only suppresses abnormal threads, without affecting normal threads, ensuring that system resources are prioritized for normal threads. This not only improves resource allocation efficiency and prevents abnormal threads from consuming excessive system resources, but also effectively reduces the power consumption and thermal impact of abnormal threads, thus improving overall performance while ensuring system endurance.

[0011] In one possible implementation of the first aspect, after determining that the suspected abnormal thread is an abnormal thread, the method may further include: not calculating the load of the abnormal thread when it runs in the next statistical period.

[0012] In the above embodiments of this application, after an abnormal thread is identified, the load on the cluster is reduced and the core frequency is reduced by limiting the load settlement of the abnormal thread. The fine-grained control method of this application only suppresses abnormal threads and does not affect normal threads.

[0013] In one possible implementation of the first aspect, after determining that the suspected abnormal thread is an abnormal thread, the method may further include: limiting the computing power requirement of the abnormal thread in the next statistical period.

[0014] In the above embodiments of this application, after an abnormal thread is identified, the maximum computing power requirement of the abnormal thread in the next cycle is limited, thereby affecting the core selection and frequency adjustment of the abnormal thread. The refined control method of this application only suppresses abnormal threads and does not affect normal threads.

[0015] In one possible implementation of the first aspect, thread power consumption may include thread CPU power consumption, which characterizes the CPU power consumed by the thread during its execution within a statistical period. In this case, determining the thread power consumption specifically includes: first, determining the runtime of the CPU corresponding to the thread's execution within the current statistical period at the target CPU frequency; then, determining the thread CPU power consumption based on the target CPU power and the runtime. Since CPU power and CPU frequency have a mapping relationship, the target CPU power can be directly obtained based on the target CPU frequency. It should be noted that since the thread may run multiple times within the current statistical period, each time on a different CPU core and at a different CPU frequency, the statistics here represent the runtime of the thread's execution at the target CPU frequency for each instance within the current statistical period.

[0016] Existing methods for identifying abnormal threads using CPU duty cycle suffer from false positives and false negatives. In the above embodiments of this application, by focusing on key suspicious threads and calculating the CPU power consumption of the threads to filter out suspected abnormal threads, the problem of difficulty in identifying high-heat / high-power abnormal threads is solved.

[0017] In one possible implementation of the first aspect, determining the thread CPU power consumption based on the target CPU power and runtime could be achieved by multiplying the target CPU power by the runtime. That is: Thread CPU power consumption = CPU power of the thread at the target CPU frequency * runtime at the target CPU frequency. It's also important to note that since a thread may run multiple times within the current statistical period, in this case, the target CPU power consumption for each thread is first multiplied by its corresponding runtime, and then the results are summed to obtain the thread CPU power consumption for that thread.

[0018] In the above embodiments of this application, a specific implementation method for calculating CPU power consumption of a thread is described, which is feasible.

[0019] In one possible implementation of the first aspect, the suspected abnormal thread meeting the preset screening conditions may include, but is not limited to: the priority of the suspected abnormal thread is lower than the preset priority; and / or, the suspected abnormal thread does not belong to the whitelist of threads, which is constructed in advance.

[0020] In the above embodiments of this application, several types of suspected abnormal threads that meet the preset screening conditions are specifically described. The priority and whitelist can be set in advance and will not be affected by the relevant data during the operation, thus having wide applicability.

[0021] In one possible implementation of the first aspect, when the suspected abnormal thread is a power domain thread, the suspected abnormal thread has a low priority; and / or, when the suspected abnormal thread is a performance domain thread, the suspected abnormal thread has a high priority; and / or, when the suspected abnormal thread is a mixed domain thread, the suspected abnormal thread has a medium priority.

[0022] In the above embodiments of this application, it is specifically described that priority can be set according to the domain type of the core in which the runtime resides. This division method can basically cover all threads and has broad coverage.

[0023] In one possible implementation of the first aspect, the preset priority can be: high priority, or medium priority.

[0024] In the above embodiments of this application, the preset priority can be customized, which provides flexibility.

[0025] In one possible implementation of the first aspect, the preset screening conditions for suspected abnormal threads may include, but are not limited to: the difference between the thread power consumption and the historical statistical value of the suspected abnormal thread exceeding a preset error range, where the historical statistical value is the statistical average of the thread power consumption of the suspected abnormal thread within a target historical time period; and / or, restricting suspected abnormal threads affecting system performance. It should be noted that in this embodiment, the preset error range can be set based on historical experience values ​​or based on the user's personal needs. For example, if the user wants stricter screening rules, the preset error range can be set smaller. Specifically, this application does not limit the method of setting the preset error range.

[0026] In the above embodiments of this application, several types of suspected abnormal threads that meet preset screening conditions are specifically described. These screening conditions are based on historical data and feedback adjustment, and are related to relevant data during the operation of suspected abnormal threads. They can be dynamically adjusted and are more flexible.

[0027] In one possible implementation of the first aspect, limiting the impact on system performance after a suspected abnormal thread can be achieved by limiting the processor's frame rate drop beyond a preset range after the suspected abnormal thread. It should be noted that in this embodiment, the preset range can be set based on historical experience or user needs. For example, if the user wants stricter filtering rules, the preset range can be set smaller. Specifically, this application does not limit the method of setting the preset range.

[0028] In the above embodiments of this application, a typical judgment method for determining whether the system performance is affected after restricting suspected abnormal threads is specifically described, and it is feasible.

[0029] A second aspect of this application provides a computer device having the function of implementing the method of the first aspect or any possible implementation thereof. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function.

[0030] A third aspect of this application provides a computer device that may include a memory, a processor, and a bus system. The memory is used to store a computer program (also referred to as a program or computer-readable instructions), and the processor is used to invoke the program stored in the memory to execute the method of the first aspect of the embodiments of this application or any possible implementation of the first aspect.

[0031] In some implementations of this application, the computer device may include, but is not limited to: smart terminals (e.g., mobile phones), laptop computers, personal computers (PCs), tablet computers, board computers, speakers, ultrabooks, wearable devices (e.g., smart bracelets, smartwatches, smart glasses, head-mounted displays (HMDs), etc.), augmented reality (AR) devices, virtual reality (VR) devices, mixed reality (MR) devices, cellular phones, personal digital assistants (PDAs), digital broadcasting terminals, etc. Of course, in the following embodiments, no specific form of the computer device is limited. It should be noted that the computer device described in this application can also be various foldable devices, such as foldable mobile phones, foldable PCs, foldable tablet computers, foldable glasses, etc. Specifically, this application does not limit the product type and form of the computer device.

[0032] A fourth aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, enable the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0033] The fifth aspect of this application provides a computer program or a computer program product containing instructions that, when the computer program or computer program product is run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation of the first aspect.

[0034] A sixth aspect of this application provides a chip including at least one processor and at least one interface circuit coupled to the processor. The interface circuit performs transceiver functions and sends instructions to the at least one processor. The at least one processor runs a computer program or instructions, having the functionality to implement the methods described in the first aspect or any possible implementation of the first aspect. This functionality can be implemented in hardware, software, or a combination of hardware and software, including one or more modules corresponding to the described functions. Furthermore, the interface circuit is used to communicate with other modules outside the chip.

[0035] In some implementations of this application, some of the one or more processors may implement some steps of the above method through dedicated hardware. For example, the processing involving neural network models may be implemented by a dedicated neural network processor or graphics processor.

[0036] The method provided in this application embodiment can be implemented by a single chip or by multiple chips working together. Attached Figure Description

[0037] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0038] Figure 2 A flowchart illustrating a method for identifying abnormal threads provided in an embodiment of this application;

[0039] Figure 3 This is a schematic diagram illustrating the running status of each thread that has run within the current statistical period, as provided in an embodiment of this application.

[0040] Figure 4 A schematic diagram illustrating the determination of a suspected abnormal thread as an abnormal thread, provided in an embodiment of this application;

[0041] Figure 5 Another schematic diagram illustrating the determination of a suspected abnormal thread as an abnormal thread, provided in an embodiment of this application;

[0042] Figure 6 A schematic diagram illustrating an example of refined control provided in this application's embodiments;

[0043] Figure 7 Another example of refined control provided in the embodiments of this application is illustrated in the diagram.

[0044] Figure 8 Another example of refined control provided in the embodiments of this application is illustrated in the diagram.

[0045] Figure 9A schematic diagram of a computer device provided in an embodiment of this application;

[0046] Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0047] This application provides a method and computer device for identifying abnormal threads. It is used to directly and accurately calculate the power consumption of each thread (which can be an application thread or a system thread) running in the current statistical period to initially screen out suspicious threads (i.e. suspected abnormal threads) that cause high power consumption / high heat. In the initial screening process, there is no need to distinguish between application threads and system threads, so the coverage is more comprehensive. Afterwards, preset screening conditions are set for a second screening to reduce false alarms, thereby achieving accurate identification of abnormal threads.

[0048] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0049] To better understand the solutions of the embodiments of this application, the relevant terms and concepts that may be involved in the embodiments of this application will be introduced below. It should be understood that the explanation of the relevant concepts may be limited due to the specific circumstances of the embodiments of this application, but it does not mean that this application can only be limited to that specific situation. The specific circumstances of different embodiments may also differ, and no specific limitation is made here.

[0050] (1) Power Anomaly Thread

[0051] A power consumption anomaly thread refers to a thread that wastes a lot of power due to infinite loops caused by code logic or busy waiting caused by incorrect synchronization. In the embodiments of this application, a power consumption anomaly thread can also be simply referred to as an anomaly thread.

[0052] (2) Thread supply management

[0053] This refers to the CPU and CPU frequency that limit the execution of threads. Common control methods include freezing, killing, core migration, and frequency limiting.

[0054] (3) Hardware Peripherals

[0055] Hardware peripherals refer to auxiliary hardware devices in a computer system other than the core processor (such as CPU, GPU, etc.) and main memory. They are connected to the host through buses, interfaces or dedicated channels to extend the system's input, output, storage, communication or other specific functions.

[0056] Based on functional type, hardware peripherals can be divided into input devices (such as touch screens, microphones, sensors, etc.), output devices (such as monitors, speakers, etc.), storage devices (such as hard drives, USB flash drives, etc.), communication devices (such as network cards, Bluetooth chips, Wi-Fi modules, etc.), and mixed-function devices (such as smart card readers). Based on connection method, hardware peripherals can be divided into internal peripherals (such as those integrated inside the motherboard (such as onboard sound cards)) and external peripherals (such as those expanded through interfaces (such as Universal Serial Bus (USB) cameras)).

[0057] (4) CPU frequency and CPU power consumption

[0058] CPU frequency and CPU power consumption are two closely related core parameters that directly affect the processor's performance and energy efficiency.

[0059] CPU frequency represents the number of clock cycles the CPU executes per second, measured in Hertz (Hz), typically in GHz, where 1 GHz = 10⁻⁶. 9 Hz. For example, 3.5GHz means 3.5 billion clock cycles per second. The higher the CPU frequency, the stronger the single-threaded performance (i.e., the more instructions executed per unit time), but the CPU frequency cannot be increased indefinitely. It is mainly limited by: 1. the physical limits of semiconductor processes, such as 7nm and 5nm processes; 2. power consumption and heat generation, as high frequencies will lead to increased voltage and power consumption.

[0060] CPU power consumption refers to the electrical energy consumed by the CPU during operation, usually measured in watts (W). CPU power consumption is a key indicator for measuring CPU energy efficiency and directly affects device performance, heat generation, and battery life.

[0061] There is a corresponding relationship between CPU frequency and CPU power consumption. For example, if the current CPU frequency of a thread is known, the CPU power consumption can be directly obtained based on the corresponding relationship. CPU frequency and CPU power consumption are hardware characteristics.

[0062] (5) Power Domain threads, Performance Domain threads, and Hybrid Domain threads

[0063] In the embodiments of this application, each thread running on a computer device (such as a terminal device) corresponds to its own domain. Threads classified in the power consumption domain are called power consumption domain threads, threads classified in the performance domain are called performance domain threads, and threads classified in the hybrid domain are called hybrid domain threads.

[0064] (6) Cluster

[0065] A cluster is a grouping of physical cores used to optimize power consumption, performance, and design complexity. Cores belonging to the same cluster are frequency-tuned uniformly. For example, if a medium-sized core contains 3 cores, then these 3 cores belong to the same cluster, and these 3 cores belonging to the same cluster can only be frequency-tuned together.

[0066] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0067] First, the system architecture and overall process applied in the methods of the embodiments of this application will be described. For details, please refer to [link / reference needed]. Figure 1 , Figure 1 A schematic diagram of the system architecture provided in this application embodiment. This system architecture may specifically include a statistics unit 101, an identification unit 102, and a supply suppression unit 103, which will be described below:

[0068] (1) Statistical Unit 101

[0069] The statistical unit 101 is used to track and count the thread power consumption / heat of the thread running in each current statistical period based on the constructed thread power consumption calculation model (also known as the energy model). Specifically, it can be obtained based on the thread's runtime, the core of the thread, the core frequency of the thread, etc. After the statistical unit 101 obtains the thread power consumption of the thread running in each current statistical period, it can be used for preliminary screening to obtain suspected abnormal threads.

[0070] (2) Identification unit 102

[0071] The suspected abnormal threads obtained by the initial screening by the statistics unit 101 are further sent to the identification unit 102 for a more refined identification process (i.e. fine screening). Specifically, the identification can be refined based on static screening rules and / or dynamic screening rules. The abnormal threads identified in this way are considered as the final abnormal threads.

[0072] (3) Supply suppression unit 103

[0073] The supply suppression unit 103 will implement refined control measures on the abnormal threads identified by the identification unit 102. Specifically, it can restrict the abnormal threads in the following aspects: runtime, supply, and frequency adjustment. Specifically, it will limit the runtime of the abnormal threads in the next statistical period, not calculate the load of the abnormal threads in the next statistical period, and limit the computing power demand of the abnormal threads in the next statistical period (i.e., the load of the abnormal threads does not affect the frequency adjustment).

[0074] It should be noted that, in the embodiments of this application, Figure 1 The system architecture shown is for illustrative purposes only, and there are no restrictions on the deployment methods of each unit. Figure 1 It may also include more or fewer units / modules, and this application does not limit this to the specifics.

[0075] Based on the above system architecture, the method for identifying abnormal threads provided in the embodiments of this application will be described below. Please refer to the following for details. Figure 2 , Figure 2 A flowchart illustrating the method for identifying abnormal threads provided in this application embodiment may specifically include the following steps:

[0076] 201. Determine the thread power consumption. Thread power consumption is used to characterize the processor power consumption or hardware peripheral power consumption consumed by a thread during its operation within a statistical period.

[0077] First, determine the power consumption of each thread running (i.e., that has run) within the current statistical period. Thread power consumption characterizes the processor power consumption (e.g., CPU power consumption, GPU power consumption, etc.) or hardware peripheral power consumption (e.g., DDS device power consumption) consumed by the corresponding thread during its execution within the current statistical period. For ease of explanation, we will use CPU power consumption as an example for the following description, and will not elaborate further. Specifically, thread CPU power consumption characterizes the CPU power consumption consumed by the thread during its execution within the statistical period.

[0078] It should be noted that, in this embodiment, the determination of thread power consumption can be performed by a monitoring thread on the computer device. This monitoring thread periodically calculates the thread power consumption of threads that have run within each statistical period. For example, assuming the statistical period is T, and the current statistical time is t1 (the previous statistical time is t0, the next statistical time is t2, and so on), then the thread power consumption calculated at time t1 is the thread power consumption within the statistical period [t0, t1], t1 - t0 = T; similarly, at the next statistical time t2, the thread power consumption calculated at time t2 is [t1, t2], t2 - t1 = T. And so on, if the current statistical time is ti, then the thread power consumption calculated at time ti is the thread power consumption within the statistical period [ti-1, ti], ti - (ti-1) = T. It is also important to note that the thread power consumption in each statistical period refers to the thread power consumption of the threads that have run within that statistical period. These threads can be threads that have run once or multiple times. If a thread has run multiple times in the current statistical period, then the thread power consumption refers to the cumulative thread power consumption of the thread across those multiple runs.

[0079] It should be noted that, in this embodiment, thread power consumption is used to characterize the processor power consumption or hardware peripheral power consumption consumed by the corresponding thread during the current statistical period. For ease of explanation, the following uses thread CPU power consumption as an example to illustrate how to determine the thread power consumption of a thread:

[0080] First, determine the runtime of the CPU corresponding to the thread running at the target CPU frequency during the current statistical period. Then, determine the thread CPU power consumption of the thread based on the target CPU power and the runtime. Since there is a mapping relationship between CPU power and CPU frequency, the target CPU power can be directly obtained based on the target CPU frequency.

[0081] It's important to note that since a thread may run multiple times within the current statistical period, each time on a different CPU core and at a different CPU frequency, the statistics here represent the runtime of the thread at its target CPU frequency for each run within the current statistical period. For example, suppose thread A runs k times (k≥1) within the current statistical period, each time on a different CPU core, such as CPU1, CPU2, ..., CPU k (in reality, it can run multiple times on the same CPU core; this is just for illustration). CPU1 runs at the target CPU frequency freq1, CPU2 at the target CPU frequency freq2, ..., CPU k at the target CPU frequency freqk for durations T1, T2, ..., Tk respectively. T1, T2, ..., Tk are the runtimes mentioned above. Since the target CPU frequency of thread A for each run within the current statistical period is known (i.e., freq1, freq2, ..., freqk),... Since CPU power and CPU frequency are mapped, the CPU power corresponding to each target CPU frequency can be determined. Assuming the CPU powers corresponding to freq1, freq2, ..., freqk are p1, p2, ..., pk respectively, then within the current statistical period, based on the CPU powers p1, p2, ..., pk and their corresponding runtimes T1, T2, ..., Tk, the thread CPU power consumption of thread A can be determined. Similarly, for other threads that have run within the current statistical period (e.g., thread B, thread C, ...), their respective thread CPU power consumption can be determined in a similar way to that of thread A; details will not be elaborated here.

[0082] It should be noted that in some embodiments of this application, one way to determine the thread CPU power consumption of a thread based on the target CPU power and runtime is to multiply the target CPU power consumption by the runtime to obtain the thread CPU power consumption, i.e.: Thread CPU power consumption = CPU power of the thread at the target CPU frequency * runtime at the target CPU frequency. It should also be noted that since a thread may run multiple times within the current statistical period, in this case, the target CPU power consumption is first multiplied by its corresponding runtime, and then the results are added together to obtain the thread CPU power consumption.

[0083] To make it easier to understand, we will still use the example of thread A above for illustration:

[0084] Within the current statistical period, based on the CPU power p1, p2, ..., pk of thread A and their respective runtimes T1, T2, ..., Tk, the CPU power consumption of thread A can be determined as: p1*T1 + p2*T2 + ... + pk*Tk.

[0085] To further understand the process of calculating CPU power consumption for threads, a specific example will be used below. Please refer to [link / reference needed]. Figure 3 , Figure 3 This illustrates the execution status of each thread that has run within the current statistical period. Within this current statistical period, threads tcb1, tcb2, tcb3, tcb1, and tcb2 ran in the order they were executed. That is, a total of 3 threads ran within the current statistical period, and threads tcb1 and tcb2 each ran twice.

[0086] Specifically, thread tcb1 ran for T1 hours at CPU frequency freq1 (assuming corresponding CPU power p1) and T4 hours at CPU frequency freq4 (assuming corresponding CPU power p4); thread tcb2 ran for T2 hours at CPU frequency freq2 (assuming corresponding CPU power p2) and T5 hours at CPU frequency freq5 (assuming corresponding CPU power p5); and thread tcb3 ran for T3 hours at CPU frequency freq3 (assuming corresponding CPU power p3). Therefore, based on the above method for calculating thread CPU power consumption, the thread CPU power consumption of thread tcb1 is: p1*T1 + p4*T4; the thread CPU power consumption of thread tcb2 is: p2*T2 + p5*T5; and the thread CPU power consumption of thread tcb3 is: p3*T3.

[0087] It should be noted that the above embodiments of this application are only one example of how to calculate the CPU power consumption of a thread. In practical applications, other methods can also be used to calculate the CPU power consumption of a thread, and this application does not limit this method.

[0088] It should also be noted that, in the embodiments of this application, the power consumption of other processors (such as the GPU power consumption of threads) or the power consumption of hardware peripherals can be calculated in a manner similar to that of CPU power consumption of threads, and will not be elaborated here.

[0089] 202. Determine whether the power consumption of the thread has reached the preset threshold. If yes, proceed to step 203; otherwise, proceed to step 207.

[0090] After obtaining the power consumption of each thread that has run within the current statistical period, it can be further determined whether the power consumption of the thread has reached the preset threshold. If yes, step 203 is executed; otherwise, step 207 is executed.

[0091] It should be noted that, in the embodiments of this application, the preset threshold can be set in various ways, including but not limited to:

[0092] a. The preset threshold can be an absolute value, that is, for all thread power consumption, regardless of whether it is running on a large core, medium core or small core, the calculated thread power consumption is compared with the preset absolute value. If it is higher than or equal to the absolute value, the thread power consumption is considered to have reached the preset threshold. If it is lower than the absolute value, the thread power consumption is considered to have not reached the preset threshold.

[0093] b. The preset threshold can be a preset ratio, that is, for all thread power consumption, if the ratio between the processor power consumption consumed by the thread in the current statistical period and the total power consumption consumed by the processor in the current statistical period is greater than or equal to the preset ratio, then the power consumption of the thread is considered to have reached the preset threshold; if it is lower than the preset ratio, then the power consumption of the thread is considered not to have reached the preset threshold.

[0094] 203. The thread is identified as a suspected abnormal thread.

[0095] Since the thread's power consumption has reached a preset threshold, the thread is identified as a suspected abnormal thread.

[0096] 204. Determine whether the suspected abnormal thread meets the preset screening conditions. If yes, proceed to step 205; otherwise, proceed to step 207.

[0097] Identifying a thread as a suspected abnormal thread is only an initial screening process based on thread power consumption. Therefore, after identifying a thread as a suspected abnormal thread, it is necessary to further determine whether the suspected abnormal thread is indeed an abnormal thread through other means. Therefore, in this step, it is further determined whether the suspected abnormal thread meets the preset screening conditions. If yes, step 205 is executed; otherwise, step 207 is executed.

[0098] It should be noted that in some embodiments of this application, filtering rules can be set from multiple dimensions, including but not limited to:

[0099] A. Static Filtering Rules

[0100] In this embodiment, static filtering rules refer to pre-defined filtering rules that are not affected by data generated during runtime. These static filtering rules include, but are not limited to:

[0101] a1. Priority-based filtering

[0102] In scenario a1, the priorities of each thread are pre-defined. When the priority of a suspected abnormal thread is lower than the preset priority, the suspected abnormal thread is considered to meet the static filtering rule.

[0103] It should be noted that, in the embodiments of this application, the priority can be set in various ways, including but not limited to:

[0104] 1) Set priority based on the domain type of the core in which the thread runs.

[0105] In this case, priority can be set according to the domain type of the core in which the thread runs. For example, if a thread is scheduled to run in a core in the power domain (called a power domain thread), the thread has a low priority; if a thread is scheduled to run in a core in the performance domain (called a performance domain thread), the thread has a high priority; and if a thread is scheduled to run in a core in the hybrid domain (called a hybrid domain thread), the thread has a medium priority.

[0106] It should be noted that, in the embodiments of this application, the preset priority can be medium priority or high priority, and this application does not limit it.

[0107] As an example, assuming the preset priority is medium priority, and assuming the suspected abnormal thread is a power domain thread, since the priority of a power domain thread is low priority, which is lower than the preset medium priority, the suspected abnormal thread is considered to meet the static filtering rule.

[0108] As another example, assuming the preset priority is high, and assuming the suspected abnormal thread is a mixed-domain thread, since the priority of a mixed-domain thread is medium, which is lower than the preset high priority, the suspected abnormal thread is considered to meet the static filtering rule. Similarly, if the suspected abnormal thread is a power domain thread, since the priority of a power domain thread is low, which is also lower than the preset high priority, the suspected abnormal thread is considered to meet the static filtering rule.

[0109] It should be noted that in the above embodiments of this application, the division of thread priorities is illustrated using a three-level division (i.e., high, medium, and low priority). In practical applications, thread priorities can be divided according to actual circumstances, with more levels (e.g., four or six levels) or fewer levels (e.g., two levels). This application does not impose any specific limitations on this. Furthermore, regardless of the number of priority levels, the method of judgment is similar to the above embodiments and will not be repeated here.

[0110] 2) Set priority according to thread type

[0111] In this case, priorities can also be set based on thread type. For example, system threads (also known as kernel threads, managed by the operating system) can be set to high priority, while application threads (managed by user libraries) can be set to low priority.

[0112] As an example, assuming the preset priority is high priority, and assuming the suspected abnormal thread is an application thread, since the application thread has a low priority, which is lower than the preset high priority, the suspected abnormal thread is considered to meet the static filtering rule.

[0113] b1. Whitelist-based filtering

[0114] In scenario b1, a whitelist is pre-built, and threads that meet the criteria for entering the whitelist are added to it. Thus, after the initial screening identifies suspected abnormal threads, it can be directly determined whether the suspected abnormal thread belongs to the whitelist. If the suspected abnormal thread does not belong to the whitelist, it is considered that the suspected abnormal thread meets the static screening rule.

[0115] It should be noted that, in the embodiments of this application, scenarios a1 and b1 are used separately to determine whether a suspected abnormal thread meets the preset screening conditions. That is, when the thread's priority is lower than the preset priority (see details...), the thread is considered abnormal. Figure 4 (a) or the thread is not a whitelisted thread (see section (a) for details). Figure 4 When the thread meets the static filtering rule (as described in part (b)), it is considered to meet the preset filtering conditions (i.e., the thread is confirmed to be an abnormal thread). In other embodiments of this application, the above-mentioned situations a1 and b1 can be combined to determine whether a suspected abnormal thread meets the preset filtering conditions. That is, when the thread's priority is lower than the preset priority and the thread is not a whitelisted thread (see details in [reference]...), the thread is considered to meet the preset filtering conditions. Figure 4 Only if part (c) in the above criteria is the suspected abnormal thread considered to meet the static filtering rules, and only then is the suspected abnormal thread confirmed to meet the preset filtering conditions (i.e., the suspected abnormal thread is confirmed to be an abnormal thread). The combination of priority and whitelist makes the judgment more stringent and can increase the accuracy of abnormal thread identification.

[0116] B. Dynamic Filtering Rules

[0117] In this embodiment, the dynamic filtering rule refers to the rule being affected by data related to the thread's execution process. This dynamic filtering rule includes, but is not limited to:

[0118] a2. Filtering based on historical data

[0119] In scenario a2, the dynamic filtering rule is used to determine whether the suspected abnormal thread meets the criteria based on the historical thread power consumption data of the suspected abnormal thread.

[0120] Specifically, after obtaining the power consumption of the suspected abnormal thread within the current statistical period, it can be further determined whether the difference between the power consumption of the suspected abnormal thread and its historical statistical value is within a reasonable error range (i.e., a preset error range). The historical statistical value is the statistical average of the power consumption of the suspected abnormal thread over a past historical period (which can be called the target historical period, such as the past month). If the difference exceeds the reasonable error range, the suspected abnormal thread is considered to meet the dynamic filtering rule. It should be noted that in this embodiment, the preset error range can be set based on historical experience values ​​or based on the user's personal needs. For example, if the user wants a stricter filtering rule, the preset error range can be set smaller. This application does not limit the specific method for setting the preset error range.

[0121] b2. Screening based on feedback adjustment

[0122] In scenario b2, the dynamic filtering rule is determined by observing whether the system performance is affected after restricting the suspected abnormal thread.

[0123] Specifically, after restricting the suspected abnormal thread, it can be determined whether the decrease in the processor's frame rate after restricting the suspected abnormal thread exceeds a reasonable range (i.e., a preset range). If it does, the suspected abnormal thread is considered to meet the dynamic filtering rule. If it does not exceed the limit, it means that the suspected abnormal thread will not affect the user experience, and the thread restriction on the suspected abnormal thread can be lifted. It should be noted that in this embodiment, the preset range can be set based on historical experience values ​​or based on the user's personal needs. For example, if the user wants a stricter filtering rule, the preset range can be set smaller. This application does not limit the specific method of setting the preset range.

[0124] Similar to the static filtering rules described above, in this embodiment, scenarios a2 and b2 are used individually to determine whether a suspected abnormal thread meets the preset filtering conditions. In other embodiments of this application, scenarios a2 and b2 can be combined to determine whether a suspected abnormal thread meets the preset filtering conditions; this application does not limit the specifics of this method.

[0125] It should also be noted that, in the embodiments of this application, the above-mentioned static filtering rules and dynamic filtering rules are used separately to determine whether a suspected abnormal thread meets the preset filtering conditions. That is: when the thread meets the above-mentioned static filtering rules (see details...), the thread is considered abnormal. Figure 5(a) in the text), or, when the thread meets the above dynamic filtering rules (see details in [reference]). Figure 5 When the thread meets the preset screening condition (i.e., the suspected abnormal thread is confirmed as an abnormal thread), it is considered to meet the preset screening condition (i.e., the suspected abnormal thread is confirmed as an abnormal thread). In other embodiments of this application, the above-mentioned static screening rules and dynamic screening rules can be combined to determine whether a suspected abnormal thread meets the preset screening condition. That is, when the thread meets both the above-mentioned static screening rules and dynamic screening rules (see [reference] for details)... Figure 5 Only when the condition in part (c) is met is the suspected abnormal thread considered to meet the preset screening condition (i.e., the suspected abnormal thread is confirmed to be an abnormal thread). The false alarms of abnormal threads are reduced by combining static and dynamic screening rules.

[0126] 205. The suspected abnormal thread has been confirmed as an abnormal thread.

[0127] Since the suspected abnormal thread meets the preset screening criteria, it is determined that the suspected abnormal thread is an abnormal thread.

[0128] 206. Implement fine-grained control over this abnormal thread.

[0129] After confirming that a suspected abnormal thread is indeed an abnormal thread, further refined management can be implemented in the next statistical period. For example, thread-level refined supply suppression can be applied to this thread. Refined management methods include, but are not limited to:

[0130] A. Limit the runtime of abnormal threads in the next statistical period.

[0131] One method of fine-grained control is to limit the CPU runtime of the abnormal thread.

[0132] To facilitate understanding, a specific example will be used below. Please refer to [link / reference needed] for details. Figure 6 Assuming a statistical period of 100 milliseconds (ms), and limiting the bandwidth of an abnormal thread to 50ms, then after limiting the abnormal thread, the thread's CPU duty cycle will be approximately 50%, with the remaining 50% of the time spent in the Runnable state. The advantage of this is that the abnormal thread does not affect the supply of resources for other tasks. Other normal tasks can continue to use the CPU as usual.

[0133] B. Do not calculate the load of abnormal threads running in the next statistical period.

[0134] Another method of fine-grained management is to limit the cumulative load of the abnormal thread, that is, not to calculate the load of the abnormal thread in the next statistical period.

[0135] To facilitate understanding, a specific example will be used below. Please refer to [link / reference needed] for details. Figure 7 ,exist Figure 7 In this scenario, assuming the CPU is currently running Thread 1, Thread 2, and Thread 3 within the current statistical period, and Thread 2 is an abnormal thread identified in the previous statistical period, if no restrictions are placed on this abnormal thread Thread 2, the cumulative load of Thread 1, Thread 2, and Thread 3 will be calculated during load calculation. This will lead to high cluster load, requiring the CPU to operate at a higher frequency. However, if the load calculation for this abnormal thread Thread 2 is restricted, effectively eliminating power domain load, the cluster load will be low, allowing the CPU to operate at a lower frequency.

[0136] C. Limit the computing power requirement of abnormal threads in the next statistical period.

[0137] Another method of fine-grained management is to limit the computing power demand of the abnormal thread in the next statistical period. That is, in the next statistical period, by limiting the maximum computing power demand of the thread, the selection of cores and frequency adjustment of the thread are affected. This method can also be called MaxUtil load management, or Max Util for short. Specifically, through scheduling, cores that meet the computing power demand of the thread can be selected, and Max Util will try to select threads for smaller cores. In addition, the maximum computing power demand can be calculated according to the tasks of the cluster to reduce the contribution of abnormal threads to frequency adjustment.

[0138] To facilitate understanding, a specific example will be used below. Please refer to [link / reference needed] for details. Figure 8 Assuming the highest and lowest frequencies of the small, medium, and large cores are as follows: Figure 8 As shown on the right, assuming Task 1 is an abnormal thread with an initial util of 900, this application can set the max util to 100. In the event of an abnormality, the highest frequency is selected on the large core, and then controlled by max util on the small core. If there are no other tasks, a lower frequency is selected. The advantage of this is that it does not affect the computing power supply of other tasks. Assuming Task 2's computing power requirement is 200, the small core will be adjusted to the highest frequency, without affecting the computing power supply of Task 2.

[0139] 207. End the identification of the current thread.

[0140] If the thread power consumption of the thread does not reach the preset threshold, or if the suspected abnormal thread does not meet the preset screening conditions, it means that the thread was not considered an abnormal thread in the initial screening or fine screening process, and the identification of the current thread ends at this time.

[0141] It should be noted that in some embodiments of this application, the identification and control processes of abnormal threads in steps 201 to 207 can all be implemented by a specific thread (which may be called the target thread) on a computer device (e.g., a terminal device); different threads can also implement different processes. For example, the monitoring thread on the computer device can perform statistics on the power consumption of each thread and identify suspected and abnormal threads. When the thread is identified as an abnormal thread, the situation of the abnormal thread is reported to the control thread, and the control thread performs fine-grained control on the identified abnormal thread. This application does not limit the specifics of this.

[0142] In summary, the method of this application includes two core points: First, it achieves accurate identification of abnormal threads based on thread-level power consumption calculation, first screening out suspected abnormal threads, and then finely screening out the real abnormal threads; Second, it provides fine-grained supply suppression at the thread level, by restricting abnormal threads (e.g., reducing runtime, restricting core selection and frequency adjustment), and ensuring that the restriction does not affect normal tasks and other threads, thereby guaranteeing the battery life experience (traditional control methods such as killing threads, relocating cores, and limiting frequency are not fine enough and will affect normal threads; this application only suppresses abnormal threads and does not affect normal threads).

[0143] It should be noted that the methods described in the above embodiments of this application can be applied to various computer devices, including but not limited to: smart terminals (e.g., mobile phones), laptops, PCs, tablet computers, board computers, speakers, ultrabooks, wearable devices (e.g., smart bracelets, smartwatches, smart glasses, HMDs, etc.), AR devices, VR devices, MR devices, cellular phones, PDAs, digital broadcasting terminals, etc. Of course, the specific form of the computer device is not limited in the following embodiments. It should be noted that the computer device described in this application can also be various foldable devices, such as foldable mobile phones, foldable personal computers, foldable tablet computers, foldable glasses, etc. Specifically, this application does not limit the product type and form of the computer device.

[0144] Based on the above embodiments, in order to better implement the above solutions of this application, related equipment for implementing the above solutions is also provided below. See details. Figure 9 , Figure 9This is a schematic diagram of a computer device provided in an embodiment of this application. The computer device 900 may specifically include: a power consumption statistics module 901, a first determination module 902, and a second determination module 903. The power consumption statistics module 901 is used to determine the thread power consumption of a thread, which is used to characterize the processor power consumption or hardware peripheral power consumption consumed by the thread during operation within a statistical period. The first determination module 902 is used to determine the thread as a suspected abnormal thread when the thread power consumption reaches a preset threshold. The second determination module 903 is used to determine the suspected abnormal thread as an abnormal thread when the suspected abnormal thread meets preset screening conditions.

[0145] In one possible design, the second determining module 903 is further configured to: after determining that the suspected abnormal thread is an abnormal thread, limit the runtime of the abnormal thread in the next statistical period.

[0146] In one possible design, the second determining module 903 is further configured to: after determining that the suspected abnormal thread is an abnormal thread, not calculate the load of the abnormal thread when it runs in the next statistical period.

[0147] In one possible design, the second determining module 903 is further used to: after determining that the suspected abnormal thread is an abnormal thread, limit the computing power requirement of the abnormal thread in the next statistical period.

[0148] In one possible design, thread power consumption includes thread CPU power consumption, which is used to characterize the CPU power consumption consumed by the thread during the statistical period. The power consumption statistics module 901 is specifically used to: determine the runtime of the CPU corresponding to the thread running at the target CPU frequency during the statistical period; and determine the thread CPU power consumption of the thread based on the target CPU power and the runtime, wherein the target CPU power is obtained based on the target CPU frequency.

[0149] In one possible design, the power consumption statistics module 901 is further used to: multiply the target CPU power by the runtime to obtain the thread CPU power consumption of the thread.

[0150] In one possible design, the suspected abnormal thread meets the preset screening conditions, including: the priority of the suspected abnormal thread is lower than the preset priority; and / or, the suspected abnormal thread does not belong to the whitelist of threads, which is pre-built.

[0151] In one possible design, if the suspected abnormal thread is a power domain thread, the suspected abnormal thread has a low priority; and / or, if the suspected abnormal thread is a performance domain thread, the suspected abnormal thread has a high priority; and / or, if the suspected abnormal thread is a mixed domain thread, the suspected abnormal thread has a medium priority.

[0152] In one possible design, the preset priority includes: high priority, or medium priority.

[0153] In one possible design, the pre-defined screening criteria for the suspected abnormal thread also include: the difference between the thread's power consumption and the historical statistical value of the suspected abnormal thread exceeds a pre-defined error range, where the historical statistical value is the statistical average of the thread's power consumption over a target historical period; and / or, restricting the suspected abnormal thread affects system performance.

[0154] In one possible design, the impact on system performance after limiting the suspected abnormal thread includes limiting the processor's frame rate drop beyond a preset range after the suspected abnormal thread.

[0155] It should be noted that the information interaction and execution process between the modules / units in the computer device 900 are based on the same concept as the method embodiments described above in this application. For details, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0156] Next, we will introduce another computer device provided in the embodiments of this application. Please refer to [link / reference]. Figure 10 , Figure 10 This is a schematic diagram of a computer device provided in an embodiment of this application. The computer device 1000 may be equipped with... Figure 9 The module described in the corresponding embodiment is used to implement Figure 9Corresponding to the functionality of the computer device 900 in the embodiment, specifically, the computer device 1000 is implemented by one or more servers. The computer device 1000 can vary significantly due to differences in configuration or performance, and may include one or more central processing units 1022 and memory 1032, and one or more storage media 1030 (e.g., one or more mass storage devices) for storing application programs 1042 or data 1044. The memory 1032 and storage media 1030 can be temporary or persistent storage. The program stored in the storage media 1030 may include one or more modules (not shown in the figure), each module including a series of instruction operations on the computer device 1000. Furthermore, the central processing unit 1022 may be configured to communicate with the storage media 1030 and execute the series of instruction operations in the storage media 1030 on the computer device 1000.

[0157] Computer device 1000 may also include one or more power supplies 1026, one or more wired or wireless network interfaces 1050, one or more input / output interfaces 1058, and / or one or more operating systems 1041, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0158] In this embodiment, the central processing unit 1022 is used to execute... Figure 2 The steps performed by the computer device in the corresponding embodiment are as follows. For example, the central processing unit 1022 can be used to: First, determine the thread power consumption of each thread running in the current statistical period, wherein the thread power consumption is used to characterize the processor power consumption (such as CPU power consumption, GPU power consumption, etc.) or hardware peripheral power consumption (such as the power consumption of a DDS device) consumed by the corresponding thread during the current statistical period. After obtaining the thread power consumption of each thread that has run in the current statistical period, it can be further determined whether the thread power consumption reaches a preset threshold. If so, the thread is determined to be a suspected abnormal thread. Determining the thread as a suspected abnormal thread is only a preliminary screening process for abnormal threads based on thread power consumption. Therefore, after determining the thread as a suspected abnormal thread, it is necessary to further determine whether the suspected abnormal thread is a real abnormal thread through other means: that is, to further determine whether the suspected abnormal thread meets the preset screening conditions. If so, the suspected abnormal thread is determined to be an abnormal thread.

[0159] It should be noted that the specific manner in which the central processing unit 1022 executes the above steps is different from that described in this application. Figure 2The corresponding method embodiments are based on the same concept, and the technical effects they bring are the same as those in the above embodiments of this application. For details, please refer to the description in the method embodiments shown above in this application, which will not be repeated here.

[0160] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0161] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0162] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0163] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for identifying abnormal threads, characterized in that, include: Determine the thread power consumption of a thread, wherein the thread power consumption is used to characterize the processor power consumption or hardware peripheral power consumption consumed by the thread during the operation of the statistical period. If the power consumption of the thread reaches a preset threshold, the thread is determined to be a suspected abnormal thread. If the suspected abnormal thread meets the preset screening conditions, the suspected abnormal thread is determined to be an abnormal thread.

2. The method according to claim 1, characterized in that, After determining that the suspected abnormal thread is an abnormal thread, the method further includes: Limit the runtime of the abnormal thread in the next statistical period.

3. The method according to any one of claims 1-2, characterized in that, After determining that the suspected abnormal thread is an abnormal thread, the method further includes: The load of the abnormal thread during the next statistical period is not calculated.

4. The method according to any one of claims 1-3, characterized in that, After determining that the suspected abnormal thread is an abnormal thread, the method further includes: Limit the computing power requirement of the abnormal thread in the next statistical period.

5. The method according to any one of claims 1-4, characterized in that, The thread power consumption includes the thread's CPU power consumption, which characterizes the CPU power consumption consumed by the thread during the statistical period. Determining the thread power consumption includes: Determine the runtime of the CPU corresponding to the thread running at the target CPU frequency during the statistical period; The thread CPU power consumption of the thread is determined based on the target CPU power and the runtime, wherein the target CPU power is obtained based on the target CPU frequency.

6. The method according to claim 5, characterized in that, Determining the thread CPU power consumption of the thread based on the target CPU power and the runtime includes: Multiply the target CPU power by the runtime to obtain the thread CPU power consumption of the thread.

7. The method according to any one of claims 1-6, characterized in that, The suspected abnormal threads meet the preset screening criteria, including: The priority of the suspected abnormal thread is lower than the preset priority; And / or, The suspected abnormal thread is not a thread in the whitelist, which is constructed in advance.

8. The method according to claim 7, characterized in that, If the suspected abnormal thread is a power domain thread, the suspected abnormal thread has a low priority. And / or, If the suspected abnormal thread is a performance domain thread, the suspected abnormal thread has a high priority. And / or, When the suspected abnormal thread is a mixed-domain thread, the priority of the suspected abnormal thread is medium priority.

9. The method according to claim 8, characterized in that, The preset priority includes: High priority, or medium priority.

10. The method according to any one of claims 1-9, characterized in that, The suspected abnormal threads that meet the preset screening criteria also include: The difference between the power consumption of the thread and the historical statistical value of the suspected abnormal thread exceeds the preset error range. The historical statistical value is the statistical average of the power consumption of the suspected abnormal thread within the target historical time period. And / or, Restricting the suspected abnormal threads affected system performance.

11. The method according to claim 10, characterized in that, The impact on system performance after restricting the suspected abnormal threads includes: The frame rate drop of the processor after the suspected abnormal thread is limited to a preset range.

12. A computer device, characterized in that, include: The power consumption statistics module is used to determine the power consumption of a thread, which is used to characterize the processor power consumption or hardware peripheral power consumption consumed by the thread during the statistical period. The first determining module is used to determine that the thread is a suspected abnormal thread when the thread power consumption reaches a preset threshold. The second determining module is used to determine that the suspected abnormal thread is an abnormal thread if the suspected abnormal thread meets the preset screening conditions.

13. The device according to claim 12, characterized in that, The second determining module is further used for: After determining that the suspected abnormal thread is indeed an abnormal thread, the runtime of the abnormal thread in the next statistical period is limited.

14. The device according to any one of claims 12-13, characterized in that, The second determining module is further used for: After determining that the suspected abnormal thread is an abnormal thread, the load of the abnormal thread during the next statistical period is not calculated.

15. The device according to any one of claims 12-14, characterized in that, The second determining module is further used for: After confirming that the suspected abnormal thread is indeed an abnormal thread, the computing power requirement of the abnormal thread in the next statistical period is limited.

16. The device according to any one of claims 12-15, characterized in that, The thread power consumption includes the thread CPU power consumption, which characterizes the CPU power consumption consumed by the thread during the statistical period. The power consumption statistics module is specifically used for: Determine the runtime of the CPU corresponding to the thread running at the target CPU frequency during the statistical period; The thread CPU power consumption of the thread is determined based on the target CPU power and the runtime, wherein the target CPU power is obtained based on the target CPU frequency.

17. The device according to claim 16, characterized in that, The power consumption statistics module is further used for: Multiply the target CPU power by the runtime to obtain the thread CPU power consumption of the thread.

18. The device according to any one of claims 12-17, characterized in that, The suspected abnormal threads meet the preset screening criteria, including: The priority of the suspected abnormal thread is lower than the preset priority; And / or, The suspected abnormal thread is not a thread in the whitelist, which is constructed in advance.

19. The device according to claim 18, characterized in that, If the suspected abnormal thread is a power domain thread, the suspected abnormal thread has a low priority. And / or, If the suspected abnormal thread is a performance domain thread, the suspected abnormal thread has a high priority. And / or, When the suspected abnormal thread is a mixed-domain thread, the priority of the suspected abnormal thread is medium priority.

20. The device according to claim 19, characterized in that, The preset priority includes: High priority, or medium priority.

21. The device according to any one of claims 12-20, characterized in that, The suspected abnormal threads that meet the preset screening criteria also include: The difference between the power consumption of the thread and the historical statistical value of the suspected abnormal thread exceeds the preset error range. The historical statistical value is the statistical average of the power consumption of the suspected abnormal thread within the target historical time period. And / or, Restricting the suspected abnormal threads affected system performance.

22. The device according to claim 21, characterized in that, The impact on system performance after restricting the suspected abnormal threads includes: The frame rate drop of the processor after the suspected abnormal thread is limited to a preset range.

23. A computer device comprising a processor and a memory, the processor being coupled to the memory, characterized in that, The memory is used to store programs; The processor is configured to execute a program in the memory, causing the computer device to perform the method as described in any one of claims 1-11.

24. A computer storage medium, characterized in that, The device stores computer-readable instructions, which, when executed by a processor, implement the method as described in any one of claims 1-11.

25. A computer program product, characterized in that, The computer program product includes computer-readable instructions that, when executed by a processor, implement the method as described in any one of claims 1-11.

26. A chip, the chip comprising a processor and a data interface, characterized in that, The processor reads instructions stored in the memory through the data interface and executes the method as described in any one of claims 1-11.

Images