Performance monitoring method and apparatus, and processor

Abstract

A performance monitoring method and apparatus, and a processor, relating to the technical field of computers. A first counting module is configured to count the number of occurrences of a first event when a processor executes a target program, a second counting module is configured to count the number of occurrences of a second event when the processor executes the target program, and the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used for representing a performance index of the target program. When the first counting module and the second counting module start counting, whether the first counting module and the second counting module overflow is detected. When it is determined that the first counting module overflows, the processor is triggered to be interrupted. When it is determined that the first counting module does not overflow and the second counting module overflows, the first counting module and the second counting module are triggered to re-start counting. In the present application, on the basis of the performance index, the processor is triggered to be interrupted, so that a hotspot code determined on the basis of the interruption is more likely to be a code segment having a poor performance index, and has high optimization potential.

Description

Performance monitoring methods and devices, processors

[0001] This application claims priority to Chinese patent application No. 202410708190.6, filed on May 31, 2024, entitled “Performance Monitoring Method and Apparatus, Processor”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a performance monitoring method and apparatus, and a processor. Background Technology

[0003] Hotspots are code segments in a program that consume a significant amount of processor resources. Optimizing these hotspots can improve a program's performance. This requires identifying (or determining) these hotspots.

[0004] Currently, single-event sampling is commonly used to identify hotspot code in a program. Specifically, the processor's performance monitoring unit (PMU) includes a counter. The operating system (OS) running on the processor determines performance events based on user commands and configures the counter to count the occurrences of these performance events. During program execution, the counter counts the occurrences of each performance event (i.e., the number of times the processor encounters the event). When the counter overflows (e.g., when it reaches a preset count), an interrupt is triggered. The OS generates a sampling record based on the interrupt context. The OS determines the code segment being executed at the time of the interrupt based on this sampling record; for example, the code segment determined from the sampling record is called the code segment corresponding to that sampling record. The OS identifies hotspot code in the program based on the code segments corresponding to multiple sampling records generated during program execution.

[0005] Generally, code snippets with good performance metrics have little or no optimization potential, while code snippets with poor performance metrics have greater optimization potential. Therefore, when optimizing a program, it's usually only necessary to focus on the code snippets with poor performance metrics. However, hotspot code identified using single-event sampling might be code snippets with good performance metrics, making optimization of these hotspot codes less effective. Summary of the Invention

[0006] This application provides a performance monitoring method, apparatus, and processor. The technical solution of this application is as follows.

[0007] Firstly, a performance monitoring method is provided. This method includes: monitoring whether the first and second counting modules overflow after they begin counting; wherein the first counting module counts the number of occurrences of a first event during the execution of the target program by the processor, and the second counting module counts the number of occurrences of a second event during the execution of the target program by the processor; the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program; when it is determined that the first counting module has overflowed, an interrupt is triggered in the processor; when it is determined that the first counting module has not overflowed but the second counting module has overflowed, the first and second counting modules are triggered to restart counting (i.e., without triggering an interrupt in the processor, the first and second counting modules are triggered to restart counting). After triggering an interrupt in the processor, hotspot code in the target program can be determined based on the interrupt.

[0008] The technical solution provided in this application involves a first counting module that counts the occurrence of a first event during the execution of the target program by the processor, and a second counting module that counts the occurrence of a second event during the same process. The ratio of the occurrences of the first event to the second event is used to characterize the performance index of the target program. When the first counting module overflows, an interrupt is triggered in the processor. If neither the first nor the second counting module overflows, no interrupt is triggered, and both the first and second counting modules restart counting. Therefore, the probability that the code segment being executed by the processor at the time of the interrupt is a code segment with poor performance is high. The probability that the hot code identified based on the interrupt is a code segment with poor performance is high, and the identified hot code has greater optimization potential, which helps improve the optimization effect of the hot code. Not triggering an interrupt when neither the first nor the second counting module overflows avoids the possibility of identifying code segments with good performance as hot code when the first counting module has not overflowed. Triggering a restart of counting when both the first and second counting modules overflow facilitates the start of a new round of counting.

[0009] Optionally, the first counting module overflows when the count reaches the first count, and the second counting module overflows when the count reaches the second count, with the ratio of the first count to the second count not less than a preset ratio. The first count can be referred to as the overflow threshold for the first counting module to count the occurrence of the first event, and the second count can be referred to as the overflow threshold for the second counting module to count the occurrence of the second event.

[0010] The technical solution provided in this application ensures that, since the ratio of the overflow line of the first counting module counting the occurrence of the first event to the overflow line of the second counting module counting the occurrence of the second event is not less than a preset ratio, when the first counting module overflows, the ratio of the occurrence of the first event counted by the first counting module to the occurrence of the second event counted by the second counting module is not less than the preset ratio. Furthermore, since the ratio of the occurrence of the first event to the occurrence of the second event is used to characterize the performance index of the target program, when the first counting module overflows, the probability that the code segment being executed by the processor is a code segment with poor performance is relatively high, and the optimization potential of the code segment being executed by the processor is relatively high. When the first counting module overflows, the processor experiences an interrupt, making it more likely that the hot code determined based on the interrupt is a code segment with poor performance, and the optimization potential of the hot code determined based on the interrupt is relatively high, which helps to improve the optimization effect of the hot code.

[0011] Optionally, the first counting module is used to count the number of occurrences of the first event by counting backwards, and the second counting module is used to count the number of occurrences of the second event by counting backwards. The method further includes: before the first counting module starts counting, initializing the count of the first counting module to the first count; and before the second counting module starts counting, initializing the count of the second counting module to the second count.

[0012] The technical solution provided in this application initializes the count of the first counting module to a first count before the first counting module starts counting. This allows the first counting module to count the occurrence of the first event by counting backwards and overflows when the count reaches the first count. Similarly, before the second counting module starts counting, it initializes the count of the second counting module to a second count. This allows the second counting module to count the occurrence of the second event by counting backwards and overflows when the count reaches the second count.

[0013] Optionally, after a processor interrupt occurs, the first and second counting modules are triggered to restart counting. For example, the first counting module is used to count the occurrences of the first event by counting down, and the second counting module is used to count the occurrences of the second event by counting down. After a processor interrupt occurs, the method further includes: resetting the count of the first counting module to the first count; resetting the count of the second counting module to the second count; and triggering the first and second counting modules to restart counting. That is, after a processor interrupt occurs, the first and second counting modules restart a new round of counting by counting down.

[0014] The technical solution provided in this application allows the first and second counting modules to restart a new round of counting by counting backwards after the processor is interrupted, so that the processor can be triggered to interrupt again when the first counting module overflows again.

[0015] Optionally, initializing the count of the first counting module to the first count includes: loading the first count from the first storage module into the first counting module, wherein the first storage module is used to store the first count; initializing the count of the second counting module to the second count includes: loading the second count from the second storage module into the second counting module, wherein the second storage module is used to store the second count.

[0016] Optionally, resetting the count of the first counting module to the first count includes: reloading the first count from the first storage module to the first counting module, wherein the first storage module is used to store the first count; resetting the count of the second counting module to the second count includes: reloading the second count from the second storage module to the second counting module, wherein the second storage module is used to store the second count.

[0017] Optionally, the method further includes: receiving an operation command from a user, the operation command carrying a first count and a second count; storing the first count in a first storage module according to the operation command; and storing the second count in a second storage module according to the operation command.

[0018] The technical solution provided in this application stores the first count to the first storage module and the second count to the second storage module according to the user's operation command. This facilitates the initialization and reset of the count of the first counting module by loading the first count from the first storage module, and also facilitates the initialization and reset of the count of the second counting module by loading the second count from the second storage module.

[0019] Optionally, the processor's performance monitoring unit (PMU) includes a control module, a first storage module, and a second storage module. Storing the first data into the first storage module includes: storing the first data into the first storage module through the control module; storing the second data into the second storage module includes: storing the second data into the second storage module through the control module.

[0020] In this application, at least one of the first storage module and the second storage module can be implemented based on software, hardware, or a combination of software and hardware. Optionally, the first storage module and the second storage module include registers. For example, both the first storage module and the second storage module are registers.

[0021] Optionally, the first counting module is used to count the number of times the first event occurs by counting backwards, and the second counting module is used to count the number of times the second event occurs by counting backwards; before the first counting module restarts counting, the count of the first counting module is reset to the first count; before the second counting module restarts counting, the count of the second counting module is reset to the second count.

[0022] The technical solution provided in this application resets the count of the first counting module to the initial count before the first counting module restarts counting. This allows the first counting module to count the occurrence of the first event by counting backwards and overflows when the count reaches the initial count. Similarly, resetting the count of the second counting module to the initial count before the second counting module restarts counting allows the second counting module to count the occurrence of the second event by counting backwards and overflows when the count reaches the initial count.

[0023] Optionally, before the first and second counting modules begin counting, the method further includes: configuring the function of the first counting module to count the occurrence of a first event; and configuring the function of the second counting module to count the occurrence of a second event. For example, the function of the first counting module is configured to count the occurrence of the first event, and the function of the second counting module is configured to count the occurrence of the second event, based on the user's operation command.

[0024] In this application, at least one of the first counting module and the second counting module is implemented based on software, hardware, or a combination of software and hardware. Optionally, the first counting module and the second counting module are located in the processor's PMU, and the first counting module and the second counting module include registers.

[0025] Optionally, after triggering an interrupt in the processor, the method further includes: obtaining a sampling record based on the context of the interrupt, the sampling record being used to record information about the code segment being executed by the processor when the interrupt was generated, the code segment being a code segment in the target program; and determining hotspot code in the target program based on the sampling record.

[0026] The technical solution provided in this application involves a first counting module that counts the occurrence of a first event during the execution of the target program by the processor, and a second counting module that counts the occurrence of a second event during the execution of the target program by the processor. The ratio of the occurrences of the first event to the occurrences of the second event is used to characterize the performance index of the target program. When the first counting module overflows, the processor experiences an interrupt. If neither the first nor the second counting module overflows, the processor does not experience an interrupt, and both the first and second counting modules restart counting. After the processor experiences this interrupt, sampling records are obtained based on the context of the interrupt, and hotspot code in the target program is determined based on these sampling records. This increases the probability that the determined hotspot code is a code segment with poor performance, and thus increases the optimization potential of the determined hotspot code.

[0027] Optionally, the second event includes an instruction retire event. The first event includes any of the following: a clock cycle event; a lookup cache miss event; a branch prediction miss event; a lookup instruction cache (i-cache) miss event; a lookup data cache (d-cache) miss event; a lookup translation lookaside buffer (TLB) miss event; a lookup instruction TLB (i-TLB) miss event; and a lookup data TLB (d-TLB) miss event. A lookup cache miss event is also called a cache miss event or cache failure event. A branch prediction miss event is also called a branch miss event or branch failure event. A lookup i-cache miss event is also called an i-cache miss event or i-cache failure event. A d-cache miss event is also called a d-cache miss event or a d-cache failure event. A TLB miss event is also called a TLB miss event or a TLB failure event. A i-TLB miss event is also called an i-TLB miss event or an i-TLB failure event. A d-TLB miss event is also called a d-TLB miss event or a d-TLB failure event.

