Method for detecting game core thread
By mounting events in the kernel interface in the computing device and calculating the total time cost of the threads, determining the core thread of the program, the performance degradation problem when high-performance processor cores are migrated to low-performance processor cores is solved, and priority processing and performance improvement of threads that are crucial to program performance are achieved.
Patent Information
- Application Number
- CN202280099716.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-08
- Publication Date
- 2025-04-11
AI Technical Summary
In computing devices, when the load of threaded tasks that are critical to the performance of the program is low, migration from a high-performance processor core to a low-performance processor core leads to degradation of program performance.
The event is mounted through the kernel interface, and the total time cost of the thread is calculated, and it is returned with the thread identifier to the core thread identifier program to determine the core thread of the program.
Effectively identify and prioritize threads that are crucial to program performance, mitigate the impact of performance degradation, and improve the overall performance of the program.
Smart Images

Figure CN119817075A_ABST
Abstract
Description
Background Art
[0001] The computing device is implemented with processor cores configured for different performance levels. A program running on the computing device may suffer performance degradation when threads that are critical to the performance of the program are migrated from one processor core to another processor core configured for a lower performance level when the thread's thread task load is low, are preempted for other threads running concurrently, and are preempted for less critical threads. Summary of the invention
[0002] The various aspects disclosed include apparatus and methods for identifying a core thread of a program executed by a processor. Various aspects may include: mounting an event by a kernel interface; calculating a total time cost for executing a thread of the program based on mounting the event by the kernel interface; returning the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program by a kernel of the processor; and determining the core thread of the program based on the total time cost for executing the thread and the thread identifier of the thread by the core thread identifier program. Some aspects may also include: calculating the duration of at least one task of a thread based on mounting the event. In some aspects, the event includes a switch-in for a running processor execution state of the processor and a switch-out for a running processor execution state.
[0003] Some aspects may also include: calculating the aggregate duration of at least one task used to execute the thread based on the mount event, and determining whether the aggregate duration of at least one task used to execute the thread exceeds an aggregate threshold, wherein calculating the total time cost of the thread used to execute the program based on the mount event includes: calculating the total time cost of the thread used to execute the program in response to determining that the aggregate duration of at least one task used to execute the thread exceeds the aggregate threshold.
[0004] Some aspects may also include calculating a representation of a total time cost for executing the thread.
[0005] Some aspects may also include: comparing a representation of the total time cost for executing a thread with at least one other representation of the total time cost for executing a thread, wherein determining a core thread of a program includes: comparing a result of comparing the representation of the total time cost for executing a thread with at least one other representation of the total time cost for executing a thread with at least one range of values, within which the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing a thread is a core thread.
[0006] Additional aspects include a computing device having a processing device configured to perform the operations of any of the methods outlined above. Additional aspects include a computing device having components for performing the functions of any of the methods outlined above. Additional aspects include a non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a processor and other components of the computing device to perform the operations of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate example embodiments in various embodiments and, together with the general description given above and the detailed description given below, serve to explain features of the claims.
[0008] Figure 1 is a component block diagram illustrating an example computing device suitable for implementing various embodiments.
[0009] Figure 2 is a component block and process flow diagram illustrating an example of a program core thread detection system for implementing various embodiments.
[0010] Figure 3 is a block diagram illustrating an example of the progression of execution states of a processor executing a thread for implementing various embodiments.
[0011] Figure 4 is a process flow diagram illustrating a method for detecting program core threads according to various embodiments.
[0012] Figure 5 is a process flow diagram illustrating a method for detecting program core threads according to some embodiments.
[0013] Figure 6 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.
[0014] Figure 7 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.
[0015] Figure 8 is a component block diagram illustrating an example server suitable for implementing various embodiments. DETAILED DESCRIPTION
[0016] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.
[0017] Various embodiments include methods for detecting program core threads and computing devices that implement such methods. Various embodiments may include methods for performing the following operations: mounting events implemented in the kernel of the execution program, using events to calculate the total time cost of task execution of threads on the processor core, and reporting the total time cost of execution and the thread identifier of the thread to the user program. Some embodiments may also include: receiving the total time cost of execution and the thread identifier of the thread from the kernel, and using the total time cost of execution and the thread identifier of the thread to identify the core thread of the execution program. In some embodiments, the program being executed may be a game program, which may have threads that are critical to the performance of the program.
[0018] The term "computing device" may refer to fixed computing devices, including personal computers, desktop computers, stand-alone computers, workstations, supercomputers, mainframe computers, embedded computers (such as in vehicles and other larger systems), computerized vehicles (e.g., partially or fully autonomous ground, air, and / or water vehicles, such as passenger vehicles, commercial vehicles, recreational vehicles, military vehicles, drones, etc.), servers, multimedia computers, and game consoles. The terms "computing device" and "mobile computing device" are used interchangeably herein to refer to any or all of the following: cellular phones, smart phones, personal or mobile multimedia players, personal data assistants (PDAs), laptop computers, tablet computers, convertible laptop / tablet computers (2-in-1 computers), smartbooks, ultrabooks, netbooks, palmtop computers, wireless email receivers, Internet-enabled multimedia cellular phones, mobile game consoles, wireless game controllers, and similar personal electronic devices that include memory and a programmable processor.
[0019] For ease of explanation and clarity, although various embodiments are described in terms of code (e.g., processor executable instructions), similarly applicable are any data, such as code, program data, or other information stored in memory. The terms "code," "data," and "information" are used interchangeably herein and are not intended to limit the scope of the claims and specification to the types of code, data, or information used as examples in describing various embodiments.
[0020] A program running on a processor within a computing device may suffer performance degradation when threads critical to the program's performance are migrated from processor cores configured for certain performance levels to processor cores configured for lower performance levels, preempted for other threads running concurrently, and preempted for less critical threads when the threads' task load is low. For example, a gaming program may suffer from reduced responsiveness to user input or reduced smoothness of image display on a computing device display (e.g., increased stuttering or artifacts).
[0021] Various embodiments can be used to solve the aforementioned problems by identifying threads that are critical to the performance of the program so that performance reduction mitigation can be achieved for the threads. Identifying threads that are critical to the performance of the program is critical to solving the aforementioned problems. In the absence of threads that are critical to the performance of the program, performance reduction mitigation may not be achieved for the program, and / or performance reduction mitigation may not be effectively achieved. Examples of using threads that are critical to the performance of the program to mitigate performance reduction may include assigning threads to processor cores configured for certain performance levels and / or assigning priority levels to threads that can be used to avoid preemption of threads.
[0022] The core thread identifier program may instruct a kernel interface (e.g., Berkeley Packet Filter (BPF), eBPF) to mount an event for a program executing in the kernel. The kernel interface may identify one or more running tasks of one or more threads of one or more processor cores and calculate one or more total time costs of execution of the one or more threads. The kernel interface may report the one or more total time costs of execution and one or more thread identifiers of the one or more threads to the core thread identifier program.
[0023] The core thread identifier program can use one or more total time costs of execution and one or more thread identifiers of one or more threads to identify one or more core threads of the execution program. The core thread identifier program can store one or more total time costs of execution and one or more thread identifiers of one or more threads in association with each other. The one or more total time costs of execution can be sorted and compared by the core thread identifier program to identify which threads of the one or more associated threads are one or more core threads of the execution program. The core thread of the execution program can be a thread that is critical to the performance of the program. For example, the execution program can be a game program, and the core thread may be critical to the performance of the program, regarding responsiveness to user input, smoothness of image display on a computing device display (e.g., increased stuttering or artifacts), etc.
[0024] Figure 1A system including a computing device 100 suitable for use with various embodiments is illustrated. The computing device 100 may include a SoC 102 having a central processing unit 104, a memory 106, a communication interface 108, a memory interface 110, a peripheral device interface 120, and a processing device 124. The computing device 100 may also include a communication component 112 (such as a wired or wireless modem), a memory 114, an antenna 116 for establishing a wireless communication link, and / or a peripheral device 122. The processor 124 may include any of a variety of processing devices (e.g., multiple processor cores).
[0025] The term "system on chip" or "SoC" is used herein to refer to a group of interconnected electronic circuits, typically but not exclusively including a processing device, a memory, and a communication interface. The processing device may include a variety of different types of processors 124 and / or processor cores, such as a general-purpose processor, a central processing unit (CPU) 104, a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a security processing unit (SPU), an intellectual property unit (IPU), a subsystem processor for a specific component of the computing device (such as an image processor for a camera subsystem or a display processor for a display), an auxiliary processor, a peripheral device processor, a single-core processor, a multi-core processor, a controller, and / or a microcontroller. The processing device may further implement other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), other programmable logic devices, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and / or a time reference. The integrated circuit may be configured so that the components of the integrated circuit reside on a single piece of semiconductor material (such as silicon).
[0026] SoC 102 may include one or more CPUs 104 and processors 124. Computing device 100 may include more than one SoC 102, thereby increasing the number of CPUs 104, processors 124, and processor cores. Computing device 100 may also include CPUs 104 and processors 124 that are not associated with SoC 102. Individual CPUs 104 and processors 124 may be multi-core processors. CPUs 104 and processors 124 may each be configured for a specific purpose that may be the same or different from other CPUs 104 and processors 124 of computing device 100 and / or be configured with specific performance parameters that may be the same or different from them. For example, CPUs 104 and processors 124 may be configured to operate at different frequencies, which may be described in relative terms such as high / higher frequency / performance and low / lower frequency / performance with respect to each other. For another example, one or more of the CPUs 104 and / or processors 124 may be high performance CPUs 104 and / or processors 124 relative to one or more other CPUs 104 and / or processors 124. Similarly, one or more of the CPUs 104 and / or processors 124 may be low performance CPUs 104 and / or processors 124 relative to one or more other CPUs 104 and / or processors 124. In some examples, high performance CPUs 104 and / or processors 124 may be referred to as gold CPUs 104, processors 124, and / or cores, while low performance CPUs 104 and / or processors 124 may be referred to as silver CPUs 104, processors 124, and / or cores. One or more of the CPUs 104, processors 124, and processor cores of the same or different configurations may be grouped together. A group of CPUs 104, processors 124, or processor cores may be referred to as a multi-processor cluster.
[0027] The memory 106 of SoC 102 may be a volatile or non-volatile memory configured to store data and processor executable code for access by CPU 104, processor 124 or other components of SoC 102. The computing device 100 and / or SoC 102 may include one or more memories 106 configured for various purposes. One or more memories 106 may include volatile memory, such as random access memory (RAM) or main memory, or cache memory. These memories 106 may be configured to temporarily hold a limited amount of data received from a data sensor or subsystem, data and / or processor executable code instructions loaded from non-volatile memory to memory 106 in anticipation of future access based on various factors requested from non-volatile memory, and / or intermediate processing data and / or processor executable code instructions generated by CPU 104 and / or processor 124 and temporarily stored for fast access without being stored in non-volatile memory. In some embodiments, any number and combination of memories 106 may include one-time programmable or read-only memory.
[0028] The memory 106 may be configured to at least temporarily store data and processor executable code loaded into the memory 106 from another memory device, such as another memory 106 or memory 114, for access by one or more of the CPU 104, the processor 124, or other components of the SoC 102. The data or processor executable code loaded into the memory 106 may be loaded in response to the CPU 104, the processor 124, or other components of the SoC 102 performing a function. The loading of the data or processor executable code into the memory 106 in response to the execution of the function may originate from a memory access request to another memory 106 or memory 114, and the data or processor executable code may be loaded into the memory 106 for later access.
[0029] The memory interface 110 and the memory 114 may work together to allow the computing device 100 to store data and processor executable code on volatile and / or non-volatile storage media and retrieve data and processor executable code from the volatile and / or non-volatile storage media. The memory 114 may be configured like the embodiment of the memory 106, where the memory 114 may store data or processor executable code for access by one or more of the CPU 104, the processor 124, or other components of the SoC 102. In some embodiments, the non-volatile memory 114 may retain information after the computing device 100 has been powered off. When power is re-applied and the computing device 100 restarts, the information stored on the memory 114 may be available to the computing device 100. In some embodiments, the volatile memory 114 may not retain information after the computing device 100 has been powered off. The memory interface 110 may control access to the memory 114 and allow the CPU 104, the processor 124, or other components of the SoC 12 to read data from and write data to the memory 114.
[0030] Some or all of the components of computing device 100 and / or SoC 102 may be arranged and / or combined differently while still providing the functionality of various embodiments. Computing device 100 may not be limited to one of each component, and multiple instances of each component may be included in various configurations of computing device 100.
[0031] Figure 2 An example of a program core thread detection system for implementing various embodiments is illustrated. Figure 1 and Figure 2 , the program core thread detection system 200 can be implemented on any number and combination of processors (e.g., Figure 1 The core thread identifier program 202 may be implemented in a CPU 104, a processor 124 in the processor, and may include a core thread identifier program 202 and a kernel / operating system 210 (e.g., a Unix-like kernel, a Windows-like kernel). The core thread identifier program 202 may be configured to instruct the kernel 210 to provide the core thread identifier program 202 with the total time cost of execution of threads of a program executed on the processor and thread identifiers of the threads, and to determine which threads are core threads. The kernel 210 may be configured to track the task execution time of threads of a program executed on the processor, determine the total time cost of execution of the threads, and provide the core thread identifier program 202 with the total time cost of execution and thread identifiers of the threads.
[0032] The core thread identifier program 202 may include a thread detection module 204, a perf event data module 206, and a statistics module 208. The thread detection module 204 may be configured to instruct the kernel 210, such as via a kernel interface module 214 (e.g., Berkeley Packet Filter (BPF), eBPF), to monitor the execution of tasks for events by threads of programs executed on the processor, and use these events to calculate the time of execution of the tasks and the total time cost of execution of the threads. The thread detection module 204 may further instruct the kernel interface module 214 to provide the total time cost of execution of the threads and the thread identifiers of the threads to the core thread identifier program 202.
[0033] The perf event data module 206 may receive the total time cost of the execution of the thread and the thread identifier of the thread from the kernel interface module 214. The perf event data module 206 may store the total time cost of the execution of the corresponding thread and the thread identifier of the thread in association with each other. For example, the total time cost of the execution of the thread and the thread identifier of the thread may be stored in association with each other in a memory (e.g., Figure 1 The perf event data module 206 may store the total time cost of execution of the corresponding thread and the thread identifier of the thread in association with each other in any of various free-form data formats, data structures, databases, etc.
[0034] The statistics module 208 may be configured to analyze the stored total time cost of execution of the threads and the thread identifiers of the threads. Such analysis may include identifying one or more of the threads as core threads of a program executed on the processor. The statistics module 208 may identify threads whose total time cost of execution of the threads is greater than other threads. The statistics module 208 may generate representations of the total time cost of execution of the threads and compare these representations. For example, the representation of the total time cost of execution of the threads may be weighted based on the total time cost of execution of the threads relative to a value such as an aggregate threshold time. As a more specific example, the representation of the total time cost of execution of the threads may be a value divided by the total time cost of execution of the threads.
[0035] The statistics module 208 may store the corresponding representation of the total time cost of execution of the thread and the thread identifier of the thread in association with each other. For example, the representation of the total time cost of execution of the thread and the thread identifier of the thread may be stored in association with each other in a memory (e.g., Figure 1 The statistics module 208 may store the corresponding representation of the total time cost of execution of the thread and the thread identifier of the thread in association with each other in any of various free-form data formats, data structures, databases, etc.
[0036] The statistics module 208 may compare the representations of the total time cost of the execution of the threads to determine the thread with the larger total time cost of the execution of the threads. For example, the representations of the total time cost of the execution of a certain number of threads with the maximum value with respect to the remaining representations may be compared with each other. In some examples, the representations of the total time cost of the execution of the threads may be sorted, such as in ascending and / or descending order, and a certain number of representations may come from the corresponding ends of the sorted representations. In order to compare the representations of the total time cost of the execution of a certain number of threads, the maximum value representation may be compared with each of the other representations in the certain number of representations. The result of the comparison within one or more ranges of the core thread value or the core thread threshold value may be used to identify the representation of the total time cost of the execution of the thread as the representation of the core thread. The maximum value representation of the total time cost of the execution of the thread may also be identified as the representation of the core thread. The statistics module 208 may identify the thread identifier associated with the representation of the core thread as the thread identifier of the core thread.
[0037] The kernel 210 may include a verifier module 212, a kernel interface module 214, and one or more of a Kprobes module 220, an Uprobes module 222, a tracepoint module 224, and a perf event module 226. The verifier module 212 may be configured to verify the code instructions provided to the kernel 210 by the thread detection module 204 by known means, and provide the verified code instructions to the kernel interface module 214.
[0038] The kernel interface module 214 may implement code instructions to monitor the execution of tasks for events by threads of programs executed on the processor. For example, the kernel interface module 214 may implement code instructions to implement mounting events and record task-related data in response to event mounting. The kernel interface module 214 may implement the Kprobes module 220 to mount kernel functions, implement the Uprobes module 222 to mount user functions, and / or implement the tracking point module 224 to mount predetermined tracking points. For example, the kernel interface module 214 may implement the tracking point module 224 to mount sched_switch events to monitor when the processor changes state between running and not running tasks.
[0039] The kernel interface module 214 may implement code instructions to record a timestamp for a sched_switch event and / or calculate a duration between sched_switch events (such as between running and not running a task) to represent the duration of task execution. The kernel interface module 214 may implement code instructions to calculate a total time cost of execution of a thread and identify a thread identifier of the thread. The kernel interface module 214 may implement code instructions to return the total time cost of execution of the thread and the thread identifier of the thread to the core thread identifier program 202. For example, the kernel interface module 214 may implement the perf event module 226 to implement returning the total time cost of execution of the thread and the thread identifier of the thread to the core thread identifier program 202.
[0040] Figure 3 An example of the progression of execution states of a processor executing a thread for implementing various embodiments is shown. Figures 1 to 3 , a processor (e.g., Figure 1 The CPU 104, processor 124 in the embodiment of the present invention can be changed to various execution states during the duration of the execution of the thread. For example, when there is no task of the thread ready to execute, the processor can be in a sleep state 302a, 302b, 302c, 302d, an uninterruptible sleep state 308, and / or an uninterruptible sleep state that blocks I / O 310. When the task of the thread is ready to execute, the processor can be in an executable state 304a, 304b, 304c, 304d, 304e. When the task of the thread is being executed by the processor, the processor can be in a running state 306a, 306b, 306c, 306d, 306e.
[0041] Switching the execution state of the processor into and out of the running state 306a, 306b, 306c, 306d, 306e may trigger a sched_switch event, which may be triggered by the kernel (e.g., Figure 2 The kernel 220, kernel interface module, interface module 214, and trace point module 224 in the kernel 220 are mounted. The kernel can monitor the sched_switch event and use the sched_switch event to record data for calculating the duration of each task execution. The kernel can aggregate the duration of each task execution to calculate the total time cost of the execution of thread 300.
[0042] Figure 4 A method 400 for detecting program core threads according to various embodiments is illustrated. Figures 1 to 4 The method 400 may be implemented in a computing device (e.g., computing device 100), in hardware, in software executed in a processor, or in a combination of a software-configured processor and dedicated hardware (e.g., Figure 1 The CPU 104, the processor 124, Figure 2 210, a verifier module 212, a kernel interface module 214, a Kprobes module 220, an Uprobes module 222, a tracepoint module 224, and a perf event module 226), which are implemented in combination with the dedicated hardware including other separate components such as various memories / caches (e.g., Figure 1 In order to cover alternative configurations implemented in various embodiments, the hardware implementing method 400 is referred to herein as a "processing device".
[0043] In block 402, a processing device may mount an event. In response to receiving a request from a core thread identifier program (e.g., Figure 2 The processing device may implement the instructions to mount events during the execution of the program. For example, the event may be a sched switch event to monitor the processor executing the program (e.g., Figure 1 The processing device of the event in the mounting frame 402 can be a processor (e.g., a CPU 104, a processor 124) state switching, such as switching to and from the running state of the processor when starting and ending the task of executing the program. Figure 1 CPU 104, processor 124), core (e.g., Figure 2 210 in the kernel), kernel interface modules (e.g., Figure 2 Kernel interface module 214 in, Kprobes module (e.g., Figure 2 Kprobes module 220 in, Uprobes module 222 (e.g., Figure 2 Uprobes module 222 in ) and / or tracking point module (e.g., Figure 2 Tracking point module 224 in.
[0044] In block 404, the processing device may determine whether the processor executing the program is in a running state. The mounting of the event may enable the processing device to monitor the state change of the processor. The processing device may identify the state of the processor, particularly when the processor is in a running state of the task executing the program. The processing device may identify the state of the processor by known means, and determine whether the processor is in a running state based on the identified state of the processor. In some embodiments, the processing device that determines whether the processor executing the program is in a running state in determination block 404 may be a processor, a kernel, and / or a kernel interface module.
[0045] In response to determining that the processor executing the program is in a running state (i.e., determination block 404 = "Yes"), the processing device may record a start timestamp in optional block 406. For the first task execution by a thread of the program during a particular duration (such as a duration corresponding to an aggregation threshold (described further herein)), the processing device may record a timestamp when the task execution started. The start timestamp may be recorded in a memory (e.g., Figure 1 In some embodiments, the processing device may implement recording a start timestamp a specified number of times (such as once) per specific duration in optional block 406. Whether the processing device has implemented recording a start timestamp for a specific duration in optional block 406 may be indicated by setting a start timestamp flag such as a register or buffer value. In some embodiments, the processing device that records the start timestamp in optional block 406 may be a processor, a kernel, and / or a kernel interface module.
[0046] In block 408, the processing device may calculate the aggregate task runtime. The processing device may calculate the duration of each task executed by the processor during a specific duration based on the mounting of the event. For example, the processing device may use the timestamp of the event and calculate the difference between the timestamps to calculate the duration of the task execution. As another example, the processing device may control a timer based on the event and use the duration measured by the timer to calculate the duration of the task execution. The processing device may aggregate the duration of each task executed by the processor during a specific duration to calculate the aggregate task runtime. In some embodiments, the processing device that calculates the aggregate task runtime in block 408 may be a processor, a kernel, and / or a kernel interface module.
[0047] In determination block 410, the processing device may determine whether the aggregate task runtime exceeds an aggregate threshold. The aggregate threshold may be a predetermined value, such as a value of the duration of the duration for which the aggregate processor executes each task. For example, the aggregate threshold may be between about 100 ms and about 1000 ms, such as about 500 ms. The processing device may compare the aggregate task runtime with the aggregate threshold. Based on the comparison result, the processing device may determine whether the aggregate task runtime exceeds the aggregate threshold. In some embodiments, the processing device that determines in determination block 410 whether the aggregate task runtime exceeds the aggregate threshold may be a processor, a kernel, and / or a kernel interface module.
[0048] In response to determining that the aggregate task runtime exceeds the aggregate threshold (i.e., determination block 410 = "yes"), the processing device may record an end timestamp in block 412. For the last task execution of a thread of a program during a particular duration (such as a duration corresponding to the aggregate threshold), the processing device may record a timestamp when the task execution completed. The end timestamp may be recorded in a memory (e.g., Figure 1 In some embodiments, the processing device that records the end timestamp in block 412 may be a processor, a kernel, and / or a kernel interface module.
[0049] In block 414, the processing device may calculate the total time cost for the execution of the thread. The processing device may use the recorded start timestamp and end timestamp to determine the total time cost for the execution of the thread. For example, the processing device may calculate the difference between the end timestamp and the start timestamp as the total time cost for the execution of the thread. In some embodiments, the processing device that calculates the total time cost for the execution of the thread in block 414 may be a processor, a kernel, and / or a kernel interface module.
[0050] In block 416, the processing device may return the total time cost for the execution of the thread and the thread identifier of the thread to the thread identifier program. The processing device may retrieve the thread identifier of the thread of the program executed by the processing device by known means. The processing device may implement a callback function for instructions received from a core thread identifier program (such as perf_output) to provide the total time cost for the execution of the thread and the thread identifier of the thread to the thread identifier program. In some embodiments, the processing device that returns the total time cost for the execution of the thread and the thread identifier of the thread to the thread identifier program in block 416 may be a processor, a kernel, a kernel interface module, and / or a perf event module (e.g., Figure 2 perf event module 226 in.
[0051] In response to determining that the processor executing the program is not in a running state (i.e., determination box 404 = "No"), or in response to determining that the aggregate task runtime does not exceed the aggregate threshold (i.e., determination box 410 = "Yes"), the processing device may continuously, repeatedly and / or periodically mount events in box 402.
[0052] Figure 5 A method 500 for detecting program core threads according to an embodiment is illustrated. Figures 1 to 5 , method 500 may be implemented in a computing device (e.g., computing device 100), in hardware, in software executed in a processor, or in a combination of a software-configured processor and dedicated hardware (e.g., Figure 1 The CPU 104, the processor 124, Figure 2204, a perf event data module 206, and a statistics module 208), which are implemented in combination with the core thread identifier program 202, the thread detection module 204, the perf event data module 206, and the statistics module 208 in the dedicated hardware, and the dedicated hardware includes other separate components, such as various memories / caches (e.g., Figure 1 In order to cover alternative configurations implemented in various embodiments, the hardware implementing method 500 is referred to herein as a "processing device".
[0053] In block 502, a processing device may execute a command from a kernel (e.g., Figure 2 The processing device may receive from the kernel the total time cost of the execution of the thread and the thread identifier of the thread returned by the processing device in block 416 of method 400 as described. In some embodiments, the processing device that receives the total time cost of the thread and the thread identifier of the thread from the kernel in block 502 may be a processor (e.g., Figure 1 CPU 104, processor 124), core thread identifier program (e.g., Figure 2 202) and / or a perf event data module (e.g., Figure 2 perf event data module 206 in.
[0054] In block 504, the processing device may calculate a representation of the total time cost for the execution of the thread. The processing device may generate the representation of the total time cost for the execution of the thread by algorithmic means. For example, the representation of the total time cost for the execution of the thread may be weighted based on the total time cost for the execution of the thread relative to a value such as an aggregate threshold time. For a more specific example, the representation of the total time cost for the execution of the thread may be a value divided by the total time cost for the execution of the thread. In some embodiments, the processing device that calculates the representation of the total time cost for the execution of the thread in block 504 may be a processor, a core thread identifier program, and / or a statistics module (e.g., Figure 2 Statistics module 208 in ).
[0055] In block 506, the processing device may store the representation of the total time cost for the execution of the thread and the thread identifier of the thread in association with each other. The processing device may store the corresponding representation of the total time cost for the execution of the thread and the thread identifier of the thread in association with each other. For example, the representation of the total time cost for the execution of the thread and the thread identifier of the thread may be stored in association with each other in a memory (e.g., Figure 1The processing device may store the corresponding representation of the total time cost for the execution of the thread and the thread identifier of the thread in association with each other in any of various free-form data formats, data structures, databases, etc. In some embodiments, the processing device that stores the representation of the total time cost for the execution of the thread and the thread identifier of the thread in association with each other in block 506 may be a processor, a core thread identifier program, and / or a statistics module.
[0056] In block 508, the processing device may start a timer. The timer may be configured to measure a duration, such as time, and may be used to determine an elapsed duration. The timer may be a timer configured for a specific duration and / or a timer that is not configured for a specific duration. The processing device may track the progress of the timer. In some embodiments, the processing device that starts the timer in block 508 may be a processor, a core thread identifier program, and / or a statistics module.
[0057] In determination block 510, the processing device may determine whether the timer has expired. For example, the timer may expire when a set duration is completed and may trigger a signal that the timer has expired, which may be received by the processing device. As another example, the processing device may compare the timer to a timer threshold and determine whether the timer has expired based on the comparison. In some embodiments, the processing device that determines whether the timer has expired in determination block 510 may be a processor, a core thread identifier program, and / or a statistics module.
[0058] In response to determining that the timer has expired (i.e., determination block 510 = "Yes"), the processing device may sort the representation of the total time cost of execution of the thread in block 512. For example, the representation of the total time cost of execution of the thread may be sorted, such as in ascending and / or descending order. In some embodiments, the processing device that sorts the representation of the total time cost of execution of the thread in block 512 may be a processor, a core thread identifier program, and / or a statistics module.
[0059] In box 514, the processing device may compare the representations of the total time cost of the execution of the threads. The processing device may compare the representations of the total time cost of the execution of the threads with each other to determine the thread with the total time cost of the execution of the larger thread. For example, the representations of the total time cost of the execution of a certain number of threads with the maximum value for the remaining representation may be compared with each other. In some examples, the representations of the certain number may come from a portion of the sorted representation, such as one end, and the portion of the sorted representation corresponds to the maximum value of the representation of the total time cost of the execution of the threads. In order to compare the representations of the total time cost of the execution of a certain number of threads, the maximum value representation may be compared with each of the other representations in the certain number of representations. For example, the processing device may divide each of the other representations in the representation of the total time cost of the execution of a certain number of threads by the maximum value representation. In some embodiments, the processing device that compares the representations of the total time cost of the execution of the threads in box 514 may be a processor, a core thread identifier program, and / or a statistical module.
[0060] In box 516, the processing device may identify one or more core threads of the program executed by the processor. The result of the comparison can be used to determine whether the thread is a core thread. For example, the comparison result can be compared with one or more patterns of the comparison results of the combination of one or more core threads. The result of the comparison within one or more ranges of the core thread value or the core thread threshold can be used to identify the representation of the total time cost of the execution of the thread as the representation of the core thread. For example, the comparison result within multiple ranges of the core thread value or the core thread threshold can identify the corresponding representation of the total time cost of the execution of the thread as the representation of the core thread. The maximum value representation of the total time cost of the execution of the thread can also be identified as the representation of the core thread. The processing device can identify the thread identifier associated with the representation of the core thread as the thread identifier of the core thread. In some embodiments, the processing device that identifies one or more core threads of the program executed by the processor in box 516 can be a processor, a core thread identifier program and / or a statistical module.
[0061] According to various embodiments (including but not limited to the above reference Figure 1 9) can be implemented in a variety of computing systems including mobile computing devices, examples of which are suitable for use with various embodiments are in Figure 66. The mobile computing device 600 may include a processor 602 coupled to a touch screen controller 604 and an internal memory 606. The processor 602 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 606 may be volatile or non-volatile memory, and may also be secure and / or encrypted memory, or unsecure and / or unencrypted memory, or any combination thereof. Examples of memory types that may be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touch screen controller 604 and the processor 602 may also be coupled to a touch screen panel 612, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, and the like. Additionally, the display of the mobile computing device 600 need not have touch screen capabilities.
[0062] The mobile computing device 600 may have one or more radio signal transceivers 608 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radios) coupled to each other and / or to the processor 602 and an antenna 610 for transmitting and receiving communications. The transceiver 608 and antenna 610 may be used with the circuits mentioned above to implement various wireless transmission protocol stacks and interfaces. The mobile computing device 600 may include a cellular network wireless modem chip 616 that enables communication via a cellular network and is coupled to the processor.
[0063] The mobile computing device 600 may include a peripheral device connection interface 618 coupled to the processor 602. The peripheral device connection interface 618 may be configured solely to accept one type of connection, or may be configured to accept various types of physical and communication connections that are shared or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 618 may also be coupled to a similarly configured peripheral device connection port (not shown).
[0064] The mobile computing device 600 may also include a speaker 614 for providing audio output. The mobile computing device 600 may also include a housing 620 for housing all or some of the components described herein, the housing being constructed of plastic, metal, or a combination of materials. The mobile computing device 600 may include a power source 622 coupled to the processor 602, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive a charging current from a source external to the mobile computing device 600. The mobile computing device 600 may also include a physical button 624 for receiving user input. The mobile computing device 600 may also include a power button 624 for turning the mobile computing device 600 on and off.
[0065] According to various embodiments (including but not limited to the above reference Figure 1 9) can be implemented in a variety of computing systems including a laptop computer 700, an example of which is shown in FIG. Figure 7 . Many laptop computers include a touchpad touch surface 717 that serves as a pointing device for the computer and can therefore receive drag, scroll, and tap gestures similar to those implemented on computing devices equipped with a touch screen display and as described above. Laptop computer 700 will typically include a processor 702 coupled to volatile memory 712 and a disk drive 713 of a large capacity non-volatile memory such as flash memory. Additionally, computer 700 may have one or more antennas 708 for transmitting and receiving electromagnetic radiation, connectable to a wireless data link, and / or a cellular telephone transceiver 716 coupled to processor 702. Computer 700 may also include a floppy disk drive 714 and a compact disk (CD) drive 715 coupled to processor 702. In a notebook configuration, the computer housing includes a touchpad 717, a keyboard 718, and a display 719, all coupled to processor 702. Other configurations of computing devices may include a computer mouse or trackball coupled to a processor (e.g., via a USB input) as is well known, which may also be used in conjunction with various embodiments.
[0066] According to various embodiments (including but not limited to the above reference Figures 1 to 5 The system of the described embodiments may also be implemented in a fixed computing system, such as any of a variety of commercially available servers. Figure 8 An example server 800 is illustrated in FIG. Such a server 800 typically includes one or more multi-core processor assemblies 801 coupled to a volatile memory 802 and a large capacity non-volatile memory (such as a disk drive 804). Figure 8As shown, a multi-core processor assembly 801 can be added to a server 800 by inserting it into a chassis of the assembly. The server 800 may also include a floppy disk drive, a compact disk (CD), or a digital versatile disk (DVD) disk drive 806 coupled to the processor 801. The server 800 may also include a network access port 803 coupled to the multi-core processor assembly 801 for establishing a network interface connection with a network 805, such as a local area network coupled to other broadcast system computers and servers, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, 5G, or any other type of cellular data network).
[0067] Specific implementation examples are described in the following paragraphs. Although some of the following specific implementation examples are described in terms of example methods, other example implementations may include: the example methods discussed in the following paragraphs implemented by a computing device, the computing device including a processing device configured with processing device executable instructions for performing the operations of the example methods; the example methods discussed in the following paragraphs implemented by a computing device, the computing device including components for performing the functions of the example methods; and the example methods discussed in the following paragraphs implemented as a non-transitory processor-readable storage medium having processor executable instructions stored thereon, the processor executable instructions being configured to cause a processor of the computing device to perform the operations of the example methods.
[0068] Embodiment 1. Embodiment 1. A method for identifying a core thread of a program executed by a processor, comprising: mounting an event by a kernel interface; calculating a total time cost of a thread for executing the program based on mounting the event by the kernel interface; returning the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program by the kernel of the processor; and determining the core thread of the program by the core thread identifier program based on the total time cost for executing the thread and the thread identifier of the thread.
[0069] Embodiment 2. The method according to embodiment 1 further includes: calculating the duration of at least one task of the thread based on mounting the event.
[0070] Embodiment 3. The method of embodiment 2, wherein the event comprises a switch-in to a running processor execution state for the processor and a switch-out of the running processor execution state.
[0071] Embodiment 4. The method according to any one of embodiments 1-3 further includes: calculating the aggregate duration of at least one task used to execute the thread based on mounting the event; and determining whether the aggregate duration of at least one task used to execute the thread exceeds an aggregate threshold, wherein calculating the total time cost of the thread used to execute the program based on mounting the event includes: calculating the total time cost of the thread used to execute the program in response to determining that the aggregate duration of at least one task used to execute the thread exceeds the aggregate threshold.
[0072] Embodiment 5. The method according to any one of embodiments 1-4 further includes: calculating a representation of the total time cost for executing the thread.
[0073] Embodiment 6. The method according to embodiment 5 further includes: comparing the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread, wherein determining the core thread of the program includes: comparing the result of the comparison of the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread with at least one range of values, within the at least one range, the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing the thread is a core thread.
[0074] Computer program code or "program code" for execution on a programmable processor to perform the operations of the various embodiments may be written in a high-level programming language (such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic), a structured query language (e.g., Transact-SQL), Perl, or in a variety of other programming languages. Program code or program stored on a computer-readable storage medium as used in this application may refer to machine language code (such as object code) in a format that can be understood by a processor.
[0075] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter", "then", "next", etc. are not intended to limit the order of operations; these words are only used to guide the reader to read the description of the method. In addition, any reference to a claim element in the singular form (e.g., a reference using the article "one", "an", or "said") should not be interpreted as limiting the element to the singular.
[0076] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with the various embodiments may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Although a technician may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as departing from the scope of the claims.
[0077] The hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination thereof designed to perform the functions described herein. Although a general purpose processor may be a microprocessor, in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.
[0078] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, each function may be stored as one or more instructions or codes on a non-transient computer-readable medium or a non-transient processor-readable medium. The operation of the method or algorithm disclosed herein may be implemented in a processor-executable software module, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination is also included in the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.
[0079] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.
Claims
1. A method for identifying a core thread of a program executed by a processor, the method comprising: Events are mounted by the kernel interface; Calculating a total time cost of a thread for executing the program based on mounting the event by the kernel interface; returning, by a core of the processor, the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program; as well as A core thread of the program is determined by the core thread identifier program based on the total time cost for executing the thread and the thread identifier of the thread.
2. The method according to claim 1, further comprising: The duration of at least one task of the thread is calculated based on mounting the event. 3 . The method of claim 2 , wherein the event comprises a switch-in to a running processor execution state for the processor and a switch-out of the running processor execution state.
4. The method according to claim 1, further comprising: calculating an aggregate duration of at least one task for executing the thread based on mounting the event; as well as determining whether the aggregate duration for executing the at least one task of the thread exceeds an aggregate threshold, Wherein calculating the total time cost of the thread for executing the program based on mounting the event includes: calculating the total time cost of the thread for executing the program in response to determining that the aggregate duration of the at least one task for executing the thread exceeds the aggregate threshold.
5. The method according to claim 1, further comprising: A representation of the total time cost for executing the thread is calculated.
6. The method according to claim 5, further comprising: comparing the representation of the total time cost for executing the thread to at least one other representation of the total time cost for executing a thread, Wherein determining the core thread of the program comprises comparing a result of comparing the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread with at least one range of values, wherein within the at least one range, the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing the thread is a core thread.
7. A computing device, comprising: Memory; and a processor coupled to the memory and configured to: Mounting an event in a program executed in the processor by a kernel interface; Calculating a total time cost of a thread for executing the program based on mounting the event by the kernel interface; returning, by a core of the processor, the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program; as well as A core thread of the program is determined by the core thread identifier program based on the total time cost for executing the thread and the thread identifier of the thread. 8 . The computing device method of claim 7 , wherein the processor is further configured to calculate a duration of at least one task of the thread based on mounting the event.
9. The computing device of claim 8, wherein the event comprises a switch-in to a running processor execution state for the processor and a switch-out of the running processor execution state.
10. The computing device of claim 7, wherein the processor is further configured to: calculating an aggregate duration of at least one task for executing the thread based on mounting the event; and determining whether the aggregate duration for executing the at least one task of the thread exceeds an aggregate threshold, Wherein the processor is further configured to calculate the total time cost for executing the thread of the program in response to determining that the aggregate duration for executing the at least one task of the thread exceeds the aggregate threshold.
11. The computing device of claim 7, wherein the processor is further configured to compute a representation of the total time cost for executing the thread.
12. The computing device of claim 11, wherein the processor is further configured to: comparing the representation of the total time cost for executing the thread to at least one other representation of the total time cost for executing a thread, The processor is further configured to determine the core thread of the program by comparing a result of the comparison of the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread with at least one range of values, wherein within the at least one range, the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing the thread is a core thread.
13. A computing device, the computing device comprising: means for mounting an event by a kernel interface of a program executing in said computing device; means for calculating a total time cost for executing a thread of the program based on mounting the event by the kernel interface; means for returning, by a core of the processor, the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program; and Means for determining, by the core thread identifier program, a core thread of the program based on the total time cost for executing the thread and the thread identifier of the thread.
14. The computing device of claim 13, further comprising: Means for calculating a duration of at least one task of the thread based on mounting the event.
15. The computing device of claim 14, wherein the event comprises a switch-in to a running processor execution state for the processor and a switch-out of the running processor execution state.
16. The computing device of claim 13, further comprising: means for calculating an aggregate duration of at least one task for executing the thread based on mounting the event; and means for determining whether the aggregate duration for executing the at least one task of the thread exceeds an aggregate threshold, The component for calculating the total time cost of the thread for executing the program based on mounting the event includes: a component for calculating the total time cost of the thread for executing the program in response to determining that the aggregate duration of the at least one task for executing the thread exceeds the aggregate threshold.
17. The computing device of claim 13, further comprising: Means for computing a representation of the total time cost for executing the thread.
18. The computing device of claim 17, further comprising: means for comparing the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread, Wherein the means for determining the core thread of the program comprises means for comparing a result of the comparison of the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread with at least one range of values, wherein within the at least one range, the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing the thread is a core thread.
19. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor to perform operations for identifying a core thread of a program executed by the processor, the operations comprising: Events are mounted by the kernel interface; Calculating a total time cost of a thread for executing the program based on mounting the event by the kernel interface; returning, by a core of the processor, the total time cost for executing the thread and a thread identifier of the thread to a core thread identifier program; as well as A core thread of the program is determined by the core thread identifier program based on the total time cost for executing the thread and the thread identifier of the thread.
20. The non-transitory processor-readable medium of claim 19, wherein the stored processor-executable instructions are configured to cause the processor to perform operations further comprising: The duration of at least one task of the thread is calculated based on mounting the event.
21. The non-transitory processor-readable medium of claim 20, wherein the event comprises a switch-in to a running processor execution state for the processor and a switch-out of the running processor execution state.
22. The non-transitory processor-readable medium of claim 19, wherein the stored processor-executable instructions are configured to cause the processor to perform operations further comprising: calculating an aggregate duration of at least one task for executing the thread based on mounting the event; as well as determining whether the aggregate duration for executing the at least one task of the thread exceeds an aggregate threshold, The stored processor-executable instructions are configured to calculate the total time cost of the thread for executing the program based on mounting the event, including: calculating the total time cost of the thread for executing the program in response to determining that the aggregate duration of at least one task for executing the thread exceeds the aggregate threshold.
23. The non-transitory processor-readable medium of claim 19, wherein the stored processor-executable instructions are configured to cause the processor to perform operations further comprising: A representation of the total time cost for executing the thread is calculated.
24. The non-transitory processor-readable medium of claim 23, wherein the stored processor-executable instructions are configured to cause the processor to perform operations further comprising: comparing the representation of the total time cost for executing the thread to at least one other representation of the total time cost for executing a thread, The stored processor-executable instructions are configured such that determining the core thread of the program includes comparing a result of comparing the representation of the total time cost for executing the thread with at least one other representation of the total time cost for executing the thread with at least one range of values, wherein within the at least one range, the result of the comparison indicates that the corresponding thread of the representation of the total time cost for executing the thread is a core thread.