Operating system kernel performance data collection method, storage medium and terminal device

Abstract

The present application relates to operating system kernel performance data acquisition method, storage medium and terminal equipment, through the plug-in callback mechanism and the whole process data processing design of the simulator level, three major core technical problems of no hardware dependence, fine-grained path analysis, cross-architecture compatibility are solved, core technical effects at least include: get rid of physical hardware dependence, realize high-precision data acquisition in the scene without PMU; Refine the path observation granularity, with dynamic insertion of fine-grained analysis capability; Realize cross-architecture decoupling, build a unified performance analysis workflow; Non-intrusive acquisition, guarantee the stability of kernel running; Whole process automation closed loop, improve analysis efficiency. A complete data flow closed loop from "QEMU virtual machine insertion" to "compiler optimization" is constructed, the fine-grained dynamic execution information captured by QEMU is seamlessly connected to mature compiler optimization tool chain such as AutoFDO, and the automation integration of data acquisition and optimization is realized.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method for acquiring operating system kernel performance data, a storage medium, and a terminal device. Background Technology

[0002] With the rapid iteration of computer technology, the complexity of operating system kernels and user-space programs continues to increase. The widespread adoption of embedded systems and cross-architecture computing scenarios, in particular, places higher demands on the accuracy, compatibility, and flexibility of performance analysis tools. As a core means of system optimization and bottleneck localization, performance analysis directly determines the depth of a developer's understanding of the system's runtime behavior, thus affecting product stability and operational efficiency. Currently, performance analysis of operating system kernels and user-space programs has developed into various technical approaches. These solutions, based on different implementation principles, possess unique advantages in specific scenarios but also have significant limitations, making it difficult to meet the comprehensive analysis needs of complex cross-platform scenarios.

[0003] Existing performance analysis techniques can be mainly divided into the following four categories based on differences in implementation methods, each exhibiting distinct characteristics in terms of applicable scenarios and analytical capabilities: 1. Analysis tools based on Hardware Performance Monitoring Unit (PMU): These tools are typically represented by the perf tool integrated into the Linux kernel. Their core principle is to read the CPU's built-in hardware performance counters to perform high-precision sampling and statistics of low-level hardware events. Hardware performance counters can directly capture raw hardware-level events such as instruction cycles, cache misses, branch prediction errors, and bus occupancy rates. They have the advantages of high sampling accuracy and minimal interference with the target program's execution, and are widely used for performance bottleneck analysis on hardware platforms with complete PMU functionality, such as servers and PCs. 2. Kernel static instrumentation-based tracing tools: Represented by the Linux kernel's native ftrace and kprobe, these tools achieve observation of kernel control flow and timing characteristics by pre-setting static tracing points in critical kernel paths (such as function calls, interrupt handling, scheduler execution, etc.). Its core advantage lies in its ability to penetrate deep into the kernel space without relying on additional hardware. It is primarily used for scenarios such as function call tracing, interrupt latency statistics, and kernel scheduling behavior analysis, making it a commonly used tool for basic kernel-level performance troubleshooting. 3. User-space dynamic binary instrumentation (DBI) frameworks: Frameworks such as DynamoRIO and Pin are typical representatives of this technology. Their core logic is to dynamically rewrite and instrument the binary code of the target program at runtime in user space. Analysis logic can be injected according to custom requirements, enabling instruction-level tracing, code coverage statistics, and customized performance metric collection for user-space programs. This type of solution offers high flexibility and can adapt to diverse user-space program analysis needs, but its scope is limited to user space and cannot directly penetrate into the kernel space for effective analysis. 4. Commercial integrated analysis platforms: Represented by Intel VTune Profiler and ARM Development Studio, these platforms integrate hardware sampling, software instrumentation, data analysis, and visualization functions, providing a graphical user interface and automated analysis workflows. They can provide comprehensive performance analysis capabilities for specific vendor hardware platforms. However, its core drawback lies in its deep binding to specific hardware architectures. For example, Intel VTune Profiler is mainly adapted to the Intel x86 architecture, which cannot be used across manufacturers or architectures. Moreover, the commercial licensing cost is high, making it difficult to popularize in embedded, open source development and other scenarios.

[0004] While the aforementioned existing technologies have application value in their respective specific scenarios, they expose many unavoidable core defects when dealing with complex systems (especially embedded systems, cross-architecture computing, and deep kernel-level analysis scenarios). These defects directly limit the depth, breadth, and engineering feasibility of performance analysis, failing to meet the demands of modern system development for generalized, fine-grained performance analysis. Examples include: 1. Strong hardware dependency and lack of cross-architecture adaptability: Mainstream high-precision performance analysis tools (such as perf) heavily rely on the CPU's built-in hardware performance monitoring unit (PMU). However, in embedded systems and emerging architectures, PMU functionality is generally missing or incompletely configured. For example, some low-end ARMv8 architecture chips and early RISC-V architecture chips did not integrate a complete PMU module to control cost and power consumption; even for chips equipped with PMUs, the event definitions and counting precision differ between manufacturers, resulting in extremely poor tool compatibility. This makes it impossible for developers to use hardware-dependent tools in these scenarios, or they can only obtain incomplete performance data, making it impossible to carry out effective performance optimization work. Meanwhile, the binding relationship between commercial platforms and specific vendor hardware further exacerbates the barriers to cross-architecture analysis, making it impossible to form a unified performance analysis workflow. 2. Insufficient kernel-level observability, making fine-grained analysis difficult: In real physical hardware environments, dynamic, fine-grained instrumentation analysis of the operating system kernel carries extremely high risks. Arbitrarily modifying kernel code or injecting analysis logic can easily disrupt system stability and even lead to kernel crashes. While static instrumentation tools (such as ftrace) can mitigate stability risks, they can only collect data through preset trace points, limiting the observation granularity to function or module levels, and failing to achieve fine-grained tracing at the instruction or branch levels. For performance bottlenecks in core paths such as the kernel scheduler, interrupt handling, memory management, and I / O scheduling, only limited static data or external observations can be used to infer the root cause, making it difficult to accurately locate key issues such as instruction execution latency, branch jump efficiency, and code block execution frequency, greatly increasing the difficulty of kernel performance optimization. 3. Poor flexibility and scalability, and insufficient adaptability: The fixed event types of hardware performance counters prevent them from supporting the collection of custom performance metrics. When developers need to track new performance issues (such as the execution efficiency of specific algorithms or the running characteristics of custom kernel modules), hardware-dependent tools are completely unsuitable. Furthermore, the deployment and configuration complexity of existing tools is high, often requiring the compilation of specific kernel modules, loading of dedicated drivers, or modification of kernel configurations. In resource-constrained scenarios such as embedded systems, deployment costs are extremely high and compatibility issues are easily introduced. In addition, the separation between the user-space DBI framework and kernel-space analysis tools prevents the formation of a system-wide "kernel-user space" integrated analysis capability, making it difficult to locate performance issues caused by cross-space interactions (such as system calls and interrupt responses).