[0028] Optionally, the processor is a central processing unit (CPU). For example, the processor is an advanced RISC machine (ARM) processor. RISC stands for reduced instruction set computer.

[0029] In a second aspect, a performance monitoring device is provided, comprising at least one functional unit for performing the performance monitoring method provided by the first aspect or any alternative method thereof. The at least one functional unit may be implemented based on software, hardware, or a combination of both, and may be arbitrarily combined or divided based on a specific implementation.

[0030] Optional, the performance monitoring device includes the processor's PMU.

[0031] Optionally, the performance monitoring device may also include an operating system (OS) running on the processor.

[0032] Thirdly, a processor is provided, including the performance monitoring device as provided in the second aspect.

[0033] Optionally, the processor is a CPU. For example, the processor is an ARM processor.

[0034] Fourthly, a computer device is provided, including a processor as provided in the third aspect.

[0035] Fifthly, a computer device is provided, including a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory to implement the method provided as described in the first aspect or any alternative to the first aspect.

[0036] In a sixth aspect, a computer-readable storage medium is provided, wherein a computer program is stored therein, which, when executed, implements the method provided as described in the first aspect or any alternative method of the first aspect.

[0037] In a seventh aspect, a computer program product is provided, comprising a program or code that, when executed, implements the method provided as described in the first aspect or any alternative method of the first aspect.

[0038] The technical effects of the second to seventh aspects mentioned above can be referred to the technical effects of the first aspect and its optional implementation methods, and will not be elaborated here. Attached Figure Description

[0039] Figure 1 is a schematic diagram of a PMU provided in an embodiment of this application;

[0040] Figure 2 is a schematic diagram of another PMU provided in an embodiment of this application;

[0041] Figure 3 is a schematic diagram of a performance monitoring method provided in an embodiment of this application;

[0042] Figure 4 is a schematic diagram of another performance monitoring method provided in an embodiment of this application;

[0043] Figure 5 is a schematic diagram of a performance monitoring device provided in an embodiment of this application;

[0044] Figure 6 is a schematic diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0045] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0046] Hotspot code refers to code segments in a program that consume a significant amount of processor resources. Hotspot code analysis is a fundamental method for analyzing program performance. The principle behind hotspot code analysis is that the "hotter" the code segment (the more processor resources it consumes), the greater its optimization potential. Program performance can be improved by optimizing the hotspot code. This requires identifying the hotspot code within the program.

[0047] Currently, single-event sampling is commonly used to identify hotspot code in a program. Specifically, the processor's performance monitoring unit (PMU) includes a counter. The operating system (OS) running on the processor determines performance events based on user commands and configures the counter to count the occurrences of these performance events. During program execution, the counter counts the occurrences of each performance event. When the counter reaches a preset count, it overflows. This overflow triggers an interrupt in the processor. The OS generates a sampling record based on the interrupt context. The OS determines the code segment being executed at the time of the interrupt based on this sampling record (the code segment determined from the sampling record is called the code segment corresponding to that sampling record). The OS identifies hotspot code in the program based on the code segments corresponding to multiple sampling records generated during program execution. Each of these multiple sampling records corresponds to a different interrupt of the processor. The code segment corresponding to each sampling record is the code segment that the processor was executing when the interrupt corresponding to that sampling record occurred. The code segment corresponding to each sampling record can also be called the code segment that the sampling record falls into or hits. The more sampling records a code segment has in the program, the "hotter" it is.

[0048] As an example, a performance event is a clock cycle event. Clock cycle events are also called processor clock cycle events. For example, if the processor is a central processing unit (CPU), the clock cycle event is also called a CPU clock cycle event, or simply a CPU cycle event. The user specifies a clock cycle event through an operation command, specifying a sampling period of 10,000 clock cycles. The OS running on the processor determines the clock cycle event based on this operation command. The OS configures a counter to count the occurrences of the clock cycle event and configures the sampling period for the clock cycle event to 10,000 clock cycles (i.e., configures the overflow threshold of the counter to 10,000). During the execution of the program by the processor, this counter counts the occurrences of the clock cycle event (i.e., the number of times the processor performs this clock cycle event). When the counter counts to 10,000, that is, when the counter counts to the 10,000th clock cycle, the counter overflows. This counter overflow triggers an interrupt in the processor. The OS generates a sampling record based on the context of the interrupt. Based on this sampling record, the OS determines the code segment the processor was executing at the time the interrupt occurred (i.e., the code segment corresponding to the sampling record). The OS identifies hotspot code within the program based on the code segments corresponding to multiple sampling records generated during the processor's execution of the program.

[0049] Generally, code segments with good performance metrics have little or no optimization potential, while code segments with poor performance metrics have greater optimization potential. Therefore, when optimizing a program, it is usually only necessary to focus on the code segments with poor performance metrics. However, single-event sampling cannot identify hotspot code in a program based on performance metrics. The hotspot code identified by single-event sampling may be code segments with good performance metrics, and these hotspot codes with good performance metrics have little optimization potential and poor optimization results. For example, cycles per instruction (CPI) is a relatively authoritative performance metric in the field of performance analysis. CPI is equal to the ratio of the number of clock cycle events to the number of instruction completion events. For example, CPI = cycles / instructions; "cycles" represents the number of clock cycle events, i.e., the number of clock cycles; "instructions" represents the number of instruction completion events, i.e., the number of completed instructions (e.g., the number of instructions successfully executed); the symbol " / " represents division; "CPI" represents the number of clock cycles required to complete each instruction within "cycles" of clock cycles. CPI is used to measure instruction execution efficiency. The higher the CPI of a code segment, the lower its instruction execution efficiency and the greater its optimization potential. The lower the CPI of a code segment, the higher its instruction execution efficiency and the smaller its optimization potential. Using single-event sampling cannot identify hotspot code in a program based on CPI, resulting in identified hotspot code segments with lower CPI. Code segments with lower CPI have less optimization potential and poorer optimization performance.

[0050] This application provides a performance monitoring method, apparatus, and processor. The performance monitoring method is executed by the performance monitoring apparatus. A first counting module is used to count the number of occurrences of a first event during the execution of a target program by the processor, and a second counting module is used to count the number of occurrences of a second event during the execution of the target program by the processor. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program. After the first and second counting modules start counting, the performance monitoring apparatus monitors whether the first and second counting modules overflow. When the performance monitoring apparatus determines that the first counting module has overflowed, it triggers an interrupt in the processor. When the performance monitoring apparatus determines that the first counting module has not overflowed but the second counting module has overflowed, it does not trigger an interrupt in the processor and triggers the first and second counting modules to restart counting. The performance monitoring apparatus determines hot spot code in the target program based on the interrupt in the processor. This application triggers an interrupt in the processor based on the performance index of the target program executed by the processor, making it more likely that the code segment being executed by the processor at the time of the interrupt is a code segment with poor performance index. The hot spot code determined based on the processor interrupt is more likely to be a code segment with poor performance index, and the optimization potential of the determined hot spot code is greater, which helps to improve the optimization effect of the hot spot code.

[0051] In the embodiments of this application, the performance monitoring device can be implemented based on software, hardware, or a combination of software and hardware. For example, the performance monitoring device includes a processor PMU, and optionally an operating system running on the processor. The PMU is located in the processor, and the PMU can be implemented based on hardware or a combination of software and hardware. The processor PMU provided in the embodiments of this application will be described below.

[0052] Please refer to Figure 1, which shows a schematic diagram of a PMU provided in an embodiment of this application. This PMU is used to trigger processor interrupts based on performance indicators. As shown in Figure 1, the PMU includes n counting modules (i.e., counting modules 1 to n), n storage modules (i.e., storage modules 1 to n), an enable control module, an overflow module, and an interrupt control module, where n is a positive integer. The n storage modules are connected one-to-one with the n counting modules, the enable control module is connected to the n storage modules and the interrupt control module respectively, and the overflow module is connected to the n counting modules and the interrupt control module respectively.

[0053] In this system, each of the n counting modules counts the occurrence of a single performance event, while different counting modules count the occurrence of different performance events. For example, each of the n counting modules corresponds to one of the n performance events, and each module counts the occurrence of its corresponding performance event. When a counting module reaches a preset number of occurrences for its corresponding performance event, it overflows. This preset number can be called the overflow line (or the sampling period for the corresponding performance event). The preset numbers for different counting modules can be the same or different, and the sampling periods for different performance events can also be the same or different. As shown in Figure 1, when any of the n counting modules overflows, it sends an overflow signal to the overflow module. The overflow module processes the overflow signal and sends it to the interrupt control module. The interrupt control module determines whether to trigger an interrupt in the processor based on the overflow signal. If it determines that an interrupt needs to be triggered, the interrupt control module issues an interrupt signal to trigger an interrupt in the processor. The interrupt control module does not issue an interrupt signal if it determines that it does not need to trigger an interrupt in the processor, thus preventing the processor from being interrupted.

[0054] In this embodiment, the overflow signal sent by the counting module may carry either the identifier of the performance event being counted by the counting module (i.e., the performance event corresponding to the counting module) or the identifier of the counting module itself. Based on the identifier of the performance event or the identifier of the counting module carried in the overflow signal, the interrupt control module determines whether to trigger an interrupt in the processor using the following two implementation methods.

[0055] The first implementation method is as follows: The overflow signal sent by the counting module carries the identifier of the performance event counted by the counting module, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the performance event carried by the received overflow signal.

[0056] In one embodiment, the interrupt control module records preset performance events, which are performance events used to trigger an interrupt in the processor. The interrupt control module determines the performance event based on the identifier of the performance event carried by the received overflow signal. The interrupt control module determines whether the performance event is a preset performance event. If the performance event is a preset performance event, the interrupt control module determines that an interrupt needs to be triggered in the processor, and issues an interrupt signal to trigger the interrupt. If the performance event is not a preset performance event, the interrupt control module determines that an interrupt does not need to be triggered in the processor, and does not issue an interrupt signal. In an optional embodiment, the interrupt control module is pre-configured to record preset performance events. For example, as shown in Figure 1, the interrupt control module can be configured by the enable control module according to the user's operation command to record preset performance events.

[0057] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records a preset counting module. Each counting module recorded in the first correspondence is used to count the occurrence count of the corresponding performance event. The preset counting module is used to count the occurrence count of a preset performance event, which is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the performance event based on the identifier of the performance event carried by the received overflow signal. The interrupt control module determines the counting module corresponding to the performance event based on the performance event and the first correspondence. The interrupt control module determines whether the counting module corresponding to the performance event is a preset counting module. If the counting module corresponding to the performance event is a preset counting module (meaning the performance event is a preset performance event), the interrupt control module determines that an interrupt needs to be triggered in the processor, and issues an interrupt signal to trigger the interrupt. If the counting module corresponding to the performance event is not a preset counting module (meaning the performance event is not a preset performance event), the interrupt control module determines that an interrupt does not need to be triggered in the processor, and does not issue an interrupt signal. In an optional embodiment, the interrupt control module is pre-configured to record a first correspondence and a preset counting module. For example, as shown in Figure 1, the interrupt control module can be configured by the enable control module according to the user's operation command to record the first correspondence and the preset counting module.

