Performance analysis method based on RISC-V architecture

Abstract

The invention provides a multi-level performance analysis and optimization method based on an RISC-V framework, and aims to position and optimize performance bottlenecks in application programs through efficient performance data acquisition and analysis means. The method comprises the following steps: firstly, sampling and monitoring all application programs by utilizing an eBPF, capturing applications or processes with abnormal performance, then deeply analyzing the abnormal applications by utilizing a perf tool, and obtaining performance indexes such as function call, instruction number, CPU period and the like. A hot function generated by perf is analyzed, a specific performance counter of an RISC-V architecture is further used, data of the performance counter is read from a user mode, the performance data in the function execution process are accurately monitored in combination with the uprobe technology, and the performance bottleneck is deeply analyzed and positioned. Finally, the performance problem is solved by means of code optimization, system architecture adjustment and the like, and the performance is continuously optimized in multiple iterations. According to the scheme, global performance monitoring can be converted into accurate function level analysis, dependence on a kernel module is reduced, the flexibility and accuracy of performance analysis are improved, and the method has wide application value and is particularly suitable for performance adjustment and optimization in the fields of high-performance calculation, embedded systems, cloud services and the like.

Description

Technical Field

[0001] The present invention relates to hierarchical analysis of resources consumed by applications of RISC-V architecture, and belongs to the field of performance analysis and optimization. Background Art

[0002] In modern computing systems, performance optimization is one of the key tasks, especially in embedded systems, data centers, and high-performance computing (HPC) applications that require efficient execution. With the development and widespread application of the RISC-V open source instruction set architecture, there is a need to deeply analyze its performance bottlenecks to ensure that applications can run efficiently on RISC-V systems. Current performance analysis involves multiple levels and multiple tools. For example, you can use the Trace tool to track the system calls of the application to understand the interaction between the application and the operating system, or use the performance profiling tool Perf built into the Linux kernel source tree to obtain PMU, tracepoint, and special counter information in the kernel for performance statistics. By generating a flame graph, you can visualize the function call path and hot functions of the program, helping developers intuitively understand the performance bottlenecks of the program.

[0003] However, existing tools (such as perf and BPF) do not fully support RISC-V. For example, eBPF support on the RISC-V platform is still under development and cannot meet the needs of complex event tracking, statistics, and filtering. The functions of perf on RISC-V are not as rich as those on x86, such as the lack of support for complex events and detailed call stack information. Therefore, developers can only perform basic performance analysis and find it difficult to dig deep into performance issues. Summary of the invention

[0004] Purpose of the invention: The purpose of the present invention is to provide an efficient performance analysis method based on the RISC-V architecture, which aims to accurately identify and optimize performance bottlenecks in applications through multi-level performance monitoring and analysis. The method combines eBPF global sampling monitoring, function-level analysis of the perf tool, hardware performance counters and uprobe probes of the RISC-V architecture to achieve accurate performance diagnosis from the system level to the function level. Real-time performance monitoring of all applications is performed at the system level through eBPF, processes with abnormal performance are screened out, and these processes are analyzed in fine-grained detail using the perf tool to further locate hotspot functions. After locating a specific hotspot function, the present invention uses the hardware performance counters of the RISC-V architecture to directly read performance data in user mode, and combines uprobe probes to accurately monitor performance indicators during the execution of hotspot functions. Through this series of steps, developers can accurately identify performance bottlenecks in the code, provide optimization suggestions based on the analysis results, and finally improve system performance through continuous iterative optimization. This method does not require kernel module support and is performed entirely in user mode. It has the characteristics of low overhead, non-intrusiveness, and easy integration. It can help developers identify specific performance bottlenecks and optimization directions for applications on the RISC-V architecture and optimize application performance on RISC-V.

[0005] Technical solution:

[0006] A performance analysis method based on RISC-V architecture, including three parts: performance capture and analysis step instructions, application analysis scripts, and data processing scripts.

[0007] The performance capture and analysis step description includes four parts: eBPF sampling, hotspot function location, hotspot function analysis, and script processing data description. These four parts constitute a complete performance analysis process.

[0008] The main purpose of the application analysis script is to screen the target application, obtain the hot functions of the target application, and analyze the register information changes generated by the hot functions during execution. The main application performance indicators obtained are: system calls, CPU occupancy, memory access; the main function execution indicators obtained are: number of function calls, function execution time, number of CPU cycles, number of instructions. The main CSR register events obtained are: cyclecounter, instructions-retiredcounter, instructionscounter cyclecounter, ConditionalBranchCounter, ConditionalBranchMispredictCounter, IFUBranchTargetMispredCounter, IFUBranchTargetInstructionCounter, and the obtained information is passed to the data processing script.

[0009] The data processing script described above mainly constructs a top-down performance analysis method, which is layered according to the status of micro-operations (uOps) on the CPU pipeline. The first layer is mainly divided into three parts, namely:

[0010] Frontend (frontend_bound) and backend (backend_bound): The front end is responsible for taking the program code represented by the architecture instructions and decoding them into one or more low-level hardware operations called micro-operations (uOps). These uOps are passed to the back end through allocation, and the back end is responsible for monitoring when the data operands of the uOps are available and executing the uOps in the available execution units;

[0011] Retired: The completion of uOps execution is called retirement, and the results of uOps are committed to the storage medium (CPU registers or written back to memory);

[0012] Bad predictions (bad_speculation): Normally, most uOps make it completely through the pipeline and finish retirement, but sometimes before retirement, some uOps fetched in the branch prefetch stage may be canceled.