[0005] With the rise of open-source architectures such as RISC-V, the widespread application of embedded systems, and the growing demand for cross-architecture computing, the shortcomings of existing performance analysis technologies have become increasingly apparent. There is an urgent need to provide a general performance analysis solution that has cross-architecture compatibility, full-system (kernel-mode + user-mode) analysis capabilities, fine-grained observation accuracy, and no hardware dependency. Summary of the Invention

[0006] To solve at least one of the above-mentioned technical problems, the present invention provides a method for collecting operating system kernel performance data, comprising: Based on the QEMU plugin API, initialize a dedicated performance analysis plugin; load the dedicated performance analysis plugin when QEMU starts, and register code block translation callback functions, code block execution callback functions, and simulator exit callback functions; When the QEMU dynamic translator translates the kernel code of the target architecture into the host machine's native code, the code block translation callback function is triggered to obtain basic information about the kernel code; When the translated host machine native code is executed in the virtual machine, the code block execution callback function is triggered. Based on the basic information, the branch jump path and continuous execution path of the kernel code are captured in real time, and the branch jump path and continuous execution path are aggregated and statistically analyzed online to obtain path statistics results. After the execution of the host machine's local code is completed, the emulator's exit callback function is called to construct and return a structured performance configuration file based on the path statistics results; wherein, the structured performance configuration file is used to characterize the dynamic behavior of the kernel code under specific loads.

[0007] Furthermore, the basic information includes: the starting virtual address of each code block, the ending virtual address of each code block, and the machine code of the last instruction of each code block; The steps for capturing the branch jump paths and continuous execution paths of the kernel code in real time based on the aforementioned basic information include: The steps for recording branch jump paths are as follows: Extract the ending virtual address of the previous code block saved during the last execution from the basic information, and combine it with the starting virtual address of the current code block to form a branch jump pair, which is then inserted into the LBR buffer. The steps for recording a continuous execution path are as follows: extract the start and end virtual addresses of the current code block from the basic information to form a continuous execution interval, and insert it into an LRR buffer; State Update: After recording the branch jump path and the continuous execution path, based on the basic information, the end virtual address of the current code block and the machine code of the last instruction are updated to the basic information of the previous code block and stored in the preset state cache to prepare for the recording of the branch jump path when the next execution callback is triggered.

[0008] Furthermore, the initialization of the dedicated performance analysis plugin includes initializing the sampling rate threshold; The basic information includes the number of instructions in the code block; In the step of capturing the branch jump path and continuous execution path of the kernel code in real time based on the basic information, an instruction counting-based sampling mechanism is adopted, including: An instruction counter is maintained inside the callback function of the code block execution. Each time a code block is executed, the number of instructions contained in the code block is added to the instruction counter. When the value of the instruction counter reaches a preset sampling rate threshold, a sampling event is triggered, and the instruction counter is cleared after sampling.

[0009] Furthermore, the initialization dedicated performance analysis plugin also includes an initialization virtual load detection module, a virtual high load threshold, a virtual low load threshold, a threshold adjustment step size, and a number of consecutive trigger detections; The sampling rate threshold adopts a dynamic threshold adjustment mechanism, including: Virtual load monitoring: The virtual load monitoring module is initialized to count the instruction execution density of the target operating system kernel in the QEMU simulator at preset time intervals. The instruction execution density is the ratio of the total number of times the kernel code block is executed to the collection time during the collection period. Threshold adjustment: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections and is higher than the virtual high load threshold, the current sampling rate threshold is adjusted upward according to the preset threshold adjustment step size. After the adjustment, the sampling rate threshold does not exceed the upward adjustment ratio of the initial sampling rate threshold. Threshold reduction: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections and is lower than the virtual low load threshold, the current sampling rate threshold is reduced according to the preset threshold adjustment step size. After the reduction, the sampling rate threshold is not lower than the reduction ratio of the initial sampling rate threshold. Threshold locking: When the target operating system kernel is detected to be in a critical process execution phase, the current sampling rate threshold is locked, dynamic adjustment is paused, and the critical process execution is completed.

[0010] Furthermore, the path statistics results include: a secondary hash index table of branch jump paths and a secondary hash index table of continuous execution paths; The step of online aggregation and statistics of the branch jump path and the continuous execution path to obtain path statistics results includes: The callback function executed by the code block traverses the branch jump paths accumulated in the LBR buffer and constructs a two-level hash index table of the branch jump paths; in the two-level hash index table of the branch jump paths, the first-level key is the first m bits of the starting virtual address of the branch jump path, the second-level key is the last 64-m bits of the starting virtual address of the branch jump path, and the value is the ending virtual address of the branch jump path and the number of times the branch jump path has been executed; The callback function executed by the code block traverses the consecutive execution paths accumulated in the LRR buffer and constructs a two-level hash index table for the consecutive execution paths. In the two-level hash index table for the consecutive execution paths, the first-level key is the first m bits of the starting virtual address of the consecutive execution path, the second-level key is the last 64-m bits of the starting virtual address of the consecutive execution path, and the value is the ending virtual address of the consecutive execution path and the number of times the consecutive execution path has been executed.