[0058] The second implementation method is as follows: the overflow signal sent by the counting module carries the identifier of the counting module, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the counting module carried by the received overflow signal.

[0059] In one embodiment, the interrupt control module records a preset counting module. This preset counting module is used to count the occurrences of preset performance events, which are performance events that trigger an interrupt in the processor. The interrupt control module identifies the counting module based on the identifier carried by the received overflow signal. The interrupt control module determines whether the counting module is a preset counting module. If the counting module is a preset counting module, the interrupt control module determines that an interrupt needs to be triggered in the processor and issues an interrupt signal to trigger the interrupt. If the counting module is not a preset counting module, the interrupt control module determines that an interrupt does not need to be triggered and does not issue an interrupt signal. In an optional embodiment, the interrupt control module is pre-configured to record the preset counting module. For example, as shown in Figure 1, the enable control module can configure the interrupt control module to record the preset counting module based on user operation commands.

[0060] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records preset performance events. Each counting module recorded in the first correspondence is used to count the occurrences of the corresponding performance event. The preset performance event is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the counting module based on the identifier of the counting module carried by the received overflow signal. The interrupt control module determines the performance event corresponding to the counting module based on the counting module and the first correspondence. The interrupt control module determines whether the performance event corresponding to the counting module is a preset performance event. If the performance event corresponding to the counting module is a preset performance event, the interrupt control module determines that an interrupt needs to be triggered in the processor, and issues an interrupt signal to trigger the interrupt. If the performance event corresponding to the counting module is not a preset performance event, the interrupt control module determines that an interrupt does not need to be triggered in the processor, and does not issue an interrupt signal. In an optional embodiment, the interrupt control module is pre-configured to record the first correspondence and preset performance events. For example, as shown in Figure 1, the interrupt control module can be configured by the enable control module according to the user's operation command to record the first correspondence and preset performance events.

[0061] In an optional embodiment, the aforementioned n counting modules count the occurrences of performance events by counting backwards. Before each of the n counting modules starts counting, the count of that counting module can be set to a preset number corresponding to that counting module (as mentioned above, the preset number corresponding to each counting module is the overflow line for counting the occurrences of the corresponding performance event, which can also be called the sampling period of the performance event), so that the counting module can count the occurrences of performance events by counting backwards. In a specific embodiment, the aforementioned n storage modules correspond one-to-one with the n counting modules, and the n storage modules are used to store the preset numbers corresponding to the n counting modules one-to-one. For each of the n counting modules, before the counting module starts counting, the preset number corresponding to the counting module is loaded from the storage module corresponding to the counting module to the counting module, so that the count of the counting module is set to the preset number corresponding to the counting module.

[0062] In this embodiment, the performance event corresponding to each counting module and the preset number of occurrences for that counting module can be configured by the user. For example, as shown in Figure 1, the enabling control module can configure the performance event corresponding to each counting module and the preset number of occurrences for that counting module according to the user's operation command. In a specific embodiment, the enabling control module configures the performance event corresponding to each counting module according to the user's operation command (that is, configures each counting module to count the occurrences of the corresponding performance event), and the enabling control module stores the preset number of occurrences for that counting module (that is, stores the sampling period of the performance event) in the storage module corresponding to that counting module according to the user's operation command.

[0063] In this embodiment, the counting module can be implemented based on software, hardware, or a combination of software and hardware. Please refer to Figure 2, which shows a schematic diagram of another PMU provided in this embodiment. Each of the n counting modules includes a type register and a count register. For example, counting module 1 includes type register 11 and count register 12, counting module 2 includes type register 21 and count register 22, and so on, with counting module n including type register n1 and count register n2. In each counting module, the count register is connected to the overflow module and the corresponding storage module, respectively. The count register is used to count the number of occurrences of performance events, and the type register is used to store the identifier of the performance event to indicate it. In an optional embodiment, in each counting module, the type register is connected to an enable control module (not shown in Figure 2) for configuration by the enable control module.

[0064] In an optional embodiment, all n storage modules can be registers. The overflow module, enable control module, and interrupt control module can all be implemented based on software, hardware, or a combination of software and hardware. For example, the overflow module is a register.

[0065] It should be noted that the operation commands described above can be the perf command. perf is a performance profiling tool built into the Linux kernel source code tree, which provides a user-facing perf interface through which users can input perf commands.

[0066] It should also be noted that the above names for the counting module are merely illustrative. In some embodiments, the counting module is also referred to as a counter, performance counter, or performance monitoring counter (PMC). In some documents, the type register is also referred to as PMEVTYPER, and the count register as PMEVCNTR. The aforementioned enable control module is also referred to as a checkbit control module. The PMU architecture provided in this application reuses the architecture of the PMU in current advanced RISC (ARM) processors, achieving good compatibility with current ARM processors and reducing the design complexity of the PMU. RISC stands for Reduced Instruction Set Computer.

[0067] In this embodiment, the performance events corresponding to the above n counting modules include at least one of the following: instruction retire event; clock cycle event; lookup cache miss event; branch prediction miss event; lookup instruction cache (i-cache) miss event; lookup data cache (d-cache) miss event; lookup translation lookaside buffer (TLB) miss event; lookup instruction TLB (i-TLB) miss event; and lookup data TLB (d-TLB) miss event. The lookup cache miss event is also called a cache miss event or cache failure event. The branch prediction miss event is also called a branch miss event or branch failure event. The lookup i-cache miss event is also called an i-cache miss event or i-cache failure event. A lookup of a d-cache miss event is also called a d-cache miss event or a data cache failure event. A lookup of a TLB miss event is also called a TLB miss event or a TLB failure event. A lookup of an i-TLB miss event is also called an i-TLB miss event or an instruction TLB failure event. A lookup of a d-TLB miss event is also called a d-TLB miss event or a d-TLB failure event. The number of instruction completion events is the number of completed instructions, such as the number of instructions successfully executed. The number of clock cycle events is the number of clock cycles. The number of lookup cache miss events is the number of times a lookup cache miss has occurred. The number of branch prediction miss events is the number of times a branch prediction miss has occurred. The number of i-cache miss events is the number of times an i-cache miss has occurred. The number of times a d-cache miss occurs is the same as the number of times a d-cache miss occurs. The number of times a TLB miss occurs is the same as the number of times a TLB miss occurs. The number of times an i-TLB miss occurs is the same as the number of times an i-TLB miss occurs. The number of times a d-TLB miss occurs is the same as the number of times a d-TLB miss occurs.

[0068] In the aforementioned performance events, the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric. The first event can include any of the following: clock cycle event; lookup cache miss event; branch prediction miss event; lookup instruction cache miss event; lookup data cache miss event; lookup TLB miss event; lookup instruction TLB miss event; lookup data TLB miss event. The second event can be an instruction completion event. In one example, the first event is a clock cycle event, and the second event is an instruction completion event; the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: cycles per instruction (CPI). In another example, the first event is a lookup cache miss event, and the second event is an instruction completion event; the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: cache misses per instruction (MPI). In another example, the first event is a branch prediction miss, and the second event is an instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: branch misses per instruction. In yet another example, the first event is an i-cache miss, and the second event is an instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: i-cache misses per instruction. In yet another example, the first event is a d-cache miss, and the second event is an instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: d-cache misses per instruction. In yet another example, the first event is a TLB miss, and the second event is an instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: TLB misses per instruction. In another example, the first event is the i-TLB miss event, and the second event is the instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: i-TLB misses per instruction.In another example, the first event is a lookup d-TLB miss event, and the second event is an instruction completion event. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance metric: d-TLB misses per instruction. In optional embodiments, the aforementioned preset performance events include at least one of the following: clock cycle events; lookup cache miss events; branch prediction miss events; lookup instruction cache miss events; lookup data cache miss events; lookup TLB miss events; lookup instruction TLB miss events; and lookup data TLB miss events.

[0069] The above is an introduction to the PMU of the present application. The following is an embodiment of the performance monitoring method of the present application.

[0070] Please refer to Figure 3, which shows a flowchart of a performance monitoring method provided in an embodiment of this application. This performance monitoring method is performed by a performance monitoring device. Referring to Figure 3, the performance monitoring method includes the following steps S301 to S303.

[0071] S301. After the first counting module and the second counting module start counting, monitor whether the first counting module and the second counting module overflow. The first counting module is used to count the number of occurrences of the first event during the execution of the target program by the processor, and the second counting module is used to count the number of occurrences of the second event during the execution of the target program by the processor. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program.

[0072] In an optional embodiment, both the first and second counting modules are located in the processor's PMU, and both modules include registers. For example, the PMU is shown in Figure 1 or Figure 2, and the first and second counting modules are any two of the aforementioned n counting modules. For instance, the first counting module is counting module 1, and the second counting module is counting module 2.

[0073] In optional embodiments, the first event includes any of the following: a clock cycle event; a lookup cache miss event; a branch prediction miss event; a lookup instruction cache miss event; a lookup data cache miss event; a lookup TLB miss event; a lookup instruction TLB miss event; and a lookup data TLB miss event. The second event includes an instruction completion event. The descriptions of the first and second events, as well as the performance metrics represented by the ratio of the number of occurrences of the first event to the number of occurrences of the second event, can be found in the preceding description.

[0074] The performance monitoring device can trigger the first and second counting modules to start counting. After the performance monitoring device triggers the first and second counting modules to start counting, during the execution of the target program by the processor, the first counting module counts the number of times the first event occurs (that is, the first counting module counts the number of times the first event occurs by the processor), and the second counting module counts the number of times the second event occurs (that is, the second counting module counts the number of times the second event occurs by the processor). The performance monitoring device monitors whether the first and second counting modules overflow.