[0013] The data passed by the kernel module is calculated through a predetermined mathematical formula. The output results include the normal execution ratio (retired), the front-end bottleneck ratio and the back-end bottleneck ratio (frontend_bound and backend_bound), and the error prediction ratio (bad_speculation), which are defined as: 1 = backend_bound + retired + frontend_bound and backend_bound

[0014] The calculation formulas for each part are:

[0015]

[0016] frontend_boundand backend_bound=1-(backend_bound+retired)

[0017] The beneficial effect of the present invention is that, in combination with eBPF, perf, RISC-V hardware counters and uprobe, the present invention can perform refined analysis of applications from multiple dimensions from global to local, from software to hardware. All performance analyses can be performed in user mode without modifying the kernel or writing kernel modules, thus avoiding system interference. The hardware performance counters provided by the RISC-V architecture can accurately monitor performance bottlenecks, avoiding errors and inaccuracies in traditional methods. Thus, fine-grained analysis of the hot functions of the application can be performed, increasing the accuracy of the application performance analysis, while facilitating the identification of specific performance bottlenecks within the function, capturing the different overheads of the function, and further analyzing the bottleneck, facilitating subsequent optimization, thereby improving the overall performance of the code. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A workflow diagram of a performance analysis method based on RISC-V architecture of the present invention; DETAILED DESCRIPTION

[0019] The present invention provides a performance analysis method based on RISC-V architecture, and the research object is the resource consumption of application programs at runtime, such as Figure 1 As shown, the entire process of finding the internal performance bottleneck of a function according to the present invention is divided into four steps:

[0020] Step s101: The purpose is to obtain hot applications, perform performance sampling on the entire system through eBPF, monitor the running status of all applications in real time, including CPU usage, memory access, system calls, etc., and automatically identify high-load processes that may have performance bottlenecks. By setting thresholds, abnormal processes that need further analysis are screened out.

[0021] Step s102: locate the target hotspot function and use the perf tool to perform in-depth performance analysis on the screened out performance abnormal processes. The perf tool collects detailed performance data and generates visual reports such as flame graphs and call stacks to help developers accurately locate the hotspot functions that take a long time, providing a basis for further performance optimization.

[0022] Step s103: The purpose is to collect data of hot functions. RISC-V allows to directly read performance counter data in user mode. Combined with uprobe probes, hooks can be set at the entry and return of hot functions to collect performance data in real time during function execution, including key indicators such as instruction cycles and instruction retirement rate. In this way, the hot function can be deeply analyzed and performance bottlenecks can be accurately located.

[0023] Step s104: The purpose is to fill the acquired value of the target register or target PMU event into a table, and the data processing script is used to read the information. The script needs to write mathematical processing formulas involving the top-down microarchitecture analysis method to calculate the acquired register value. The calculated value is expressed as a percentage, reflecting the location of the resources mainly consumed by the target function, thereby locking the bottleneck of the target code block and providing a basis for further optimization.

Claims

1. A performance analysis method based on RISC-V architecture, including a performance capture and analysis step manual, an application analysis script, and a data processing script, characterized in that: Use eBPF to perform global performance monitoring of all processes in the system, use the perf tool to perform performance analysis on high-load processes, locate performance hotspot functions, and use RISC-V hardware performance counters and uprobe probes to finely analyze the execution process of hotspot functions.

2. The performance analysis method according to claim 1, characterized in that: The performance capture and analysis step description includes four parts: eBPF sampling, hotspot function location, hotspot function analysis, and script processing data description. These four parts constitute a complete performance analysis process.

3. The performance analysis method according to claim 1, characterized in that: The application analysis script described above: obtains the hot functions of the target application and analyzes the register information changes generated during the execution of the hot functions. The main application performance indicators obtained are: system calls, CPU occupancy, and memory access; the main function execution indicators obtained are: number of function calls, function execution time, number of CPU cycles, and number of instructions. The main CSR register events obtained are: cyclecounter, instructions-retiredcounter, instructionscounter cyclecounter, ConditionalBranchCounter, ConditionalBranchMispredictCounter, IFUBranchTargetMispredCounter, and IFUBranchTargetInstructionCounter. The obtained information is passed to the data processing script.

4. The performance analysis method according to claim 1, characterized in that: The data processing script described above constructs a top-down performance analysis method, which is layered according to the status of micro-operations (uOps) on the CPU pipeline. The first layer is mainly divided into three parts, namely: Frontend (frontend_bound) and backend (backend_bound): The front end is responsible for taking the program code represented by the architecture instructions and decoding them into one or more low-level hardware operations called micro-operations (uOps). These uOps are passed to the back end through allocation, and the back end is responsible for monitoring when the data operands of the uOps are available and executing the uOps in the available execution units; Retired: The completion of uOps execution is called retirement, and the results of uOps are committed to the storage medium (CPU registers or written back to memory); Bad predictions (bad_speculation): Normally, most uOps make it completely through the pipeline and finish retirement, but sometimes before retirement, some uOps fetched in the branch prefetch stage may be canceled. The data passed by the kernel module is calculated through a predetermined mathematical formula, and the output results include three parts: normal execution ratio (retired), front-end bottleneck ratio and back-end bottleneck ratio (frontend_bound and backend_bound), and error prediction ratio (bad_speculation), which are defined as: 1=backend_bound+retired+frontend_boundand backend_bound. It is characterized in that the data processing script calculates the obtained register value, and the calculated value is expressed in the form of percentage, reflecting the location of the resources mainly consumed by the target function, thereby locking the bottleneck of the target code block.

Images