[0011] Furthermore, the steps of constructing the secondary hash index table for branch jump paths and the steps of constructing the secondary hash index table for continuous execution paths include: Hash Calculation and Location: Calculate the first difference between the starting virtual address and the base address of the branch jump path. Extract the high-order part of the first difference through bit shifting operations, and use it as the first-level key of the secondary hash index table of the branch jump path to locate the bucket. Extract the low-order part of the first difference through bitmasking operations, and use it as the second-level key of the secondary hash index table of the branch jump path to locate the specific entry within the bucket. Calculate the second difference between the starting virtual address and the base address of the continuous execution path. Extract the high-order part of the second difference through bit shifting operations, and use it as the first-level key of the secondary hash index table of the continuous execution path to locate the bucket. Extract the low-order part of the second difference through bitmasking operations, and use it as the second-level key of the secondary hash index table of the continuous execution path to locate the specific entry within the bucket. Record insertion and update: Traverse the stored records within the located entry. If the target address already exists, increment the corresponding count value by one. If the target address does not exist, add the new path record and the initial count value of 1 to the entry storage space. Batch write strategy: An operation counter is maintained in the secondary hash index table. The operation counter is incremented by one each time a record is inserted or updated. When the operation counter exceeds the preset write threshold, a batch persistence operation is triggered, which writes all path records in the secondary hash index table to the persistent file at once. After completion, the current path records in the secondary hash index table are cleared and the operation counter is reset.

[0012] Furthermore, the steps of constructing the secondary hash index table for branch jump paths and the steps of constructing the secondary hash index table for continuous execution paths further include: First-level expansion: When locating a bucket using the first-level key, if the calculated bucket index exceeds the capacity range of the current bucket array, the capacity of the bucket array is doubled, and the space of the newly added bucket is initialized to ensure normal subsequent location. Second-level expansion: After locating a specific entry in the bucket using the second-level key, if the number of path records already stored in the entry reaches half of the current storage space capacity, the storage space capacity of the entry will be doubled. After the expansion is completed, the storage location of the original records will be retained, and only the newly added storage space will be initialized. Post-expansion compatibility: After the tiered expansion is completed, the execution rules of the original hash calculation and positioning, record insertion and update, and batch write strategies remain unchanged.

[0013] Furthermore, the step of constructing and returning a structured performance configuration file based on the path statistics results includes: Flush all data that has not yet been written to memory and write it to the structured performance configuration file; Output a statistical summary of this performance analysis session; Release all dynamically allocated memory to ensure there are no memory leaks.

[0014] On the other hand, the present invention also provides a computer storage medium storing executable program code; the executable program code is used to execute any of the above-mentioned operating system kernel performance data acquisition methods.

[0015] On the other hand, the present invention also provides a terminal device, including a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute any of the above-mentioned operating system kernel performance data acquisition methods.

[0016] This invention relates to a method for acquiring operating system kernel performance data, a storage medium, and a terminal device. Through a pluggable callback mechanism and a full-process data processing design at the simulator level, it specifically addresses three core technical issues: no hardware dependency, fine-grained path analysis, and cross-architecture compatibility. The core technical effects include at least: (1) eliminating physical hardware dependency and achieving high-precision data acquisition in PMU-free scenarios; (2) refining the granularity of path observation and possessing dynamic instrumentation-style fine-grained analysis capabilities; (3) achieving cross-architecture decoupling and constructing a unified performance analysis workflow; (4) non-intrusive acquisition, ensuring kernel operational stability; and (5) a fully automated closed loop, improving analysis efficiency. A complete data flow closed loop from "QEMU virtual machine instrumentation" to "compiler optimization" is constructed. Through custom data formats and modified conversion tools, the fine-grained dynamic execution information captured by QEMU is successfully and seamlessly integrated into mature compiler optimization toolchains such as AutoFDO, achieving automated integration of data acquisition and optimization. Attached Figure Description

[0017] Figure 1 This is a flowchart of an embodiment of the operating system kernel performance data acquisition method of the present invention; Figure 2 This is a schematic diagram of an embodiment of the operating system kernel performance data acquisition method of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be noted that if the embodiments of the present invention involve directional indications, such as up, down, left, right, front, back, etc., these directional indications are only used to explain the relative positional relationships and movement of the components in a specific posture. If the specific posture changes, the directional indications will also change accordingly. Furthermore, if the embodiments of the present invention involve descriptions such as "first," "second," "S1," "S2," "step one," "step two," etc., these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance, or implicitly indicating the number of technical features indicated or the execution order of the method. Those skilled in the art will understand that anything that does not violate the inventive concept should be included within the scope of protection of the present invention.

[0020] like Figure 1-2As shown, the present invention provides a method for collecting operating system kernel performance data, including: S1: Based on the QEMU plugin API, initialize the dedicated performance analysis plugin; load the dedicated performance analysis plugin when QEMU starts, and register code block translation callback functions, code block execution callback functions, and simulator exit callback functions; S2: When QEMU's dynamic translator translates the kernel code of the target architecture into the host machine's native code, the code block translation callback function is triggered to obtain basic information about the kernel code; S3: When the translated host machine native code is executed in the virtual machine, the code block execution callback function is triggered. Based on basic information, the branch jump path and continuous execution path of the kernel code are captured in real time, and the branch jump path and continuous execution path are aggregated and statistically analyzed online to obtain path statistics results. S4: After the local code execution on the host machine ends, the emulator exit callback function is called to construct and return a structured performance configuration file based on the path statistics results; the structured performance configuration file is used to characterize the dynamic behavior of the kernel code under specific loads.

[0021] This embodiment presents an operating system kernel performance data acquisition method of the present invention. Through a pluggable callback mechanism and a full-process data processing design at the emulator level, it specifically addresses three core technical issues: no hardware dependency, fine-grained path analysis, and cross-architecture compatibility. The core technical effects include at least the following: (1) Get rid of physical hardware dependence and realize high-precision data acquisition in PMU-free scenarios: It does not rely on physical hardware performance monitoring unit (PMU) and completes kernel running data acquisition entirely based on the instruction translation and execution callback capabilities of QEMU simulator. It can be adapted to any architecture environment that supports instruction-level simulation, breaking through the dependence of traditional hardware-assisted acquisition schemes on specific hardware. In scenarios without hardware PMU support (such as architecture verification and virtualization test environment), it can still achieve high-precision capture of kernel performance data, filling the gap in kernel data acquisition in scenarios without hardware support.

[0022] (2) Refining the granularity of path observation and possessing dynamic instrumentation-based fine-grained analysis capabilities: By registering translation and execution dual callback functions at the QEMU simulator level, basic information is captured during the code block translation stage, and branch jump paths and continuous execution paths are accurately captured during the execution stage, realizing instruction-level path tracing for any code segment in the kernel and user-mode programs. Compared with the shortcomings of traditional kernel tracing tools, which are limited by the granularity of observation and cannot take into account both continuous and branch paths, this method achieves complete capture and online aggregation statistics of fine-grained path information through dynamic instrumentation, providing more accurate data support for kernel performance bottleneck location.