[0075] In an optional embodiment, the first counting module overflows when the count reaches a first count, and the second counting module overflows when the count reaches a second count. After the performance monitoring device triggers the first and second counting modules to start counting, the performance monitoring device monitors whether the count of the first counting module has reached the first count, and whether the count of the second counting module has reached the second count. When the count of the first counting module reaches the first count, the performance monitoring device determines that the first counting module has overflowed. When the count of the second counting module reaches the second count, the performance monitoring device determines that the second counting module has overflowed. Here, the first count is a preset count corresponding to the first counting module, which is the overflow threshold for the first counting module to count the occurrence of the first event; the first count is also called the sampling period of the first event. The second count is a preset count corresponding to the second counting module, which is the overflow threshold for the second counting module to count the occurrence of the second event; the second count is also called the sampling period of the second event. The ratio of the first count to the second count is not less than a preset ratio. Since the first counting module overflows when the count reaches the first value, and the second counting module overflows when the count reaches the second value, and the ratio of the first value to the second value is not less than a preset ratio, when the first counting module overflows, the ratio of the number of occurrences of the first event counted by the first counting module to the number of occurrences of the second event counted by the second counting module is not less than the preset ratio. Furthermore, since the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program, when the first counting module overflows, the probability that the code segment being executed by the processor is a code segment with poor performance is relatively high, and the optimization potential of the code segment being executed by the processor is relatively high. As an example, the first event is a clock cycle event, and the second event is an instruction completion event. The first count is 20000 (i.e., the sampling period of the clock cycle event is 20000), and the second count is 10000 (i.e., the sampling period of the instruction completion event is 10000). The ratio of the first count to the second count is 2, and the preset ratio is 2. The ratio of the first count to the second count is equal to the preset ratio. The first counting module counts the number of clock cycle events, with an overflow threshold of 20000. The second counting module counts the number of instruction completion events, with an overflow threshold of 10000. When the first counting module overflows, the ratio of its count to the count of the second counting module is greater than or equal to 2, meaning the ratio of clock cycle events to instruction completion events is greater than or equal to 2.Since the ratio of the number of clock cycle events to the number of instruction completion events is used to characterize CPI, the probability that the code segment being executed by the processor when the first counter module overflows is a code segment with a CPI greater than 2 (a code segment with a poor CPI) is relatively high, and the code segment being executed by the processor when the first counter module overflows has great optimization potential.

[0076] In an optional embodiment, a first counting module is used to count the occurrences of a first event by counting backwards, and a second counting module is used to count the occurrences of a second event by counting backwards. Before the first counting module starts counting, the performance monitoring device initializes the count of the first counting module to the first count. Before the second counting module starts counting, the performance monitoring device initializes the count of the second counting module to the second count. After the performance monitoring device initializes the count of the first counting module to the first count and triggers the first counting module to start counting, the first counting module counts backwards from the first count during the execution of the target program by the processor. When the first counting module counts down to 0, the count of the first counting module reaches the first count, and the first counting module overflows. After the performance monitoring device initializes the count of the second counting module to the second count and triggers the second counting module to start counting, the second counting module counts backwards from the second count during the execution of the target program by the processor. When the second counting module counts down to 0, the count of the second counting module reaches the second count, and the second counting module overflows. In an optional embodiment, after the performance monitoring device triggers the first and second counting modules to start counting, the performance monitoring device monitors whether the first counting module has counted down to 0, and the performance monitoring device monitors whether the second counting module has counted down to 0. When it is determined that the first counting module has counted down to 0, the performance monitoring device determines that the count of the first counting module has reached the first count, and then determines that the first counting module has overflowed. When the second counting module counts down to 0, the performance monitoring device determines that the count of the second counting module has reached the second count, and then determines that the second counting module has overflowed.

[0077] In an optional embodiment, the first storage module corresponds to the first counting module, and the first storage module is used to store the first count (that is, the overflow line for the first counting module to count the occurrence of the first event). The second storage module corresponds to the second counting module, and the second storage module is used to store the second count (that is, the overflow line for the second counting module to count the occurrence of the second event). Before the first counting module starts counting, the performance monitoring device loads the first count from the first storage module into the first counting module to initialize the count of the first counting module to the first count. Before the second counting module starts counting, the performance monitoring device loads the second count from the second storage module into the second counting module to initialize the count of the second counting module to the second count.

[0078] In an optional embodiment, before loading the first count from the first storage module to the first counting module, the performance monitoring device stores the first count in the first storage module. Before loading the second count from the second storage module to the second counting module, the performance monitoring device stores the second count in the second storage module. For example, the performance monitoring device stores the first count in the first storage module according to user configuration, and the performance monitoring device stores the second count in the second storage module according to user configuration. In a specific embodiment, the performance monitoring device receives an operation command from a user, the operation command carrying the first count and the second count; the performance monitoring device stores the first count in the first storage module according to the operation command, and the performance monitoring device stores the second count in the second storage module according to the operation command.

[0079] As an example, the user's command is the `perf` command. The first event is the clock cycle event, and the second event is the instruction completion event. The first count is 20000, and the second count is 10000. Therefore, the specific `perf` command could be "perf record -e cpu / event=". <cycles>,period=20000 / -e cpu / event= <instructions>"period=10000 / --ratio-profiling". In this perf command: "-ecpu / event= <cycles>"Indicates a clock cycle event, "-e cpu / event= <cycles>"period=20000" indicates that the sampling period for the clock cycle event is 20000 (that is, the overflow line for the counting module to count the occurrences of the clock cycle event is 20000; the counting module used to count the occurrences of the clock cycle event overflows once every 20000 occurrences of the clock cycle event); "-ecpu / event= <instructions>"Indicates an instruction completion event, "-e cpu / event=" <instructions>"period=10000" indicates that the sampling period for the instruction completion event is 10000 (that is, the overflow line for the counting module to count the occurrence of the instruction completion event is 10000; the counting module used to count the occurrence of the instruction completion event overflows once every 10000 occurrences of the instruction completion event); "ratio-profiling" indicates performance profiling based on ratios. According to this perf command, the performance monitoring device stores the sampling period "20000" (that is, the first count) of the clock cycle event (i.e., the first event) into the storage module (i.e., the first storage module) corresponding to the counting module (i.e., the first counting module) used to count the occurrence of the clock cycle event. According to this perf command, the performance monitoring device stores the sampling period "10000" (that is, the second count) of the instruction completion event (i.e., the second event) into the storage module (i.e., the second storage module) corresponding to the counting module (i.e., the second counting module) used to count the occurrence of the instruction completion event.

[0080] In an optional embodiment, both the first and second storage modules are located in the processor's PMU, which further includes a control module X. The performance monitoring device stores a first data point in the first storage module according to a user's operation command via the control module X. The performance monitoring device also stores a second data point in the second storage module according to a user's operation command via the control module X. That is, the control module X stores both the first and second data points in the first and second storage modules according to the user's operation command. For example, as shown in Figure 1 or Figure 2, the PMU includes a first counting module (counting module 1), a second counting module (counting module 2), a first storage module (storage module 1), a second storage module (storage module 2), and an enable control module X.

[0081] S302. When it is determined that the first counting module has overflowed, an interrupt is triggered in the processor.

[0082] When the performance monitoring device determines that the first counting module has overflowed, the performance monitoring device sends an interrupt signal to trigger an interrupt in the processor.

[0083] In an optional embodiment, the performance monitoring device includes a PMU as shown in Figure 1 or Figure 2, and the first counting module is counting module 1. As shown in Figure 1 or Figure 2, when the first counting module overflows, it sends an overflow signal to the overflow module. The overflow module processes the overflow signal and then sends it to the interrupt control module. The interrupt control module triggers an interrupt in the processor based on the overflow signal. In a specific embodiment, the interrupt control module determines whether an interrupt needs to be triggered based on the overflow signal. If the interrupt control module determines that an interrupt needs to be triggered, it issues an interrupt signal to trigger an interrupt in the processor. If the interrupt control module determines that an interrupt does not need to be triggered, it does not issue an interrupt signal and thus does not trigger an interrupt in the processor. This embodiment uses the example of the interrupt control module determining that an interrupt needs to be triggered based on the overflow signal; therefore, the interrupt control module issues an interrupt signal to trigger an interrupt in the processor.

[0084] In this embodiment, the overflow signal sent by the first counting module may carry either the identifier of the first event or the identifier of the first counting module. Based on the overflow signal carrying either the identifier of the first event or the identifier of the first counting module, the interrupt control module determines whether to trigger an interrupt in the processor, including the following two implementation methods.

[0085] The first implementation method is as follows: The overflow signal sent by the first counting module carries the identifier of the first event, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the first event carried by the overflow signal sent by the first counting module.

[0086] In one embodiment, the interrupt control module records preset performance events, which are performance events used to trigger a processor interrupt. The interrupt control module determines the first event based on the identifier of the first event carried by the overflow signal sent by the first counting module. The interrupt control module determines whether the first event is a preset performance event. If the first event is a preset performance event, the interrupt control module determines that a processor interrupt needs to be triggered. If the first event is not a preset performance event, the interrupt control module determines that a processor interrupt does not need to be triggered. This embodiment of the application uses the first event being a preset performance event as an example, therefore the interrupt control module determines that a processor interrupt needs to be triggered.

[0087] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records a preset counting module. Each counting module recorded in the first correspondence is used to count the occurrence count of the corresponding performance event. The preset counting module is used to count the occurrence count of a preset performance event, which is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the first event based on the identifier of the first event carried by the overflow signal sent by the first counting module. The interrupt control module determines the counting module (i.e., the first counting module) corresponding to the first event based on the first event and the first correspondence. The interrupt control module determines whether the first counting module is a preset counting module. If the first counting module is a preset counting module (meaning the first event is a preset performance event), the interrupt control module determines that an interrupt in the processor needs to be triggered. If the first counting module is not a preset counting module (meaning the first event is not a preset performance event), the interrupt control module determines that an interrupt in the processor does not need to be triggered. This embodiment uses the example of the first counting module being a preset counting module, therefore the interrupt control module determines that an interrupt in the processor needs to be triggered.

[0088] The second implementation method is as follows: The overflow signal sent by the first counting module carries the identifier of the first counting module, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the first counting module carried by the overflow signal sent by the first counting module.

[0089] In one embodiment, the interrupt control module records a preset counting module, which is used to count the occurrence of preset performance events. These preset performance events are performance events used to trigger an interrupt in the processor. The interrupt control module determines the first counting module based on the identifier of the first counting module carried in the overflow signal sent by the first counting module. The interrupt control module then determines whether the first counting module is a preset counting module. If the first counting module is a preset counting module, the interrupt control module determines that an interrupt needs to be triggered in the processor. If the first counting module is not a preset counting module, the interrupt control module determines that an interrupt does not need to be triggered in the processor. This embodiment uses the example of the first counting module being a preset counting module; therefore, the interrupt control module determines that an interrupt needs to be triggered in the processor.

[0090] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records preset performance events. Each counting module recorded in the first correspondence is used to count the occurrences of the corresponding performance event. The preset performance event is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the first counting module based on the identifier of the first counting module carried by the overflow signal sent by the first counting module. The interrupt control module determines the performance event (i.e., the first event) corresponding to the first counting module based on the first counting module and the first correspondence. The interrupt control module determines whether the first event is a preset performance event. If the first event is a preset performance event, the interrupt control module determines that an interrupt in the processor needs to be triggered. If the first event is not a preset performance event, the interrupt control module determines that an interrupt in the processor does not need to be triggered. This embodiment of the application uses the first event being a preset performance event as an example for illustration, therefore the interrupt control module determines that an interrupt in the processor needs to be triggered.

[0091] S303. When it is determined that the first counting module has not overflowed but the second counting module has overflowed, the first counting module and the second counting module are triggered to restart counting.