[0023] (3) Achieve cross-architecture decoupling and build a unified performance analysis workflow: Relying on the cross-architecture instruction translation capabilities of the QEMU simulator, the performance analysis framework is decoupled from the underlying CPU architecture. Developers can perform performance analysis on operating system kernels of different target architectures such as ARM64 and RISC-V on common host machines such as x86. There is no need to build dedicated hardware testing environments for different target architectures, eliminating hardware architecture barriers, reducing the cost of cross-architecture performance analysis, and improving the universality and efficiency of performance analysis work.

[0024] (4) Non-intrusive data collection, ensuring kernel stability: Data collection is based on the QEMU plugin callback mechanism throughout the process. It does not require modification of the target operating system kernel code or the injection of additional programs into the target kernel. It is a non-intrusive performance analysis method. It avoids interference with the kernel's native running state caused by intrusive data collection, ensures the stability of kernel operation during the collection process, and guarantees that the performance data can truly reflect the dynamic behavior characteristics of the kernel under specific loads.

[0025] (5) Full-process automated closed loop improves analysis efficiency: From plugin initialization, information capture during the translation stage, and path sampling during the execution stage, to the final performance configuration file construction and feedback, a full-process automated processing closed loop is formed. No manual intervention is required in the data collection and statistics process, and data redundancy is reduced through online aggregation statistics, and structured performance configuration files are quickly output, which greatly improves the efficiency and convenience of kernel performance analysis.

[0026] In summary, the operating system kernel performance data acquisition method of this invention constructs a complete data flow closed loop from "QEMU virtual machine instrumentation" to "compiler optimization", successfully and seamlessly integrates the fine-grained dynamic execution information captured by QEMU into mature compiler optimization toolchains such as AutoFDO, realizing the automated integration of data acquisition and optimization.

[0027] Specifically, in step S1: Based on the plugin development API provided by QEMU, the initialization development of a dedicated performance analysis plugin was completed. The plugin compilation environment was set up, and the core header file `qemu-plugin.h` was included, along with linking the `libqemu-plugin` plugin library. The basic logic and global resources for plugin performance data acquisition and processing were defined, enabling the plugin to interact with the QEMU simulator. When the QEMU simulator starts, the dynamic link library storage path for the dedicated performance analysis plugin was specified using the native `-plugin` command-line parameter of QEMU, completing the plugin loading and initialization, ensuring the plugin enters a running-ready state upon startup of the QEMU simulator. After the plugin is loaded, in the plugin entry initialization function, the registration interface provided by the QEMU plugin API was used to sequentially register the code block translation callback function, the code block execution callback function, and the simulator exit callback function. The custom code block translation processing logic, execution processing logic, and exit cleanup logic were bound to the QEMU simulator's code block translation event, code block execution event, and simulator exit event, respectively, ensuring that when the corresponding event is triggered during QEMU simulator operation, the plugin can automatically call the custom callback function to perform the relevant processing.

[0028] Specifically: When QEMU starts, it loads this performance analysis plugin via the `-plugin` parameter. The plugin parses the command-line parameters, such as the sampling interval (e.g., recording once every N executions), the data output file path, and the write threshold (e.g., writing to a file after accumulating 1000 records). Subsequently, the plugin registers three types of key callback functions with QEMU: a code block translation callback function, a code block execution callback function `tb_exec_callback`, and an emulator exit callback function.

[0029] More specifically, in step S2: When QEMU's TCG translates the target kernel code into host machine native code, it triggers the code block translation callback function registered by the plugin.

[0030] Preferably, the steps performed in the code block translation callback function include: (1): The code block translation callback function traverses the instructions in the translation block; during the traversal, it calls the interface used to obtain the virtual address of the instruction in the QEMU TCG plugin system, obtains the virtual address of each instruction, and stores it in the pre-built code block information structure; (2): Register a code block execution callback function for the code block and pass the pointer of the constructed code block information structure as a parameter.

[0031] More specifically, in step S3: The code block executes a callback function, records every branch jump event and continuous execution event of the kernel instruction, and captures the branch jump path and continuous execution path of the kernel code in real time during the operating system's workload. It uses an efficient data structure to aggregate and statistically analyze the path information online and record the execution frequency of each code segment and branch. Preferably, in one embodiment, the basic information includes: the starting virtual address of each code block, the ending virtual address of each code block, and the machine code of the last instruction of each code block; Based on basic information, the steps of capturing branch jump paths and continuous execution paths of kernel code in real time are implemented. This is achieved by maintaining software-simulated LBR (LastBranchRecord) and LRR (LastRangeRecord) buffers through code block execution callback functions. Specifically, this includes: The steps for recording branch jump paths are as follows: Extract the ending virtual address of the previous code block saved during the last execution from the basic information, and combine it with the starting virtual address of the current code block to form a branch jump pair. An example is a branch jump pair of "ending virtual address of the previous code block - starting virtual address of the current code block"; insert it into the LBR buffer; when the number of entries in the buffer reaches a certain amount, write it to disk, and then clear the LBR buffer. In this step, the branch jump pairs for each branch jump event are sequentially inserted into the loop's LBR buffer, forming a series of strings, thereby accurately capturing the control flow transfer between code blocks.

[0032] The steps for recording a continuous execution path are as follows: Extract the start and end virtual addresses of the current code block from the basic information to form a continuous execution interval, for example, a continuous execution interval in the format of "start virtual address of current code block - end virtual address of current code block"; insert into the LRR buffer; when the number of entries in the buffer reaches a certain amount, write to disk, and then clear the LRR buffer. In this step, the continuous execution interval is stored in the LRR buffer to record the execution trajectory within the code block; optionally, the start and end virtual addresses of the current code block can be extracted and combined with the execution timestamp of the code block to form a continuous execution interval with a time dimension, which is then stored in the LRR buffer.

[0033] State Update: After recording the branch jump path and continuous execution path, based on the basic information, update the end virtual address of the current code block and the machine code of the last instruction to the basic information of the previous code block, and store it in the preset state cache to prepare for the recording of the branch jump path when the next execution callback is triggered.

[0034] More preferably, in a preferred embodiment, step S1, initializing the dedicated performance analysis plugin includes initializing the sampling rate threshold; step S2, obtaining basic information about the kernel code block includes the number of instructions in the code block; step S3, employing a sampling mechanism based on instruction counting, includes: An instruction counter is maintained inside the callback function of the code block execution. Each time a code block is executed, the number of instructions contained in the code block is added to the instruction counter. When the value of the instruction counter reaches a preset sampling rate threshold, a sampling event is triggered, and the instruction counter is cleared after sampling.

[0035] In this embodiment, to avoid high-overhead data processing every time it is executed, the present invention also introduces an instruction counting sampling mechanism. Sampling is only performed when the instruction count reaches a preset sampling rate threshold. This combines "instruction count accumulation" with "threshold-triggered sampling", which is different from the "full collection" mode of traditional QEMU instrumentation. It can reduce performance overhead while ensuring data accuracy.

[0036] More preferably, in step S1, initializing the dedicated performance analysis plugin further includes initializing the virtual load detection module, virtual high load threshold, virtual low load threshold, threshold adjustment step size, and number of consecutive trigger detections; in step S3, the sampling rate threshold adopts a dynamic threshold adjustment mechanism, including: Virtual load monitoring: The initialized virtual load monitoring module counts the instruction execution density of the target operating system kernel in the QEMU simulator at preset time intervals (e.g., 100ms-500ms). The instruction execution density is the ratio of the total number of times the kernel code block is executed to the collection time during the collection period. Threshold adjustment: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections (e.g., 3 times) and is higher than the virtual high load threshold, the current sampling rate threshold is adjusted upward according to the preset threshold adjustment step size. After the adjustment, the sampling rate threshold does not exceed the upward adjustment ratio of the initial sampling rate threshold, thereby reducing the sampling frequency to reduce the instrumentation's impact on the QEMU simulator's execution performance. Threshold reduction: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections and is lower than the virtual low load threshold, the current sampling rate threshold is reduced according to the preset threshold adjustment step size. After the reduction, the sampling rate threshold is not lower than the reduction ratio of the initial sampling rate threshold, thereby increasing the sampling frequency to ensure the accuracy of performance data collection. Threshold locking: When the target operating system kernel is detected to be in a critical process execution phase, the current sampling rate threshold is locked, dynamic adjustment is paused, and the critical process execution is completed.

[0037] In this embodiment, the present invention also introduces a dynamic threshold adjustment mechanism, which realizes adaptive adjustment of the sampling rate threshold based on the virtual load perception in the QEMU simulator. Compared with the fixed sampling rate acquisition method, it realizes a dynamic balance between sampling accuracy and simulator execution performance, and adapts to the actual running load characteristics of the target operating system kernel. The core technical effects include at least: (1) Accurately sensing the real kernel load in the simulator and avoiding invalid adjustments: The instruction execution density of the kernel in the simulator is statistically analyzed by the virtual load monitoring module. It is completely based on the native acquisition capability of the QEMU instrumentation plugin. It does not need to access the host system interface, which meets the core requirement of "non-intrusiveness" of this application. At the same time, by continuously reaching the trigger condition of the set number of detections, the instantaneous fluctuation of kernel load is filtered out, and only continuous and stable load changes are responded to, ensuring that the threshold adjustment matches the real running state of the kernel and avoiding frequent changes in sampling frequency caused by instantaneous sudden load. (2) Adaptive adjustment of sampling frequency to achieve "high load to maintain performance and low load to improve accuracy": When the kernel is under high load (instruction execution density continuously exceeds the virtual high load threshold), the sampling rate threshold is increased by a set step size to reduce the sampling trigger frequency, reduce the overhead of instrumentation plugin callback calculation, data storage and aggregation statistics, avoid excessive occupation of QEMU simulator execution resources by instrumentation behavior, ensure the normal operation of the target operating system kernel under high load, and eliminate simulator stuttering and execution delay caused by sampling operation; When the kernel is under low load (instruction execution density continuously lower than the virtual low load threshold), the sampling rate threshold is decreased by a set step size to increase the sampling trigger frequency, increase the granularity of path data collection, fully capture the fine-grained execution characteristics of the kernel under low load, ensure the accuracy of performance data collection, and provide more comprehensive kernel dynamic behavior data for the construction of subsequent performance configuration files. (3) Threshold upper and lower limits to avoid scheme failure caused by extreme adjustments: By limiting the proportion of the sampling rate threshold to be adjusted up or down, such as the increase not exceeding twice the initial value and the decrease not less than 50% of the initial value, the range of threshold adjustment is rigidly constrained. This avoids the problem of missing data in the kernel critical path and incomplete characterization of execution features due to excessively increasing the threshold and excessively decreasing the threshold, which leads to excessively high sampling frequency and performance overhead of returning to fixed low threshold sampling. This ensures that dynamic adjustment is always within a reasonable range and guarantees the stability and effectiveness of the entire data acquisition scheme.(4) Locking the threshold of key processes to ensure the integrity of core path data collection: For key processes such as kernel interrupt handling and system calls, the current sampling rate threshold is locked to suspend dynamic adjustment, ensuring that the sampling frequency remains stable when the kernel executes core and key code segments, and that the sampling accuracy will not drop sharply due to load changes. The execution path, branch jump and instruction execution characteristics of key processes are fully captured, which makes up for the data collection loss problem that is easy to occur in key processes in ordinary dynamic adjustment schemes. The final performance configuration file can reflect the behavior characteristics of the kernel under normal load, and can also accurately depict the dynamic execution rules of key processes, thus improving the reference value of the performance configuration file.

[0038] In summary, this dynamic threshold adjustment mechanism, through a full-process dynamic control logic of load perception, condition triggering, range constraint, and critical protection, makes the instruction counting sampling mechanism more aligned with the operating characteristics of the QEMU simulator and the load changes of the target kernel. Without compromising the core requirements of "non-intrusive and high precision" of this solution, it minimizes the impact of instrumentation on simulator performance while ensuring the comprehensiveness and accuracy of performance data acquisition, ultimately improving the practicality, adaptability, and stability of the entire performance data acquisition solution.