[0092] When the performance monitoring device determines that the first counting module has not overflowed but the second counting module has overflowed, the performance monitoring device does not trigger an interrupt in the processor, but instead triggers the first and second counting modules to restart counting. After the first and second counting modules restart counting, during the execution of the target program by the processor, the first counting module counts the occurrence of the first event, and the second counting module counts the occurrence of the second event. The performance monitoring device monitors whether the first and second counting modules have overflowed. If the performance monitoring device determines that the first counting module has overflowed, it triggers another interrupt in the processor. If the performance monitoring device determines that the first counting module has not overflowed but the second counting module has overflowed, it triggers the first and second counting modules to restart counting again. That is, after the performance monitoring device triggers the first and second counting modules to restart counting, the performance monitoring device re-executes steps S301 to 303.

[0093] In an optional embodiment, the performance monitoring device includes a PMU as shown in Figure 1 or Figure 2, a first counting module (counting module 1), and a second counting module (counting module 2). As shown in Figure 1 or Figure 2, when the second counting module overflows, it sends an overflow signal to the overflow module. The overflow module processes the overflow signal and then sends it to the interrupt control module. The interrupt control module determines whether an interrupt needs to be triggered in the processor based on the overflow signal. If the interrupt control module determines that an interrupt needs to be triggered, it issues an interrupt signal to trigger an interrupt. If the interrupt control module determines that an interrupt does not need to be triggered, it does not issue an interrupt signal and triggers the first and second counting modules to restart counting. This embodiment illustrates the case where the interrupt control module determines that an interrupt does not need to be triggered based on the overflow signal; therefore, the interrupt control module does not issue an interrupt signal and triggers the first and second counting modules to restart counting.

[0094] In this embodiment, the overflow signal sent by the second counting module may carry either the identifier of the second event or the identifier of the second counting module. Based on the overflow signal carrying either the identifier of the second event or the identifier of the second counting module, the interrupt control module determines whether to trigger a processor interrupt, including the following two implementation methods.

[0095] The first implementation method is as follows: The overflow signal sent by the second counting module carries the identifier of the second event, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the second event carried by the overflow signal sent by the second counting module.

[0096] In one embodiment, the interrupt control module records preset performance events, which are performance events used to trigger a processor interrupt. The interrupt control module determines the second event based on the identifier of the second event carried by the overflow signal sent by the second counting module. The interrupt control module determines whether the second event is a preset performance event. If the second event is a preset performance event, the interrupt control module determines that a processor interrupt needs to be triggered. If the second event is not a preset performance event, the interrupt control module determines that a processor interrupt does not need to be triggered. This embodiment of the application illustrates the case where the second event is not a preset performance event; therefore, the interrupt control module determines that a processor interrupt does not need to be triggered.

[0097] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records a preset counting module. Each counting module recorded in the first correspondence is used to count the occurrence count of the corresponding performance event. The preset counting module is used to count the occurrence count of a preset performance event, which is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the second event based on the identifier of the second event carried by the overflow signal sent by the second counting module. The interrupt control module determines the counting module (i.e., the second counting module) corresponding to the second event based on the second event and the first correspondence. The interrupt control module determines whether the second counting module is a preset counting module. If the second counting module is a preset counting module (meaning the second event is a preset performance event), the interrupt control module determines that an interrupt in the processor needs to be triggered. If the second counting module is not a preset counting module (meaning the second event is not a preset performance event), the interrupt control module determines that an interrupt in the processor does not need to be triggered. This embodiment of the application uses the example of the second counting module not being a preset counting module, therefore the interrupt control module determines that an interrupt in the processor does not need to be triggered.

[0098] The second implementation method is as follows: the overflow signal sent by the second counting module carries the identifier of the second counting module, and the interrupt control module determines whether to trigger an interrupt in the processor based on the identifier of the second counting module carried by the overflow signal sent by the second counting module.

[0099] In one embodiment, the interrupt control module records a preset counting module, which is used to count the occurrences of preset performance events. These preset performance events are performance events used to trigger an interrupt in the processor. The interrupt control module determines the second counting module based on the identifier of the second counting module carried in the overflow signal sent by the second counting module. The interrupt control module then determines whether the second counting module is a preset counting module. If the second counting module is a preset counting module, the interrupt control module determines that an interrupt needs to be triggered in the processor. If the second counting module is not a preset counting module, the interrupt control module determines that an interrupt does not need to be triggered in the processor. This embodiment illustrates the case where the second counting module is not a preset counting module; therefore, the interrupt control module determines that an interrupt does not need to be triggered in the processor.

[0100] In another embodiment, the interrupt control module records a first correspondence between performance events and counting modules, and also records preset performance events. Each counting module recorded in the first correspondence is used to count the occurrences of the corresponding performance event. The preset performance event is a performance event used to trigger an interrupt in the processor. The interrupt control module determines the second counting module based on the identifier of the second counting module carried by the overflow signal sent by the second counting module. The interrupt control module determines the performance event (i.e., the second event) corresponding to the second counting module based on the second counting module and the first correspondence. The interrupt control module determines whether the second event is a preset performance event. If the second event is a preset performance event, the interrupt control module determines that an interrupt in the processor needs to be triggered. If the second event is not a preset performance event, the interrupt control module determines that an interrupt in the processor does not need to be triggered. This embodiment of the application illustrates the case where the second event is not a preset performance event, therefore the interrupt control module determines that an interrupt in the processor does not need to be triggered.

[0101] In an optional embodiment, the first counting module overflows when the count reaches a first count, and the second counting module overflows when the count reaches a second count. The first counting module is used to count the occurrence of the first event by counting backwards, and the second counting module is used to count the occurrence of the second event by counting backwards. When the performance monitoring device determines that the first counting module has not overflowed but the second counting module has overflowed, the performance monitoring device resets the count of the first counting module to the first count and the count of the second counting module to the second count, thereby triggering the first and second counting modules to restart counting. In a specific embodiment, when the performance monitoring device determines that the first counting module has not overflowed but the second counting module has overflowed, the performance monitoring device reloads the first count from the first storage module to the first counting module to reset the count of the first counting module to the first count, and the performance monitoring device reloads the second count from the second storage module to the second counting module to reset the count of the second counting module to the second count.

[0102] As an example, the first event is a clock cycle event, and the second event is an instruction completion event. The first count is 20000 (i.e., the sampling period for the clock cycle event is 20000), and the second count is 10000 (i.e., the sampling period for the instruction completion event is 10000). The ratio of the first count to the second count is 2, and this ratio is preset to be 2. The first counting module is used to count the occurrences of the clock cycle event, and its overflow threshold is 20000. The second counting module is used to count the occurrences of the instruction completion event, and its overflow threshold is 10000. When the first counting module has not overflowed and the second counting module has overflowed, the ratio of the counts of the first counting module to the counts of the second counting module is less than 2, meaning the ratio of the occurrences of the clock cycle event to the occurrences of the instruction completion event is less than 2. Since the ratio of clock cycle events to instruction completion events is used to characterize the Clock Performance Index (CPI), when the first counter module has not overflowed but the second counter module has overflowed, the probability that the code segment being executed by the processor is a code segment with a CPI less than 2 (a code segment with a better CPI) is relatively high, and the optimization potential of the code segment being executed by the processor is relatively low. If the performance monitoring device triggers a processor interrupt when the first counter module has not overflowed but the second counter module has overflowed, then the optimization potential of the hot code determined by the performance monitoring device based on the interrupt is relatively low. Therefore, when the first counter module has not overflowed but the second counter module has overflowed, the performance monitoring device does not trigger a processor interrupt, but only triggers the first and second counter modules to restart counting.

[0103] It should be noted that the first counting module does not send an overflow signal when it has not overflowed. Therefore, the overflow module and the interrupt control module cannot receive the overflow signal sent by the first counting module. Thus, the above description of S303 mainly describes the relevant content of the second counting module.

[0104] In summary, the technical solution provided in this application involves a first counting module counting the occurrences of a first event during the execution of the target program by the processor, and a second counting module counting the occurrences of a second event during the same process. The ratio of the occurrences of the first event to the second event is used to characterize the performance metrics of the target program. When the first counting module overflows, the processor is interrupted. When neither the first nor the second counting module overflows, the processor is not interrupted, and both the first and second counting modules restart counting. Therefore, when the processor is interrupted, the probability that the code segment being executed by the processor is a code segment with poor performance metrics is relatively high. Hotspot code identified based on processor interrupts is also more likely to be a code segment with poor performance metrics, and hotspot code identified based on processor interrupts has greater optimization potential, which helps improve the optimization effect of hotspot code. Not triggering a processor interrupt when neither the first nor the second counting module overflows avoids the possibility of identifying code segments with good performance metrics as hotspot code due to an interruption occurring when the first counting module has not overflowed. Triggering a restart of counting by both the first and second counting modules when neither overflows facilitates the start of a new round of counting.

[0105] Furthermore, the first counting module overflows when it reaches the first count, and the second counting module overflows when it reaches the second count, with the ratio of the first count to the second count not less than a preset ratio. Therefore, when the first counting module overflows, the ratio of the number of occurrences of the first event counted by the first counting module to the number of occurrences of the second event counted by the second counting module is not less than this preset ratio. Since the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program, when the first counting module overflows, the probability that the code segment being executed by the processor is a code segment with poor performance is relatively high, and the optimization potential of the code segment being executed by the processor is relatively high. When the first counting module overflows, the processor interrupts, making it highly likely that the hotspot code determined by the processor interrupt is a code segment with poor performance, and the optimization potential of the hotspot code determined by the processor interrupt is relatively high.

[0106] In an optional embodiment, please refer to Figure 4, which shows a flowchart of another performance monitoring method provided by an embodiment of this application. Based on the performance monitoring method shown in Figure 3, the performance monitoring method shown in Figure 4 further includes the following step S304.

[0107] S304. After the trigger processor is interrupted, the first and second counting modules are triggered to restart counting.

[0108] After a processor interrupt is triggered, the performance monitoring device can handle the interrupt. For example, the performance monitoring device includes an interrupt service routine (ISR) running on the processor, which handles the interrupt.

[0109] After handling the interrupt, the performance monitoring device triggers the first and second counting modules to restart counting, and also triggers the processor to continue executing the target program. After the first and second counting modules restart counting, during the processor's execution of the target program, the first counting module counts the occurrence of the first event, and the second counting module counts the occurrence of the second event. The performance monitoring device monitors whether the first and second counting modules overflow. If the performance monitoring device determines that the first counting module has overflowed, it triggers the processor to interrupt again. If the performance monitoring device determines that the first counting module has not overflowed but the second counting module has overflowed, it triggers both the first and second counting modules to restart counting. That is, after the performance monitoring device triggers the first and second counting modules to restart counting, it re-executes steps S301 to 303.