[0039] More preferably, in one embodiment, the path statistics results include: a secondary hash index table of branch jump paths and a secondary hash index table of continuous execution paths; Step S3, which involves online aggregation and statistics of branch jump paths and continuous execution paths to obtain path statistics results, includes: The code block executes a callback function to traverse the branch jump paths accumulated in the LBR buffer and constructs a two-level hash index table for the branch jump paths. In the two-level hash index table for the branch jump paths, the first-level key is the first m bits of the starting virtual address (from_addr) of the branch jump path, the second-level key is the last 64-m bits of the starting virtual address (from_addr) of the branch jump path, and the value is the ending virtual address (to_addr) of the branch jump path and the number of times the branch jump path has been executed. By executing callback functions in code blocks, the consecutive execution paths accumulated in the LRR buffer are traversed, and a two-level hash index table of consecutive execution paths is constructed. In the two-level hash index table of consecutive execution paths, the first-level key is the first m bits of the starting virtual address (start_addr) of the consecutive execution path, the second-level key is the last 64-m bits of the starting virtual address (start_addr) of the consecutive execution path, and the value is the ending virtual address (end_addr) of the consecutive execution path and the number of times the consecutive execution path is executed.

[0040] Specifically: The callback function executing the code block iterates through all records accumulated in the LBR and LRR buffers, and inserts these records in batches into the two-level hash index table (jump_table) for branch jump paths and the two-level hash index table (range_table) for consecutive execution paths, which adopt a two-level hash index table structure. Taking jump_table as an example, the first-level key is the first m bits of the branch jump path's from_addr, and the second-level key is the last 64-m bits of the branch jump path's from_addr, with the value being the branch jump path's to_addr and the number of times that branch jump path is executed. The two-level hash index table can optionally adopt an expansion strategy similar to C++'s Vector, expanding to twice its capacity whenever the size exceeds the capacity, effectively reducing unnecessary memory consumption.

[0041] In this embodiment, the present invention introduces a two-level hash index table, setting up a two-level positioning logic of first-level key (first-level hash index) and second-level key (second-level hash index), realizing fast insertion and lookup of path information with an average time complexity of O(1). Compared with the traditional single-level hash or linked list structure, it significantly reduces memory usage and hash collision rate, making it particularly suitable for processing massive amounts of path information. This process ensures data consistency in a multi-core environment through mutex locks.

[0042] More preferably, in one embodiment, step S3, the steps of constructing a secondary hash index table for branch jump paths and constructing a secondary hash index table for continuous execution paths, include: Hash calculation and location: Recording branch jump paths: Taking a branch jump pair (e.g., "end virtual address of the previous code block - start virtual address of the current code block") as an example, calculate the first difference between the start virtual address (from_addr) of the branch jump path and the base address (kernel's start virtual address) (subtract the kernel's start virtual address from the start virtual address). Extract the high-order part of the first difference through bitwise operations, and use it as the first-level key (first-level hash index) of the branch jump path's secondary hash index table to locate the bucket. Extract the low-order part of the first difference through bitmasking operations, and use it as the second-level key (second-level hash index) of the branch jump path's secondary hash index table to locate the specific entry within the bucket (locating the specific storage entry within the corresponding bucket in the secondary hash index table). Through this operation, the branch jump pair and its corresponding execution frequency information can be stored in the specific storage entry.

[0043] Recording continuous execution paths: Taking a continuous execution interval (e.g., "starting virtual address of the current code block - ending virtual address of the current code block") as an example, calculate the second difference between the starting virtual address (start_addr) and the base address of the continuous execution interval. Extract the high-order part of the second difference through bit shifting operations as the first-level key (first-level hash index) of the second-level hash index table of the continuous execution path to locate the bucket. Extract the low-order part of the second difference through bitmasking operations as the second-level key (second-level hash index) of the second-level hash index table of the continuous execution path to locate the specific entry in the bucket.

[0044] Record insertion and update: Traverse the stored records within the located entry. If the target address (the branch jump path or continuous execution path to be inserted) already exists, increment the corresponding count value by one. If the target address does not exist, add the new path record and the initial count value of 1 to the storage space of the entry. Batch write strategy: An operation counter is maintained in the secondary hash index table. The operation counter is incremented by one each time a record is inserted or updated. When the operation counter exceeds the preset write threshold, a batch persistence operation is triggered, which writes all path records in the secondary hash index table to the persistent file at once. After completion, the current path records in the secondary hash index table are cleared and the operation counter is reset.

[0045] In this embodiment, the present invention introduces a two-level dynamic hash index table structure, designing a unified two-level hash index, update, and batch persistence scheme for branch jump paths and continuous execution paths. For the high-frequency acquisition scenario of kernel path data within the QEMU simulator, it combines dynamic start / stop control and batch writing mechanisms. Plugins can be dynamically enabled or disabled at runtime, avoiding unnecessary overhead during system startup or irrelevant phases. Simultaneously, by setting a write threshold, high-frequency memory operations are decoupled from low-frequency disk I / O operations, significantly reducing the overall impact of instrumentation on simulator performance. This solves the core problems of traditional storage structures—"low insertion efficiency, cumbersome statistics, and high persistence overhead"—and the core technical effects include at least: Unified hash logic reduces storage and computation overhead: Branches and continuous paths adopt the same source hash rule (base address offset + high and low bit splitting), eliminating the need to maintain multiple storage structures and hash algorithms, which greatly reduces the memory usage and code implementation complexity of QEMU plugins; at the same time, hash calculation only relies on simple bit operations such as bit shifting and bit masking, with low computational load, avoiding the additional performance burden brought by complex algorithms to simulator execution, which is in line with the core design goal of "non-intrusive and low overhead".

[0046] Accurately and efficiently complete path statistics and adapt to online aggregation requirements: Through the insertion logic of "traversal matching-count update", it realizes the rapid deduplication and frequency accumulation of duplicate paths. It can complete the online aggregation of path execution frequency without the need for additional statistical structures, which perfectly echoes the requirement of "efficient data structure online aggregation and statistics" and provides accurate frequency data support for the construction of performance configuration files.

[0047] Batch persistence strategy, balancing performance and data security: Batch writing is triggered by an operation counter, transforming high-frequency single path writing into low-frequency batch writing, which greatly reduces the number of system calls and reduces the interference of persistence operations on simulator performance; at the same time, batch writing can avoid data loss in abnormal scenarios such as instantaneous power outages, taking into account the real-time nature and security of path data, and solving the simulator lag problem caused by traditional real-time writing.