[0110] In an optional embodiment, the first counting module overflows when the count reaches the first count, and the second counting module overflows when the count reaches the second count. The first counting module is used to count the occurrence of the first event by counting backwards, and the second counting module is used to count the occurrence of the second event by counting backwards. After the performance monitoring device handles the interrupt, it resets the count of the first counting module to the first count and the count of the second counting module to the second count, thereby triggering the first and second counting modules to restart counting. In a specific embodiment, after the performance monitoring device handles the interrupt, it reloads the first count from the first storage module to the first counting module to reset the count of the first counting module to the first count; and it reloads the second count from the second storage module to the second counting module to reset the count of the second counting module to the second count.

[0111] As described in S301 to S304, when either the first counting module or the second counting module overflows, the performance monitoring device triggers both the first and second counting modules to restart counting. Furthermore, as long as the first counting module overflows, regardless of whether the second counting module overflows, the performance monitoring device triggers a processor interrupt. That is, whether a processor interrupt is triggered is independent of whether the second counting module overflows. In an optional embodiment, the first and second counting modules overflow simultaneously, and both send an overflow signal to the overflow module. The overflow module processes the overflow signal sent by the first counting module and then sends the overflow signal to the interrupt control module. The overflow module processes the overflow signal sent by the second counting module and then sends the overflow signal to the interrupt control module. The interrupt control module determines that a processor interrupt needs to be triggered based on the overflow signal sent by the first counting module, and then issues an interrupt signal to trigger a processor interrupt. In this case, the interrupt control module may not process the overflow signal sent by the second counting module to improve processing efficiency.

[0112] In an optional embodiment, the performance monitoring device includes the processor's PMU and an OS running on the processor. After triggering an interrupt in the processor, the OS triggers the first and second counting modules to restart counting (i.e., S304 can be executed by the OS). If it is not necessary to trigger an interrupt in the processor, the PMU triggers the first and second counting modules to restart counting (i.e., S303 can be executed by the PMU), and this embodiment of the application does not limit this.

[0113] In summary, the technical solution provided in this application embodiment allows the performance monitoring device to trigger the first and second counting modules to restart counting after the processor is interrupted, which facilitates triggering the processor to be interrupted again when the first counting module overflows again.

[0114] In an optional embodiment, before the performance monitoring device triggers the first counting module and the second counting module to start counting, the performance monitoring device configures the function of the first counting module to count the occurrence of the first event, and configures the function of the second counting module to count the occurrence of the second event. Referring again to Figure 4, the performance monitoring method further includes the following step S305. The performance monitoring device may execute S305 before executing S301.

[0115] S305. Configure the function of the first counting module to count the number of times the first event occurs, and configure the function of the second counting module to count the number of times the second event occurs.

[0116] In an optional embodiment, the performance monitoring device receives an operation command from the user, and according to the operation command, the performance monitoring device configures the function of the first counting module to count the number of occurrences of the first event, and configures the function of the second counting module to count the number of occurrences of the second event.

[0117] In one embodiment, the user's operation command carries configuration information for a first event and configuration information for a second event. The configuration information for the first event includes the identifier of a first counting module and the identifier of the first event. The configuration information for the second event includes the identifier of a second counting module and the identifier of the second event. The performance monitoring device determines the first counting module and the first event based on the configuration information of the first event, and configures the function of the first counting module to count the occurrences of the first event. The performance monitoring device determines the second counting module and the second event based on the configuration information of the second event, and configures the function of the second counting module to count the occurrences of the second event. That is, the user's operation command specifies that the first counting module counts the occurrences of the first event and the second counting module counts the occurrences of the second event. The performance monitoring device configures the function of the first counting module to count the occurrences of the first event and the function of the second counting module to count the occurrences of the second event according to the instruction of the operation command.

[0118] In another embodiment, the user's operation command carries an identifier for a first event and an identifier for a second event. The performance monitoring device determines the first event based on the identifier of the first event, and determines the second event based on the identifier of the second event. The performance monitoring device identifies two idle counting modules (i.e., counting modules without functional configuration) in the counting module of the processor's PMU. The performance monitoring device configures one of these two idle counting modules (i.e., the first counting module) to count the occurrences of the first event. The performance monitoring device configures the other of these two idle counting modules (i.e., the second counting module) to count the occurrences of the second event. That is, the user's operation command specifies the first event and the second event, but does not specify a first counting module to count the occurrences of the first event and a second counting module to count the occurrences of the second event. In this case, the performance monitoring device identifies two idle counting modules in the PMU as the first counting module and the second counting module, respectively, and configures the first counting module to count the occurrences of the first event and the second counting module to count the occurrences of the second event. That is, if the user's operation command does not specify a first counting module for counting the occurrence of the first event and a second counting module for counting the occurrence of the second event, the performance monitoring device assigns counting modules to the first event and the second event. This application embodiment does not limit this.

[0119] As an example, the user's command is the `perf` command. The first event is the clock cycle event, and the second event is the instruction completion event. The first count is 20000, and the second count is 10000. Therefore, the specific `perf` command could be "perf record -e cpu / event=". <cycles>,period=20000 / -e cpu / event= <instructions>"period=10000 / --ratio-profiling". In this perf command: "-ecpu / event= <cycles>"" indicates a clock cycle event, and "cycles" can be used as an identifier for clock cycle events; "-e cpu / event=" <instructions>The "" indicates an instruction completion event, and "instructions" can be used as identifiers for instruction completion events. The performance monitoring device uses the "-ecpu / event=" in the perf command. <cycles>"To determine clock cycle events, the performance monitoring device uses the '-e cpu / event=' option in the perf command." <instructions>"Identify instruction completion events. The performance monitoring device identifies two idle counting modules in the processor's PMU counting module; the performance monitoring device configures one of these two idle counting modules to count the number of clock cycle events; the performance monitoring device configures the other of these two idle counting modules to count the number of instruction completion events."

[0120] In an optional embodiment, the PMU includes a control module X. The performance monitoring device configures the first counting module to count the occurrence of a first event and the second counting module to count the occurrence of a second event according to the user's operation command via the control module X. That is, the control module X configures the first counting module to count the occurrence of the first event according to the user's operation command, and the control module X configures the second counting module to count the occurrence of the second event according to the user's operation command.

[0121] In an optional embodiment, the performance monitoring device configures the first counting module to count the occurrence of the first event, also known as enabling the first counting module. The performance monitoring device configures the second counting module to count the occurrence of the second event, also known as enabling the second counting module. After enabling the first counting module, the performance monitoring device stores the sampling period of the first event (i.e., the first count) into the first storage module corresponding to the first counting module. After enabling the second counting module, the performance monitoring device stores the sampling period of the second event (i.e., the second count) into the second storage module corresponding to the second counting module.

[0122] After the performance monitoring device triggers an interrupt in the processor, it can process the interrupt. For example, the performance monitoring device samples the interrupt. Referring to Figure 4, after S302, the performance monitoring method further includes the following step S306.

[0123] S306. Obtain a sampling record based on the interrupt context. This sampling record is used to record information about the code segment that the processor was executing when the interrupt was generated. This code segment is a code segment in the target program.

[0124] After a performance monitoring device triggers a processor interrupt, it acquires the context of the interrupt and then obtains sampling records based on that context. For example, the performance monitoring device performs interrupt sampling based on the interrupt context to obtain sampling records.

[0125] In an optional embodiment, the context of the interrupt includes the address of the target program being executed by the processor at the time the interrupt occurs and the address of the instruction being executed by the processor. The instruction being executed by the processor is an instruction in the target program, and the instruction being executed by the processor is an instruction in a code segment within the target program. The performance monitoring device determines the code segment being executed by the processor at the time the interrupt occurs based on the address of the target program being executed by the processor and the address of the instruction being executed by the processor. The performance monitoring device generates a sampling record based on the code segment being executed by the processor at the time the interrupt occurs.

[0126] In an optional embodiment, after the performance monitoring device obtains the sampling record based on the context of the interruption, it stores the sampling record for subsequent application. For example, the performance monitoring device stores the sampling record in a buffer space.

[0127] In an optional embodiment, the performance monitoring device includes an OS running on the processor, and S306 is executed by the OS.

[0128] In an optional embodiment, after the performance monitoring device acquires the interrupt sampling records, it determines the hotspot code in the target program based on the interrupt sampling records. Referring again to Figure 4, after S306, the performance monitoring method further includes the following step S307.

[0129] S307. Determine the hotspot code in the target program based on the sampling records.

[0130] In an optional embodiment, during the execution of the target program by the processor, the first counting module overflows multiple times, and the performance monitoring device triggers multiple interrupts to the processor. After each interrupt, the performance monitoring device obtains sampling records based on the context of the interrupt. Therefore, during the execution of the target program by the processor, the performance monitoring device can obtain multiple sampling records. The performance monitoring device can determine the hot spot code in the target program based on these multiple sampling records. Each of these multiple sampling records corresponds to one of the multiple interrupts of the processor, and each sampling record corresponds to a code segment in the target program. The code segment corresponding to each sampling record is the code segment being executed by the processor when the interrupt corresponding to that sampling record occurs. The code segment corresponding to each sampling record can also be called the code segment that the sampling record falls into or hits. The more sampling records a code segment in the target program corresponds to, the "hotter" it is. In an optional embodiment, the performance monitoring device determines the code segment in the target program with the most corresponding sampling records as the hot spot code. Alternatively, the performance monitoring device determines the code segment in the target program with more than a preset number of corresponding sampling records as the hot spot code.

[0131] In an optional embodiment, the performance monitoring device includes an OS running on the processor, and S307 is executed by the OS.

[0132] After identifying hotspot code in the target program, the performance monitoring device can optimize that code. For example, the performance monitoring device can optimize the hotspot code directly, or experienced personnel can optimize it.

[0133] In summary, the technical solution provided in this application involves a performance monitoring device triggering an interrupt in the processor based on the performance metrics of the target program executed by the processor. The performance monitoring device obtains sampling records based on the interrupt context and determines hotspot code in the target program based on the sampling records. Therefore, the hotspot code determined by the performance monitoring device is more likely to be a code segment with poor performance metrics, and the hotspot code determined by the performance monitoring device has greater optimization potential, which helps improve the optimization effect of the hotspot code.

[0134] The technical solution provided in this application embodiment triggers a processor interrupt when the first counting module overflows, and obtains sampling records based on the interrupt context; the performance monitoring device does not trigger a processor interrupt when the first counting module does not overflow and the second counting module overflows. That is, the performance monitoring device performs interrupt sampling when the first counting module overflows, and does not perform interrupt sampling when the first counting module does not overflow and the second counting module overflows. Therefore, invalid sampling can be greatly reduced, and sampling overhead can be lowered. This allows the technical solution provided in this application embodiment to be applied not only in performance analysis tools but also in production environments.