[0048] Adapting to kernel address characteristics and improving index distribution uniformity: Based on the kernel's starting virtual address as the baseline offset, the high-order fixed kernel address is transformed into a small-range offset value. Combined with a two-level index that splits the high and low orders, hash index clustering is effectively avoided, allowing path data to be evenly distributed within the hash table. This lays the foundation for the efficient execution of subsequent expansion mechanisms and improves data query and retrieval efficiency.

[0049] More preferably, in one embodiment, the steps of constructing a secondary hash index table for branch jump paths and constructing a secondary hash index table for continuous execution paths further include: First-level expansion (bucket expansion): When locating a bucket using the first-level key, if the calculated bucket index exceeds the capacity range of the current bucket array, the capacity of the bucket array is doubled, and the space of the newly added bucket is initialized to ensure normal subsequent location. Second-level expansion (entry expansion): After locating a specific entry in the bucket using the second-level key, if the number of path records already stored in the entry reaches half of the current storage space capacity, the storage space capacity of the entry will be doubled. After the expansion is completed, the storage location of the original records will be retained, and only the newly added storage space will be initialized. Post-expansion compatibility: After the tiered expansion is completed, the execution rules of the original hash calculation and positioning, record insertion and update, and batch write strategies remain unchanged.

[0050] In this embodiment, a hierarchical dynamic expansion mechanism is introduced to further enhance the adaptability of the hash table in scenarios with massive path data. The core technical effects include at least the following: Tiered expansion avoids hash collisions and ensures storage efficiency: Tiered expansion of the first-level bucket solves the index out-of-bounds problem and ensures that newly added path data can be located normally by doubling the capacity; Tiered pre-expansion of the second-level entries (doubling when the capacity reaches half) reserves storage space in advance, which greatly reduces the probability of hash collisions in subsequent insertions. Compared with the traditional "expansion after full capacity" method, it amortizes the collision handling cost of a single insertion, so that the hash table insertion and query operations always maintain an O(1) level time complexity, which is suitable for the massive path collection needs under high kernel load.

[0051] Seamless expansion ensures data collection continuity: After expansion, the original hash calculation, record update, and batch write rules remain unchanged. Storage space adjustment can be completed without interrupting the path collection process, avoiding missing path data or disordered collection timing caused by expansion operations. This ensures the continuity and integrity of kernel performance data collection, making it more practical than traditional expansion solutions that require service interruption.

[0052] Adaptive adjustment of storage space to improve resource utilization: Through the adaptive mechanism of "on-demand expansion", the hash table space dynamically increases or decreases with the amount of path data. This avoids the waste of memory resources caused by a fixed large-capacity hash table, and also prevents the performance loss caused by frequent expansion of a fixed small-capacity hash table. This achieves efficient utilization of memory resources and adapts to changes in the amount of path data under different kernel loads.

[0053] Specifically, in step S4: When QEMU exits, the emulator exit callback function registered by the plugin is triggered.

[0054] Preferably, in one embodiment, step S4, the step of constructing and returning a structured performance configuration file based on path statistics results, includes: Flush all data in memory that has not yet been written and write it to the structured performance configuration file; Output a statistical summary of this performance analysis session, such as total runtime, total number of recorded paths, etc. Release all dynamically allocated memory to ensure there are no memory leaks.

[0055] More preferably, the performance analysis method of the present invention further includes: post-processing and profile file generation steps: The plugin generates a data file that is a custom-formatted text file containing virtual addresses and execution frequencies. First, a post-processing script merges the branch jump path file and the continuous execution path file into a system path file. When processing the system path file, cross-function paths are removed. The `create_llvm_profile` tool is then used to convert the system path file into an LLVMProfile format file (e.g., `.profile`) that the Clang compiler can recognize. The source code of this tool has been adapted to parse custom data formats.

[0056] On the other hand, the present invention also provides a computer storage medium storing executable program code; the executable program code is used to execute any of the above-mentioned operating system kernel performance data acquisition methods.

[0057] On the other hand, the present invention also provides a terminal device, including a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute any of the above-mentioned operating system kernel performance data acquisition methods.

[0058] For example, the program code can be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the program code in the terminal device.

[0059] The terminal device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that the terminal device may also include input / output devices, network access devices, buses, etc.

[0060] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0061] The memory can be an internal storage unit of the terminal device, such as a hard drive or RAM. The memory can also be an external storage device of the terminal device, such as a plug-in hard drive, SmartMediaCard (SMC), Secure Digital (SD) card, or FlashCard. Furthermore, the memory can include both internal and external storage units of the terminal device. The memory is used to store the program code and other programs and data required by the terminal device. The memory can also be used to temporarily store data that has been output or will be output.

[0062] The aforementioned computer storage medium and terminal device are created based on the aforementioned operating system kernel performance data acquisition method. Their technical functions and beneficial effects will not be elaborated here. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0063] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of this invention patent should be determined by the appended claims.

Claims

1. A method for collecting operating system kernel performance data, characterized in that, include: Initialize a dedicated performance analysis plugin based on QEMU's plugin API; When QEMU starts, the dedicated performance analysis plugin is loaded, and code block translation callback functions, code block execution callback functions, and simulator exit callback functions are registered. When the QEMU dynamic translator translates the kernel code of the target architecture into the host machine's native code, the code block translation callback function is triggered to obtain basic information about the kernel code; When the translated host machine native code is executed in the virtual machine, the code block execution callback function is triggered. Based on the basic information, the branch jump path and continuous execution path of the kernel code are captured in real time, and the branch jump path and continuous execution path are aggregated and statistically analyzed online to obtain path statistics results. After the execution of the host machine's local code is completed, the emulator's exit callback function is called to construct and return a structured performance configuration file based on the path statistics results; wherein, the structured performance configuration file is used to characterize the dynamic behavior of the kernel code under specific loads.

2. The operating system kernel performance data acquisition method according to claim 1, characterized in that, The basic information includes: the starting virtual address of each code block, the ending virtual address of each code block, and the machine code of the last instruction of each code block; The steps for capturing the branch jump paths and continuous execution paths of the kernel code in real time based on the aforementioned basic information include: The steps for recording branch jump paths are as follows: Extract the ending virtual address of the previous code block saved during the last execution from the basic information, and combine it with the starting virtual address of the current code block to form a branch jump pair, which is then inserted into the LBR buffer. The steps for recording a continuous execution path are as follows: extract the start and end virtual addresses of the current code block from the basic information to form a continuous execution interval, and insert it into an LRR buffer; State Update: After recording the branch jump path and the continuous execution path, based on the basic information, the end virtual address of the current code block and the machine code of the last instruction are updated to the basic information of the previous code block and stored in the preset state cache to prepare for the recording of the branch jump path when the next execution callback is triggered.