[0135] In the technical solution provided in this application embodiment, the interrupt context may further include call information of the instructions being executed by the processor when the interrupt occurs. The performance monitoring device can also determine the call information of the code segment being executed by the processor when the interrupt occurs based on the call information of the instructions being executed by the processor when the interrupt occurs, and then generate the call stack of the code segment based on the call information of the code segment. Since the interrupt is triggered based on performance indicators, the call stack of the code segment obtained by the performance monitoring device based on the interrupt is a call stack based on performance indicators. Therefore, this application embodiment can obtain the call stack of hot code based on performance indicators.

[0136] The above is a description of the method embodiments of this application. The following describes the apparatus embodiments of this application, which are used to execute the method of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the method embodiments.

[0137] This application provides a performance monitoring device, including at least one functional unit. This at least one functional unit is used to perform all or part of the operations of the performance monitoring method provided in the embodiments shown in Figures 3 and 4. The at least one functional unit can be implemented based on software, hardware, or a combination of software and hardware, and can be arbitrarily combined or divided based on specific implementations.

[0138] As an example, please refer to Figure 5, which shows a schematic diagram of a performance monitoring device 500 provided in an embodiment of this application. The performance monitoring device 500 includes a monitoring unit 501, an interrupt unit 502, and a trigger unit 503.

[0139] The monitoring unit 501 is used to monitor whether the first counting module and the second counting module overflow after the first counting module and the second counting module start counting. The first counting module is used to count the number of occurrences of the first event during the execution of the target program by the processor, and the second counting module is used to count the number of occurrences of the second event during the execution of the target program by the processor. The ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to characterize the performance index of the target program.

[0140] Interrupt unit 502 is used to trigger an interrupt in the processor when it is determined that the first counting module has overflowed;

[0141] The triggering unit 503 is used to trigger the first and second counting modules to restart counting when it is determined that the first counting module has not overflowed and the second counting module has overflowed.

[0142] Optionally, the first counting module overflows when the count reaches the first number, and the second counting module overflows when the count reaches the second number, with the ratio of the first number to the second number not less than a preset ratio.

[0143] Optionally, the first counting module is used to count the number of occurrences of the first event by counting backwards, and the second counting module is used to count the number of occurrences of the second event by counting backwards. Referring again to Figure 5, the performance monitoring device 500 also includes an initialization unit 504. The initialization unit 504 is used to: initialize the count of the first counting module to the first count before the first counting module starts counting; and initialize the count of the second counting module to the second count before the second counting module starts counting.

[0144] Optionally, referring to Figure 5, the performance monitoring device 500 also includes a reset unit 505.

[0145] The reset unit 505 is used to: reset the count of the first counting module to the first count after the trigger processor is interrupted; and to reset the count of the second counting module to the second count after the trigger processor is interrupted.

[0146] The trigger unit 503 is also used to trigger the first counting module and the second counting module to restart counting after an interrupt occurs in the trigger processor.

[0147] Optionally, the initialization unit 504 is used to: load the first number from the first storage module into the first counting module, the first storage module being used to store the first number; and load the second number from the second storage module into the second counting module, the second storage module being used to store the second number.

[0148] Optionally, the reset unit 505 is used to: reload the first number from the first storage module to the first counting module, the first storage module being used to store the first number; and reload the second number from the second storage module to the second counting module, the second storage module being used to store the second number.

[0149] Optionally, referring to Figure 5, the performance monitoring device 500 further includes a receiving unit 506 and a storage unit 507. The receiving unit 506 is used to receive a user's operation command, which carries a first count and a second count; the storage unit 507 is used to store the first count in a first storage module and, according to the operation command, store the second count in a second storage module.

[0150] Optionally, the processor's PMU includes a control module, a first storage module, and a second storage module. The storage unit 507 is used to: store a first number to the first storage module through the control module; and store a second number to the second storage module through the control module.

[0151] Optionally, the first and second storage modules include registers.

[0152] Optionally, referring to Figure 5, the performance monitoring device 500 also includes a reset unit 505. The reset unit 505 is used to: reset the count of the first counting module to the first count before the first counting module restarts counting; and reset the count of the second counting module to the second count before the second counting module restarts counting.

[0153] Optionally, referring to Figure 5, the performance monitoring device 500 also includes a configuration unit 508. The configuration unit 508 is used to configure the function of the first counting module to count the occurrence of the first event, and to configure the function of the second counting module to count the occurrence of the second event, before the first counting module and the second counting module begin counting.

[0154] Optionally, the first and second counting modules are located in the processor's PMU, and the first and second counting modules include registers.

[0155] Optionally, please continue to refer to Figure 5. The performance monitoring device 500 also includes a sampling unit 509 and a determination unit 510.

[0156] The sampling unit 509 is used to obtain a sampling record based on the context of the interrupt after the processor is triggered to generate an interrupt. The sampling record is used to record information about the code segment that the processor is executing when the interrupt is generated. The code segment is a code segment in the target program.

[0157] The determination unit 510 is used to determine the hot spot code in the target program based on the sampling record.

[0158] Optionally, the second event includes an instruction completion event; the first event includes any of the following: a clock cycle event; a lookup cache miss event; a branch prediction miss event; a lookup instruction cache miss event; a lookup data cache miss event; a lookup TLB miss event; a lookup instruction TLB miss event; or a lookup data TLB miss event.

[0159] Optionally, the performance monitoring device 500 includes the processor's PMU.

[0160] Optionally, the performance monitoring device 500 may also include an OS running on the processor.

[0161] The functional implementations of the monitoring unit 501 and the initialization unit 504 can be found in the relevant descriptions in S301. The functional implementation of the interrupt unit 502 can be found in the relevant descriptions in S302. The functional implementation of the trigger unit 503 can be found in the relevant descriptions in S303 and S304. The functional implementation of the reset unit 505 can be found in the relevant descriptions in S303 and S304. The functional implementations of the receiving unit 506 and the storage unit 507 can be found in the relevant descriptions in S301. The functional implementation of the configuration unit 508 can be found in the relevant descriptions in S305. The functional implementation of the sampling unit 509 can be found in the relevant descriptions in S306. The functional implementation of the determination unit 510 can be found in the relevant descriptions in S307.

[0162] In summary, the technical solution provided in this application involves a first counting module counting the occurrences of a first event during the execution of the target program by the processor, and a second counting module counting the occurrences of a second event during the same process. The ratio of the occurrences of the first event to the second event is used to characterize the performance metrics of the target program. When the first counting module overflows, the processor is interrupted. When neither the first nor the second counting module overflows, the processor is not interrupted, and both the first and second counting modules restart counting. Therefore, when the processor is interrupted, the probability that the code segment being executed by the processor is a code segment with poor performance metrics is relatively high. Hotspot code identified based on processor interrupts is also more likely to be a code segment with poor performance metrics, and hotspot code identified based on processor interrupts has greater optimization potential, which helps improve the optimization effect of hotspot code. Not triggering a processor interrupt when neither the first nor the second counting module overflows avoids the possibility of identifying code segments with good performance metrics as hotspot code due to an interruption occurring when the first counting module has not overflowed. Triggering a restart of counting by both the first and second counting modules when neither overflows facilitates the start of a new round of counting.

[0163] It should be understood that the performance monitoring device provided in this application embodiment can also be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The performance monitoring method provided in the above method embodiments can also be implemented in software. When the performance monitoring method provided in the above method embodiments is implemented in software, each functional unit in the performance monitoring device can also be a software unit.

[0164] Based on the same inventive concept, embodiments of this application provide a processor. This processor includes the performance monitoring device 500 provided in the embodiment shown in FIG. 5. Optionally, the processor is a CPU. For example, the processor is an ARM processor.

[0165] Based on the same inventive concept, embodiments of this application provide a computer device including the processor described in the above embodiments.

[0166] In an optional embodiment, the computer device includes a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program stored in the memory to implement all or part of the steps of the performance monitoring method provided in the embodiments shown in Figures 3 and 4.

[0167] As an example, please refer to Figure 6, which shows a schematic diagram of a computer device 600 provided in an embodiment of this application. The computer device 600 includes a processor 602, a memory 604, a communication interface 606, and a bus 608. The processor 602, memory 604, and communication interface 606 are communicatively connected via the bus 608. The connection method between the processor 602, memory 604, and communication interface 606 shown in Figure 6 is only an example; the processor 602, memory 604, and communication interface 606 can also be connected using connection methods other than the bus 608.

[0168] The memory 604 stores the computer program 6042, which may include instructions and data. The memory 604 can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), flash memory, optical storage, and registers.

[0169] In this embodiment, processor 602 can be a general-purpose processor, which can be a processor that performs specific steps and / or operations by reading and executing a computer program (e.g., computer program 6042) stored in a memory (e.g., memory 604). The general-purpose processor may use data stored in the memory (e.g., memory 604) during the execution of the above steps and / or operations. The stored computer program can be executed, for example, to implement the relevant functions of all or part of the functional units provided in the embodiment shown in FIG. 5. The general-purpose processor can be a CPU. In optional embodiments, processor 602 can also be a dedicated processor, which is a processor specifically designed to perform specific steps and / or operations. A dedicated processor can be a digital signal processor (DSP), ASIC, or FPGA, etc. Processor 602 can also be a combination of multiple processors, such as a multi-core processor. Processor 602 includes at least one circuit to execute all or part of the steps of the performance monitoring method provided in the above embodiments. In this embodiment, processor 602 includes a PMU as shown in FIG. 1 or FIG. 2, which is used to monitor performance during the execution of the program by the processor.

[0170] The communication interface 606 may include input / output (I / O) interfaces, physical interfaces, and logical interfaces for interconnecting devices within the computer device 600, as well as interfaces for interconnecting the computer device 600 with other devices (e.g., network devices). The physical interface may be a gigabit Ethernet (GE) interface, which can be used to interconnect the computer device 600 with other devices. The logical interface is an internal interface of the computer device 600, used for interconnecting devices within the computer device 600. The I / O interface can be a software interface or a hardware interface; for example, the I / O interface includes the perf interface, which can be used to allow users to input operation commands to the computer device 600. For example, a user inputs operation commands to the computer device 600 through the perf interface.

[0171] It is easy to understand that the communication interface 606 can be used for communication between the computer device 600 and other devices. For example, the communication interface 606 is used for sending and receiving information between the computer device 600 and other devices. The communication interface 606 can realize the relevant functions of the aforementioned receiving unit 506.

[0172] Bus 608 can be of any type, used to interconnect processor 602, memory 604, and communication interface 606. For example, bus 608 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. Bus 608 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 6, but this does not mean that there is only one bus or one type of bus.

[0173] The aforementioned devices in computer device 600 can be disposed on separate chips, or at least partially or entirely on the same chip. Whether to dispose of the devices independently on different chips or integrate them on one or more chips often depends on the needs of the product design. This application does not limit the specific implementation of the aforementioned devices.

[0174] The computer device 600 shown in Figure 6 is merely an example. In the implementation process, the computer device 600 may also include other components, which will not be listed one by one in this article.

[0175] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed (e.g., by a performance monitoring device, PMU, processor, etc.), implements all or part of the steps of the performance monitoring method provided in the embodiments shown in Figures 3 and 4.