3. The operating system kernel performance data acquisition method according to claim 1, characterized in that, The initialization of the dedicated performance analysis plugin includes initializing the sampling rate threshold; The basic information includes the number of instructions in the code block; In the step of capturing the branch jump path and continuous execution path of the kernel code in real time based on the basic information, an instruction counting-based sampling mechanism is adopted, including: An instruction counter is maintained inside the callback function of the code block execution. Each time a code block is executed, the number of instructions contained in the code block is added to the instruction counter. When the value of the instruction counter reaches a preset sampling rate threshold, a sampling event is triggered, and the instruction counter is cleared after sampling.

4. The operating system kernel performance data acquisition method according to claim 3, characterized in that, The initialization dedicated performance analysis plugin also includes an initialization virtual load detection module, a virtual high load threshold, a virtual low load threshold, a threshold adjustment step size, and a number of consecutive trigger detections; The sampling rate threshold employs a dynamic threshold adjustment mechanism, including: Virtual load monitoring: The virtual load monitoring module is initialized to count the instruction execution density of the target operating system kernel in the QEMU simulator at preset time intervals. The instruction execution density is the ratio of the total number of times the kernel code block is executed to the collection time during the collection period. Threshold adjustment: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections and is higher than the virtual high load threshold, the current sampling rate threshold is adjusted upward according to the preset threshold adjustment step size. After the adjustment, the sampling rate threshold does not exceed the upward adjustment ratio of the initial sampling rate threshold. Threshold reduction: When the statistically obtained instruction execution density continuously reaches the configured number of consecutive trigger detections and is lower than the virtual low load threshold, the current sampling rate threshold is reduced according to the preset threshold adjustment step size. After the reduction, the sampling rate threshold is not lower than the reduction ratio of the initial sampling rate threshold. Threshold locking: When the target operating system kernel is detected to be in a critical process execution phase, the current sampling rate threshold is locked, dynamic adjustment is paused, and the critical process execution is completed.

5. The operating system kernel performance data acquisition method according to claim 2, characterized in that, The path statistics include: a secondary hash index table of branch jump paths and a secondary hash index table of continuous execution paths; The step of online aggregation and statistics of the branch jump path and the continuous execution path to obtain path statistics results includes: The callback function executed by the code block traverses the branch jump paths accumulated in the LBR buffer and constructs a two-level hash index table of the branch jump paths; in the two-level hash index table of the branch jump paths, the first-level key is the first m bits of the starting virtual address of the branch jump path, the second-level key is the last 64-m bits of the starting virtual address of the branch jump path, and the value is the ending virtual address of the branch jump path and the number of times the branch jump path has been executed; The callback function executed by the code block traverses the consecutive execution paths accumulated in the LRR buffer and constructs a two-level hash index table for the consecutive execution paths. In the two-level hash index table for the consecutive execution paths, the first-level key is the first m bits of the starting virtual address of the consecutive execution path, the second-level key is the last 64-m bits of the starting virtual address of the consecutive execution path, and the value is the ending virtual address of the consecutive execution path and the number of times the consecutive execution path has been executed.

6. The operating system kernel performance data acquisition method according to claim 5, characterized in that, The steps of constructing the secondary hash index table for branch jump paths and the steps of constructing the secondary hash index table for continuous execution paths include: Hash Calculation and Location: Calculate the first difference between the starting virtual address and the base address of the branch jump path. Extract the high-order part of the first difference through bit shifting operations, and use it as the first-level key of the secondary hash index table of the branch jump path to locate the bucket. Extract the low-order part of the first difference through bitmasking operations, and use it as the second-level key of the secondary hash index table of the branch jump path to locate the specific entry within the bucket. Calculate the second difference between the starting virtual address and the base address of the continuous execution path. Extract the high-order part of the second difference through bit shifting operations, and use it as the first-level key of the secondary hash index table of the continuous execution path to locate the bucket. Extract the low-order part of the second difference through bitmasking operations, and use it as the second-level key of the secondary hash index table of the continuous execution path to locate the specific entry within the bucket. Record insertion and update: Traverse the stored records within the located entry. If the target address already exists, increment the corresponding count value by one. If the target address does not exist, add the new path record and the initial count value of 1 to the entry storage space. Batch write strategy: An operation counter is maintained in the secondary hash index table. The operation counter is incremented by one each time a record is inserted or updated. When the operation counter exceeds the preset write threshold, a batch persistence operation is triggered, which writes all path records in the secondary hash index table to the persistent file at once. After completion, the current path records in the secondary hash index table are cleared and the operation counter is reset.

7. The operating system kernel performance data acquisition method according to claim 6, characterized in that, The steps of constructing the secondary hash index table for branch jump paths and the steps of constructing the secondary hash index table for continuous execution paths further include: First-level expansion: When locating a bucket using the first-level key, if the calculated bucket index exceeds the capacity range of the current bucket array, the capacity of the bucket array is doubled, and the space of the newly added bucket is initialized to ensure normal subsequent location. Second-level expansion: After locating a specific entry in the bucket using the second-level key, if the number of path records already stored in the entry reaches half of the current storage space capacity, the storage space capacity of the entry will be doubled. After the expansion is completed, the storage location of the original records will be retained, and only the newly added storage space will be initialized. Post-expansion compatibility: After the tiered expansion is completed, the execution rules of the original hash calculation and positioning, record insertion and update, and batch write strategies remain unchanged.

8. The method for acquiring operating system kernel performance data according to any one of claims 1 to 7, characterized in that, The step of constructing and returning a structured performance configuration file based on the path statistics results includes: Flush all data that has not yet been written to memory and write it to the structured performance configuration file; Output a statistical summary of this performance analysis session; Release all dynamically allocated memory to ensure there are no memory leaks.

9. A computer storage medium, characterized in that, It stores executable program code; the executable program code is used to execute the operating system kernel performance data acquisition method according to any one of claims 1 to 8.

10. A terminal device, characterized in that, It includes a memory and a processor; the memory stores program code that can be executed by the processor; the program code is used to execute the operating system kernel performance data acquisition method according to any one of claims 1 to 8.

Images