[0176] Based on the same inventive concept, this application provides a computer program product, which includes a program or code. When the program or code is executed (e.g., by a performance monitoring device, PMU, processor, etc.), it implements all or part of the steps of the performance monitoring method provided in the embodiments shown in FIG3 and FIG4.

[0177] It should be noted that, in the embodiments of this application, "counting module overflow" refers to the counting number of times the counting module reaches the range that the counting module can count. For example, the range that the counting module can count is a preset number of times. The range that the counting module can count can be configured by the user. It can be understood that the aforementioned first count is the range that the first counting module can count, and the second count is the range that the second counting module can count.

[0178] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented entirely or partially as a computer program product, which 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 can be a general-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium, or a semiconductor medium (e.g., solid-state drive), etc.

[0179] It should be understood that the term "at least one" in this application refers to one or more, and "multiple" refers to two or more. In this application, unless otherwise stated, the symbol " / " generally means "or," for example, A / B can mean A or B. The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, for clarity, this application uses terms such as "first," "second," and "third" to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," and "third" do not limit the quantity or order of execution.

[0180] The different types of embodiments, such as the method embodiments and device embodiments provided in this application, can be referenced to each other. The order of operations in the method embodiments can be adjusted appropriately, and the operations can be added or removed in response to the situation. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be described in detail.

[0181] In the corresponding embodiments provided in this application, it should be understood that the disclosed devices, etc., can be implemented through other configurations. For example, the device embodiments described above are merely illustrative. For instance, the division of modules, units, etc., is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules, units, etc., can be combined or integrated into another system, or some features can be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed between them can be through some interfaces; the indirect coupling or communication connection between devices or modules, units, can be electrical or other forms. Modules and units described as separate components may or may not be physically separate, and components described as modules or units may or may not be physical modules or physical units. Some or all of the modules and units can be selected according to actual needs to achieve the purpose of this embodiment.

[0182] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any equivalent modifications or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / instructions> < / cycles> < / instructions> < / cycles> < / instructions> < / cycles> < / instructions> < / instructions> < / cycles> < / cycles> < / instructions> < / cycles>

Claims

1. A performance monitoring method, characterized by, The method comprises: monitoring whether the first counting module and the second counting module overflow after the first counting module and the second counting module start counting, wherein the first counting module is configured to count the number of occurrences of a first event during execution of a target program by a processor, the second counting module is configured to count the number of occurrences of a second event during execution of the target program by the processor, and the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to represent a performance index of the target program; triggering the processor to generate an interrupt when it is determined that the first counting module overflows; triggering the first counting module and the second counting module to restart counting when it is determined that the first counting module does not overflow and the second counting module overflows.

2. The method of claim 1, wherein, The first counting module overflows when the number of counts reaches a first number, the second counting module overflows when the number of counts reaches a second number, and the ratio of the first number to the second number is not less than a preset ratio.

3. The method of claim 2, wherein, The first counting module is configured to count the number of occurrences of the first event by means of countdown counting, and the second counting module is configured to count the number of occurrences of the second event by means of countdown counting. The method further comprises: initializing the number of counts of the first counting module to the first number before the first counting module starts counting; initializing the number of counts of the second counting module to the second number before the second counting module starts counting.

4. The method of claim 3, wherein, After triggering the processor to generate an interrupt, the method further comprises: resetting the number of counts of the first counting module to the first number; resetting the number of counts of the second counting module to the second number; triggering the first counting module and the second counting module to restart counting.

5. The method of claim 3, wherein: the initialization of the number of counts of the first counting module to the first number comprises loading the first number from a first storage module to the first counting module, the first storage module being configured to store the first number; the initialization of the number of counts of the second counting module to the second number comprises loading the second number from a second storage module to the second counting module, the second storage module being configured to store the second number.

6. The method of claim 4, wherein: the resetting of the number of counts of the first counting module to the first number comprises reloading the first number from a first storage module to the first counting module, the first storage module being configured to store the first number; the resetting of the number of counts of the second counting module to the second number comprises reloading the second number from a second storage module to the second counting module, the second storage module being configured to store the second number.

7. The method according to claim 5 or 6, characterized in that, The method further comprises: receiving an operation command of a user, the operation command carrying the first number and the second number; storing the first number to the first storage module according to the operation command. According to the operation command, the second number of times is stored to the second storage module.

8. The method of claim 7, wherein, The performance monitoring unit (PMU) of the processor comprises a control module, the first storage module and the second storage module, The storing of the first number of times to the first storage module comprises storing the first number of times to the first storage module by the control module. The storing of the second number of times to the second storage module comprises storing the second number of times to the second storage module by the control module.

9. The method of claim 8, wherein, The first storage module and the second storage module comprise registers.

10. The method according to any one of claims 3 to 9, characterized in that, The method further comprises: Before the first counting module restarts counting, resetting the counting number of the first counting module to the first number of times; Before the second counting module restarts counting, resetting the counting number of the second counting module to the second number of times.

11. The method according to any one of claims 1 to 10, characterized in that, Before the first counting module and the second counting module start counting, the method further comprises: configuring the function of the first counting module to count the number of occurrences of the first event; configuring the function of the second counting module to count the number of occurrences of the second event.

12. The method according to any one of claims 1 to 11, characterized in that, The first counting module and the second counting module are in the performance monitoring unit (PMU) of the processor, and the first counting module and the second counting module comprise registers.

13. The method according to any one of claims 1 to 12, characterized in that, After triggering the processor to generate an interrupt, the method further comprises: According to the context of the interrupt, a sampling record is obtained, the sampling record is used to record the information of a code segment being executed when the processor generates the interrupt, and the code segment is a code segment in the target program; According to the sampling record, a hot code in the target program is determined.

14. The method according to any one of claims 1 to 13, characterized in that, The second event comprises an instruction completion event; The first event comprises any one of the following: a clock cycle event; a cache miss event; a branch prediction miss event; a lookup instruction cache miss event; a lookup data cache miss event; 15. A performance monitoring device, characterized by a lookup translation lookaside buffer (TLB) miss event; a lookup instruction TLB miss event; and a lookup data TLB miss event. The performance monitoring device comprises: a monitoring unit, configured to monitor whether the first counting module and the second counting module overflow after the first counting module and the second counting module start counting, wherein the first counting module is configured to count the number of occurrences of a first event in the process that a processor executes a target program, the second counting module is configured to count the number of occurrences of a second event in the process that the processor executes the target program, and the ratio of the number of occurrences of the first event to the number of occurrences of the second event is used to represent a performance indicator of the target program; an interrupt unit, configured to trigger the processor to generate an interrupt when it is determined that the first counting module overflows; a triggering unit, configured to trigger the first counting module and the second counting module to restart counting when it is determined that the first counting module does not overflow and the second counting module overflows.

16. The performance monitoring apparatus of claim 15, wherein, The first counting module overflows when the counting number reaches a first number, and the second counting module overflows when the counting number reaches a second number, and the ratio of the first number to the second number is not less than a preset ratio.

17. The performance monitoring apparatus of claim 16, wherein, The first counting module is configured to count the number of occurrences of the first event by means of counting in reverse, and the second counting module is configured to count the number of occurrences of the second event by means of counting in reverse, The performance monitoring device further comprises an initialization unit configured to: initialize the counting number of the first counting module to the first number before the first counting module starts counting; initialize the counting number of the second counting module to the second number before the second counting module starts counting.

18. The performance monitoring apparatus of claim 17, wherein, The performance monitoring device further comprises: a reset unit configured to reset the counting number of the first counting module to the first number and reset the counting number of the second counting module to the second number after triggering the processor to generate an interrupt; The triggering unit is further configured to trigger the first counting module and the second counting module to start counting again after triggering the processor to generate an interrupt.

19. The performance monitoring apparatus of claim 17, wherein, The initialization unit is configured to: load the first number from a first storage module to the first counting module, and the first storage module is configured to store the first number; load the second number from a second storage module to the second counting module, and the second storage module is configured to store the second number.

20. The performance monitoring apparatus of claim 18, wherein, The reset unit is configured to: re-load the first number from a first storage module to the first counting module, and the first storage module is configured to store the first number; re-load the second number from a second storage module to the second counting module, and the second storage module is configured to store the second number.

21. The performance monitoring apparatus of claim 19 or 20, wherein, The performance monitoring device further comprises: a receiving unit configured to receive an operation command of a user, and the operation command carries the first number and the second number; a storage unit configured to store the first number to the first storage module according to the operation command, and store the second number to the second storage module according to the operation command.

22. The performance monitoring apparatus of claim 21, wherein, The performance monitoring unit PMU of the processor comprises a control module, the first storage module and the second storage module, and the storage unit is configured to: store the first number to the first storage module by means of the control module; store the second number to the second storage module by means of the control module.

23. The performance monitoring apparatus of claim 22, wherein, The first storage module and the second storage module comprise registers.

24. The performance monitoring apparatus of any of claims 17 to 23, wherein, The performance monitoring device further comprises: a reset unit configured to: reset the counting number of the first counting module to the first number before the first counting module starts counting again; reset the counting number of the second counting module to the second number before the second counting module starts counting again.

25. The performance monitoring apparatus of any of claims 15 to 24, wherein, The performance monitoring device further comprises: The configuration unit is configured to configure the first counting module to count the number of occurrences of the first event and configure the second counting module to count the number of occurrences of the second event before the first counting module and the second counting module start counting.

26. The performance monitoring apparatus of any of claims 15 to 25, wherein, The first counting module and the second counting module are included in a performance monitoring unit (PMU) of the processor.

27. The performance monitoring apparatus of any of claims 25 to 26, wherein, The performance monitoring device further comprises: The sampling unit is configured to obtain a sampling record according to a context of the interrupt after the interrupt is triggered, the sampling record being used to record information of a code segment being executed when the processor generates the interrupt, the code segment being a code segment in the target program. The determining unit is configured to determine a hot code in the target program according to the sampling record.

28. The performance monitoring apparatus of any of claims 25 to 27, wherein, The second event comprises an instruction completion event. The first event comprises any one of the following: a clock cycle event; a cache miss event; a branch prediction miss event; a lookup instruction cache miss event; a lookup data cache miss event; a lookup translation lookaside buffer (TLB) miss event; a lookup instruction TLB miss event; and a lookup data TLB miss event.

29. The performance monitoring device according to any one of claims 25 to 28, wherein: The performance monitoring device comprises a performance monitoring unit (PMU) of the processor.

30. The performance monitoring device according to claim 29, wherein: The performance monitoring device further comprises an operating system (OS) running on the processor. The computer program product comprises a program or code which, when executed, implements the method according to any one of claims 1 to 14. The computer program product comprises a program or code which, when executed, implements the method according to any one of claims 1 to 14. ​ ​ ​ 31. A processor, comprising: ​ 32. A computer device, comprising: ​ 33. A computer-readable storage medium, characterized in that, ​ 34. A computer program product, characterised in that, ​

Images