A PMC parallel acquisition system and method of an ARM heterogeneous multi-core processor

Abstract

The application discloses a PMC parallel collection system and method of an ARM heterogeneous multi-core processor. By identifying the type of CPU core responsible for the collection task, a configured PMC event set is created for each online CPU core, and a performance counter is configured and enabled. During the sampling process, all threads use a unified sampling strategy and start sampling synchronously. Each sampling thread periodically reads the PMC counter value of its binding core, dynamically measures the actual sampling overhead of each core, and calculates the optimal sampling ratio in real time according to the load state and core type. Finally, for large and small core PMC data, the decision criteria are dynamically adjusted, a termination signal is sent to the sampling thread after data analysis, the performance event is closed, the memory mapping is released, and the resources are released. The method provides high-precision PMC collection performance monitoring and excellent collection efficiency, and greatly reduces the time overhead of collection.

Description

Technical Field

[0001] This invention belongs to the field of electrical digital data processing technology, and relates to the performance testing of heterogeneous multi-core processors, specifically to a PMC parallel acquisition system and method for ARM heterogeneous multi-core processors. Background Technology

[0002] The widespread deployment of ARM architecture in mobile and server applications has driven the rapid development of heterogeneous multi-core processors. CPU power consumption prediction models based on performance detection counters (PMCs) have attracted widespread attention due to their high accuracy and low overhead. During the model parameter sampling process, PMU events are highly reliable in reflecting CPU performance, thus playing a crucial role in CPU performance monitoring.

[0003] Traditional PMC sampling methods are generally based on the Linux perf subsystem, reading PMC data through API functions and employing a uniform sampling strategy across all CPU cores. However, when sampling multiple PMCs in a multi-core system, these API functions incur significant time overhead. User-space tools like simpleperf and PAPI use system calls to invoke low-level kernel functions to collect PMC data. This process causes the CPU to switch from user mode to kernel mode, meaning that a large portion of the user-space PMC sampling time is consumed during CPU state transitions, impacting system performance and the real-time performance of power consumption estimation. In contrast, the kernel-space function `perf_event_read_value()` executes directly in the kernel, eliminating the need for user-to-kernel mode switching, thus offering higher efficiency and lower time overhead. However, this method can only read one PMC from one CPU per interrupt response, and interrupt responses require context switching. In a multi-core system, if a CPU wants to sample the PMCs of all cores, it must read them serially, spending a significant amount of time waiting.

[0004] Existing technology 1 (Che, N., et al. (2024). OS-level PMC-based runtime thermal control for ARM mobile CPUs. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 43(7), 2023–2036.) discloses a structure that introduces a "producer-consumer" model, task queues, and shared memory, and designs an efficient PMC acquisition mechanism. It cleverly solves the above problems by reducing the number of interrupts and using parallel acquisition.

[0005] However, in heterogeneous architectures, the PMC data collection requirements of different core types are more complex. The sampling methods described above use the same sampling frequency strategy, ignoring the fact that in heterogeneous multi-core CPUs, the sampling overhead of small cores is usually higher than that of large cores, as well as the problems caused by differences in sampling performance. This leads to excessive load on small cores and wasted performance on large cores. Furthermore, the sampling strategy is not dynamically adjusted according to the system's operating status, resulting in problems such as easy interference with system services under high load and insufficient monitoring accuracy under low load, affecting the real-time performance and accuracy of performance monitoring. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention proposes a parallel PMC acquisition system and method for ARM heterogeneous multi-core processors. Based on the parallelized PMC acquisition mechanism, it constructs a hardware-specific basic ratio model by measuring the actual sampling overhead of different types of cores in real time, and designs an adaptive algorithm to adjust the CPU frequency of acquisition, thereby reducing the waste of sampling performance. This provides an efficient, accurate, and low-latency solution to the high time overhead problem of PMC acquisition in heterogeneous multi-core environments.

[0007] A PMC parallel acquisition method for ARM heterogeneous multi-core processors specifically includes the following steps:

[0008] Step 1: System Initialization and Configuration

[0009] The CPU cores responsible for data acquisition are initialized. Heterogeneous cores are identified and classified by reading processor characteristic registers or system information. The system creates CPU masks (cpumask) for large and small cores, establishes a clear core type mapping, allocates per-CPU data structures, and prepares independent monitoring status storage for each core. Simultaneously, global synchronization primitives, including mutexes and wait queues, are initialized to ensure thread safety for subsequent parallel operations. A configured PMC event set is created for each online CPU core, and performance counters are configured and enabled. If a user-defined PMC event configuration exists, it is loaded; otherwise, the system default event configuration is used.

[0010] As a preferred option, register a CPU hot-swap callback function and set a callback trigger point to adjust the monitoring range when the core goes online or offline.

[0011] Step 2: Data Acquisition and Monitoring

[0012] A dedicated sampling thread is created for each online CPU core, and these threads are strictly bound to the target core to ensure localized sampling and minimal monitoring interference. After all threads initialize, they enter a ready state and wait. Once the master thread confirms that all threads are ready, it sends a global start signal, and all threads then synchronously begin sampling, ensuring accurate data time alignment. During sampling, a unified sampling strategy is employed, with all cores using the same configuration event set. Each sampling thread periodically reads the PMC counter value of its bound core and stores the data in the core's local buffer, avoiding performance loss caused by cross-core data transfer.

[0013] The big.LITTLE architecture is packaged, and during sampling, the actual sampling overhead of different cores is dynamically measured. Combined with CPU load status obtained from CPU utilization, a dynamic sampling ratio factor is calculated, and the optimal sampling ratio is calculated in real time based on the load status and core type to achieve an adaptive sampling strategy. Simultaneously, CPU hot-plug events are responded to in real time. When a new core comes online, new monitoring threads and performance events are created; when a core goes offline, related threads are safely stopped and resources are cleaned up.

[0014] Step 3: Data Processing and System Termination

[0015] Differentiate PMC data between big and small cores, apply a differentiated analysis algorithm, and dynamically adjust the judgment criteria. Focus on analyzing high-performance computing indicators for big cores and energy efficiency indicators for small cores. Finally, send a termination signal to the sampling thread to disable performance events, unmap memory, and release resources.

[0016] A PMC parallel acquisition system based on an ARM heterogeneous multi-core processor includes a system initialization and configuration module, a data acquisition and monitoring module, and a data processing and system termination module.

[0017] The system initialization and configuration module includes an IPH unit and a CHPE unit. The IPH unit is used to identify, classify, and initialize the CPU cores undertaking the acquisition task, and call the CHPE unit to form a set of acquisition events for the PMUs to be acquired.

[0018] The data acquisition and monitoring module includes an SHPS unit, an EPSC unit, and a CSPR unit. The SHPS unit allocates acquisition tasks based on the event set content and the big / small core architecture packaged by the EPSC unit. The EPSC unit collects CPU utilization and sampling data during the acquisition process, calls the CSPR unit to calculate the dynamic sampling factor, and returns it to the SHPS unit to adjust the sampling frequency of the big and small cores. Finally, the raw PMC data is transmitted to the data processing and system termination module.

[0019] The data processing and system termination module includes a PPDA unit and an SPR unit. The PPDA unit performs statistical analysis on the raw PMC data input from the EPSC unit, and stores the PMC data into memory after confirming that there is no abnormal data. The SPR unit is used for the recycling and cleanup of all system resources after the data acquisition task is completed.

[0020] The present invention has the following beneficial effects:

[0021] 1. Breaking away from the traditional simplistic approach of treating all cores as homogeneous processing units, this approach accurately identifies the performance differences between large and small cores in the ARM big.LITTLE architecture and implements a differentiated sampling strategy. Addressing the higher sampling overhead of small cores, it automatically reduces the sampling frequency of small cores to a level suitable for large cores, effectively reducing overall acquisition overhead.

[0022] 2. Dynamically measure the actual sampling overhead ratio between large and small cores, calculate the optimal sampling period in real time in conjunction with CPU load status, and adaptively adjust the sampling interval to achieve joint optimization of hardware characteristics and operating status.

[0023] 3. Employing a per-CPU data structure avoids lock contention and supports users in allocating PMC event collection tasks across multiple threads on large / small cores, allowing selection of the most representative performance metrics for different microarchitecture characteristics. By optimizing core local operations and differentiated sampling strategies, monitoring interference is minimized, ensuring that performance data accurately reflects workload characteristics. Meanwhile, built-in intelligent default configuration enhances system usability.

[0024] 4. Implements CPU hot-plug awareness and NUMA-optimized resource management, enabling real-time response to core online / offline events and dynamic adjustment of monitoring scope and sampling strategies. By allocating resources to the correct NUMA nodes, it optimizes memory access locality and reduces cross-node data transfer latency. This design allows the optimized system to potentially scale efficiently to large-scale ARM server platforms, supporting cluster-level performance monitoring capabilities. Attached Figure Description

[0025] Figure 1 Block diagram of a PMC parallel acquisition system for ARM heterogeneous multi-core processor;

[0026] Figure 2 This refers to the load time overhead of the simpleperf data acquisition tool in the example;

[0027] Figure 3 The time overhead of different methods for data collection during large-core computationally intensive loads is shown in the examples.

[0028] Figure 4 The time overhead of different methods for collecting data during small-core computationally intensive loads in the embodiments;

[0029] Figure 5 The time overhead of different methods for data collection during large-core I / O intensive loads is shown in the examples.

[0030] Figure 6 The time overhead of different methods for data collection during small-core I / O intensive loads is shown in the examples.

[0031] Figure 7 The example illustrates the acquisition error of this method under different loads. Detailed Implementation

[0032] The present invention will be further explained below with reference to the accompanying drawings;

[0033] like Figure 1 As shown, a PMC parallel acquisition system based on an ARM heterogeneous multi-core processor includes a system initialization and configuration module, a data acquisition and monitoring module, and a data processing and system termination module.

[0034] The system initialization and configuration module includes an IPH unit and a CHPE unit. The IPH unit is used to identify, classify, and initialize the CPU cores undertaking the acquisition task, and calls the CHPE unit to form a set of acquisition events for the PMUs to be acquired.

[0035] The data acquisition and monitoring module includes an SHPS unit, an EPSC unit, and a CSPR unit. The SHPS unit allocates acquisition tasks based on the event set content and the big / small core architecture packaged by the EPSC unit. The EPSC unit collects CPU utilization and sampling data during the acquisition process, calls the CSPR unit to calculate the dynamic sampling factor, and returns it to the SHPS unit to adjust the sampling frequency of the big and small cores. Finally, the raw PMC data is transmitted to the data processing and system termination module.

[0036] The data processing and system termination module includes a PPDA unit and an SPR unit. The PPDA unit performs statistical analysis on the raw PMC data input from the EPSC unit, and stores the PMC data into memory after confirming that there is no abnormal data. The SPR unit is used for the recycling and cleanup of all system resources after the data acquisition task is completed.

[0037] A PMC parallel acquisition method for ARM heterogeneous multi-core processors specifically includes the following steps:

[0038] Step 1: System Initialization and Configuration

[0039] The PMU acquisition initialization process for heterogeneous multi-core processors is implemented through the InitPMCSystemForHeterogeneous() function. Its core lies in establishing a heterogeneous sensing monitoring infrastructure, specifically:

[0040] s1.1 The cpumask_clear() function is used to clear the big core CPU mask big_cores and the little core CPU mask little_cores respectively, so as to build an initial container for subsequent core classification and ensure the consistency of the mask state.

[0041] s1.2. By traversing all online CPU cores, the core type is determined based on the predefined core ID range BIG_CORE_START~BIG_CORE_END. Then, the cores are included in the corresponding masks by using the cpumask_set_cpu() function, thus completing the topology abstraction of the heterogeneous system.

[0042] s1.3 Call the CreateHeterogeneousPerfEvents() function for each online CPU to create PMC events for each core according to user configuration or system default configuration:

[0043] s1.3.1 Obtain the target CPU-specific data structure pmc_data to provide localized storage support for subsequent event configuration.

[0044] s1.3.2. Determine the core type and record the current CPU architecture information;

[0045] s1.3.3 Check user configuration. If user configuration user_config exists, load the event set specified by the user; otherwise, use the system default event configuration.

[0046] s1.3.4 Clean up existing events on the target CPU to ensure the purity of the new configuration environment.

[0047] s1.3.5 Iterate through the configuration items and create performance events. Generate and enable kernel-level counters using perf_event_create_kernel_counter(), and finally return the number of successfully created events, events_created.

[0048] s1.4 Registering CPU hot-plug callback functions via cpuhp_setup_state() enables the system to respond in real-time to frequent core online / offline operations of the ARM processor. When a core comes online, cpu_online_callback automatically creates a PMU event for the new core and starts monitoring; when a core goes offline, cpu_offline_callback safely stops related monitoring and releases resources. This dynamic adaptation mechanism is particularly important for the aggressive power management strategies of modern ARM mobile processors, ensuring the continuity of the monitoring process and data integrity.

[0049] The `StartHeterogeneousParallelSampling()` function (s1.5) initiates the parallel sampling thread system. By allocating a dedicated sampling thread to each core and strictly binding it to the target CPU, a distributed data acquisition architecture is achieved. This design avoids the performance bottleneck of traditional single-threaded sampling, while reducing cache invalidation and context switching overhead caused by task migration through thread binding.

[0050] The key feature of the system initialization and configuration phase lies in its deep architecture awareness capability, specifically optimized for the characteristics of heterogeneous ARM processors. By reading processor characteristic registers or system information, it accurately distinguishes the core types within the ARM processor. It also provides a flexible configuration mechanism and efficient resource allocation strategies. After system initialization is complete, all CPU core PMC events are configured and ready, core classification and resource allocation are finished, and the system can proceed to the subsequent data acquisition and monitoring phase.

[0051] Step 2: Data Acquisition and Monitoring

[0052] The sampling process is initiated by calling the `StartHeterogeneousParallelSampling()` function, creating a dedicated sampling thread for each online CPU core and strictly binding the thread to the target core to ensure localized sampling and minimal monitoring interference. The `ExecuteParallelSamplingAndCollection()` function coordinates the entire sampling process, ensuring the continuity and integrity of data acquisition. During sampling, the `CalculateAdaptiveSamplingRatio()` function dynamically measures the actual sampling overhead of different cores and calculates the optimal sampling ratio for each core in real time, implementing an adaptive sampling strategy.

[0053] The parallel sampling design of the `StartHeterogeneousParallelSampling()` function fully leverages the parallelism of modern multi-core processors. Simultaneously, through careful thread management and synchronization mechanisms, it ensures low interference and high accuracy in the sampling process. For heterogeneous processors, it allows the system to simultaneously monitor the performance characteristics of different types of cores, providing a comprehensive and unified view of system performance.

[0054] s2.1 Initialize the threads_ready atomic counter, initialize the threads_finished atomic counter, set start_flag to 0, and complete the initialization of the atomic counters and control flags required for synchronization.

[0055] s2.2. Create a dedicated sampling thread for each online CPU core in the system: Iterate through all online CPUs, call the cpu_to_node() function to determine the NUMA node to which each CPU belongs, and call kthread_create_on_node() to create a sampling thread threads[] on the correct NUMA node. This NUMA-aware design optimizes memory access locality and reduces cross-node communication overhead.

[0056] s2.3 To ensure the accuracy of sampling, kthread_bind() is used to strictly bind each thread[] to its target CPU to prevent cache invalidation and context switching overhead caused by thread migration.

[0057] s2.4 An error handling mechanism is designed during thread creation: if thread creation fails, the created threads are stopped in a loop and a failure is returned to prevent resource leaks. After thread creation is complete, `wake_up_process()` wakes up all threads to begin executing initialization logic. Then, `wait_event_timeout()` is called to wait for all threads to enter the ready state (`atomic_read(&threads_ready) == num_online_cpus()`), implementing a synchronization barrier between threads to ensure all threads complete necessary preparations before sampling begins. When all threads are ready, the global start flag `start_flag` is set to 1, and `wake_up_all()` wakes up the waiting threads, triggering the synchronous start of parallel sampling. If not all threads are ready after the timeout, an error is reported and a failure is returned.

[0058] This two-stage startup design, which is ready first and then synchronized, ensures precise timing alignment of sampling, which is crucial for cross-core performance correlation.

[0059] The ExecuteParallelSamplingAndCollection() function implements the core execution logic for parallel sampling:

[0060] s2.5. Obtain the local data structure local_data of the current CPU through per_cpu_ptr().

[0061] s2.6 Use kmalloc_node() to allocate a buffer of uniform size local_data.buffer on the corresponding NUMA node to optimize memory access locality.

[0062] s2.7. Send the thread ready notification threads_ready via atomic_inc() and call wait_event() to wait for the global start signal start_flag to ensure multi-threaded collaborative startup.

[0063] s2.8. Enter the main sampling loop, read the current CPU's PMC event value local_data.events using perf_event_read_value(), and record the timestamp sleep_time. Then, directly call the CalculateAdaptiveSamplingRatio() function to dynamically calculate the sampling interval, and precisely control the sampling period using the high-precision timer hrtimer_nanosleep().

[0064] s2.8.1. The target CPU core type is determined by cpumask_test_cpu(). For large cores, the baseline ratio of 1.0 is returned directly to maintain the standard sampling frequency. For small cores, the reference large core is obtained by cpumask_first(), and the actual PMC sampling time overhead of overhead_big and overhead_little for large cores and small cores is measured by kme_get() in conjunction with execute_pmc_sampling(), respectively, to eliminate the influence of hardware platform differences.

[0065] s2.8.2 Calculate the hardware-specific baseline ratio R_base = overhead_little / overhead_big. Since the hardware overhead of sampling operations is mainly reflected in time consumption, by calculating the ratio of sampling time overhead R_base, the hardware performance difference between big and small cores can be quantified. This compensates for the imbalance in sampling overhead caused by the difference in big and small core architectures, providing a true performance benchmark for subsequent adaptive adjustments, maintaining equivalent monitoring effects within the same time window, and ensuring that monitoring overhead matches hardware performance.

[0066] s2.8.3 To avoid monitoring interference with system operation under high load and insufficient monitoring accuracy under low load, the dynamic impact of load changes on the sampling strategy is realized. The utilization rate of the target CPU, current_load, is obtained. The load perception factor, load_factor=f(current_load)=1.0+(current_load-0.5)*α, is calculated through the load perception function f(), where α represents the sensitivity coefficient.

[0067] The load sensing function f() should satisfy:

[0068] ① When the utilization of the target CPU current_load=0.5, it belongs to medium load, and no sampling strategy is adjusted, that is, f(0.5)=1.0.

[0069] ② When the utilization rate of the target CPU current_load=1.0, it is considered a high load. The sampling interval needs to be extended to reduce the interference of monitoring on the business. That is, f(1.0) > 1.0.

[0070] ③ When the utilization rate of the target CPU current_load→0.0, it is in an idle state. The sampling interval can be shortened to improve the monitoring accuracy, that is, f(0.0) < 1.0.

[0071] To ensure a balance between load response and data stability, this embodiment sets the sensitivity coefficient α=0.4, thereby allowing the load perception factor load_factor to be adjusted smoothly within the range of [0.8,1.2], avoiding the weak impact of load changes on the sampling strategy, or the drastic changes in the sampling interval caused by excessive load fluctuations, which would disrupt the continuity of monitoring data.

[0072] s2.8.4 Multiply the hardware-specific base ratio R_base by the load-aware factor load_factor to perform performance difference compensation and real-time response to load changes, and obtain the preliminary adaptive ratio adaptive_ratio=R_base×load_factor, thereby realizing the joint optimization of hardware characteristics and operating status.

[0073] To prevent the sampling strategy from failing in extreme cases, boundary constraints are introduced, and the dynamic sampling ratio factor is calculated as sampling_ratio = max(lb). down ,min(lb up `adaptive_ratio` ensures that the sampling interval effectively reduces the burden on the small core without affecting data timeliness. `max` and `min` represent taking the maximum and minimum values, respectively. down lb up These represent the lower and upper boundaries, respectively. To balance cost control and monitoring integrity, this embodiment sets an upper boundary lb. up =2.5, controlling the maximum extension of the sampling interval to 150%, ensuring that critical performance events are not lost due to excessively long sampling intervals. Lower boundary lb up =1.2, which allows the sampling interval to be extended by at least 20%, ensuring an effective reduction in the monitoring overhead of small cores.

[0074] s2.8.5 returns the dynamic sampling ratio factor (sampling_ratio) after hardware measurement, load awareness, and boundary protection, providing intelligent frequency scheduling for heterogeneous multi-core PMC sampling.

[0075] s2.9 After sampling is completed, update the thread completion status and set the sampling completion flag local_data.sampling_done.

[0076] s2.10. Create the main control thread using kthread_run() and use wait_event_timeout() to wait for all sampling threads to complete or time out, thereby achieving global process coordination.

[0077] The dynamic sampling scaling factor solves the problems of traditional methods, which use a uniform sampling frequency, leading to excessive load on small cores, wasted performance on large cores, inability to adjust the sampling rhythm according to the real-time operating status of the CPU, easy interference with system services under high load, and insufficient monitoring accuracy under low load. While reducing the PMC acquisition overhead of heterogeneous multi-core systems, it ensures the accuracy and continuity of sampling data, providing reliable underlying data support for performance monitoring.

[0078] Step 3: Data Processing and System Termination

[0079] The termination phase is responsible for analyzing and processing the collected PMC data and ensuring the safe release of system resources.

[0080] The ProcessPMCDataAndDetectAnomalies() function iterates through and analyzes sampled data from all online CPUs to calculate key statistical indicators in order to identify potential performance anomalies.

[0081] s3.1 Initialize two counters, including the number of processed CPUs (processed_cpus) and the number of abnormal CPUs (anomalies_detected), and then iterate through all online CPUs in the system using a loop structure.

[0082] s3.2 For each CPU, first obtain its unique PMC data structure pmc_data, and filter out the core data that has been sampled by judging the sampling completion flag. Then, determine whether the current CPU type is a big core or a small core by using the core type mask. The CPU type determination result provides the basis for subsequent differential threshold selection.

[0083] s3.3 Perform statistical analysis on each PMC event event_idx on the CPU and calculate its average value. Standard deviation Minimum value x min and the maximum value x max This serves as a benchmark for anomaly detection.

[0084] s3.4 Design a multi-dimensional verification mechanism for the anomaly detection phase:

[0085] s3.4.1. Iterate through each sampling point and calculate the Z-score z_score of the original PMC data x to quantify its deviation from the statistical baseline:

[0086] Calculate the minimum value x min With the maximum value x max The corresponding Z-score yields the minimum offset Z of the event. min and maximum offset Z max This serves as a standard for judging data accuracy. s3.4.2. Because large cores typically run more complex, computationally intensive tasks, the absolute value and fluctuation range of their performance counters are usually larger than those of small cores. Small cores, on the other hand, typically handle background tasks or lightweight work, and their performance characteristics are more stable with smaller fluctuations. If the same threshold is used to detect large and small cores, normal fluctuations in large cores may be misjudged as abnormal, while genuine anomalies in small cores may be ignored. Therefore, differentiated thresholds need to be applied based on core type.

[0087] In this embodiment, the threshold for the small core is set to... ~ Set the threshold for large cores to ~ The threshold can be adjusted based on subsequent running results.

[0088] s3.4.3 When the number of events sample_anomaly with z_score > threshold in a certain sampling point reaches the preset threshold MIN_ANOMALY_EVENTS, the sampling point is marked as abnormal and recorded, and the abnormal CPU count counter anomalies_detected is incremented.

[0089] s3.4.4. After completing the processing of one CPU, the processed_cpus counter is incremented. After the entire process is completed, the result of whether any CPU was successfully processed is returned based on the value of the processed_cpus counter.

[0090] The `ShutdownPMCSystemAndReleaseResources()` function uses a systematic resource reclamation strategy to ensure that all allocated resources are properly released, thus preventing memory leaks and resource hoarding.

[0091] s3.5 Initialize the shutdown status to SUCCESS and set the terminated thread count threads_terminated to zero.

[0092] s3.6. Iterate through all online CPU cores and send termination signals to active sampling threads by setting the terminate_requested flag. This non-blocking approach allows threads to exit safely at appropriate checkpoints, avoiding resource inconsistencies that might result from forced termination.

[0093] s3.7 After the termination signal is sent, all cores are traversed again, waiting for the sampling thread to complete and exit. For each active thread, `kthread_join` is called to wait for its termination. On success, the `threads_terminated` count of terminated threads is incremented; on failure, an error is recorded and the shutdown status is set to `PARTIAL_FAILURE`. This error handling mechanism ensures that even if some threads fail to terminate normally, the function can still continue to execute and release resources. After each thread completes its processing, its active status flag is reset.

[0094] s3.8 During resource release, first, the performance events configured on each core are disabled. For each valid event, `perf_event_disable` is called to disable the counting, then `perf_event_release_kernel` is used to release kernel resources and set the event pointer to null. Memory resources are then processed, including unmapping mmap mappings, releasing the data buffer `cpu_data.buffer` and the statistics array `cpu_data.stats`, and resetting CPU data structure status parameters.

[0095] s3.9 Release global resources, check the number of terminated threads (threads_terminated) and the total number of active threads (active_thread_count). If threads_terminated < active_thread_count, it means there are threads that did not terminate successfully, and set the shutdown_status to PARTIAL_FAILURE. Return the final status shutdown_status to inform the caller of the result of the termination process.

[0096] To illustrate the beneficial effects of this method (HCMS), we compared its time overhead, performance overhead, and acquisition accuracy with the traditional PMC acquisition method that calls the Linux_perf subsystem API, the PMC acquisition tool simpleperf commonly used in Android systems, and the prior art mentioned in the background section. The different methods run the same load program during the acquisition process.

[0097] The comparative experiment used an ARM.bigtitle architecture RK3588 processor development board with a CPU featuring a large-core Cortex-A76 and a small-core Cortex-A55. The large-core Cortex-A76 operated from 408MHz to 2.4GHz, while the small-core Cortex-A55 operated from 408MHz to 1.8GHz. The operating system used was Android 12, with a Linux kernel version of Linux 5.10. The terminal computer's processor was an Intel Ultra 9, and the operating system was Windows 11. The Android and its kernel compilation environment was deployed on a VMware Workstation Pro virtual machine running Ubuntu 20.02, using the clang compilation tool included in the Rockchip official SDK.

[0098] The algorithms in Table 1 are used to act as the acquisition load, including both compute-intensive and I / O-intensive loads:

[0099] Table 1

[0100]

[0101] Since the number of PMU events sampled by an ARM architecture PCU is limited, and the RK3588 contains 7 PMU data registers, it can sample a maximum of 7 PMC events at a time. The event overhead of each sampling count was recorded under different load conditions. A group of 7 identical PMU events was sampled, and each experiment consisted of 10 rounds of sampling, for a total of 10 runs. The time consumed by a single PMC sampling under different loads was recorded, and the average time overhead of the 10 rounds was calculated. A sampling system with shorter time overhead has lower sampling overhead and better performance. The experimental subjects were large cores and small cores, meaning the large and small cores were tested separately.

[0102] Figure 2 The images show the load data collected using the PMC data acquisition tool simpleperf. (a) shows the load collected from large cores, and (b) shows the load collected from small cores. It can be observed that the time overhead of simpleperf varies between 20,000 ns and 35,000 ns depending on the load. The impact of different core types on the acquisition overhead is only a small part compared to the overall acquisition overhead. This is because simpleperf is a user-space PMC data acquisition tool, which essentially uses system calls to invoke low-level kernel functions to collect PMC data. This process causes the CPU to switch from user mode to kernel mode, and this state transition incurs significant time overhead.

[0103] Figure 3 ,4 The table shows the acquisition overhead of large and small cores when the operating system is running a computationally intensive load, using the proposed method (HCMS), prior art 1, and the perf_event_read_value() method alone. The loads represented by (a) to (d) are matrix multiplication, vector operations, image processing, and FFT, respectively. It can be seen that, under the same PMC acquisition conditions, the proposed method significantly reduces the time overhead compared to the other two methods under large core conditions, while the overhead under small core conditions is 1.5 to 1.8 times higher than that of large cores. This is because the proposed method uses an adaptive sampling strategy, and the sampling performance and clock frequency of small cores differ significantly from those of large cores, so the results are as expected.

[0104] Figure 5 , 6 The table shows the data collection overhead for large and small cores when the operating system is running an I / O-intensive load, using the proposed method (HCMS), existing technology 1, and the perf_event_read_value() method alone. (a) through (c) represent the loads of sequential read / write, random read / write, and mixed read / write, respectively. Comparison Figures 3-6 It can be seen that the acquisition overhead during different I / O-intensive workloads is lower than that during compute-intensive workloads. This is because, under large core conditions, it can be maintained within the range of 800ns to 1500ns, and under small core conditions, it can be maintained within the range of 1400ns to 2500ns. However, since I / O-intensive workloads have lower requirements for CPU utilization and relatively lower requirements for CPU acquisition performance and frequency, the overhead increase of this method under small core conditions compared to large core conditions is about 20% smaller than that under compute-intensive workloads.

[0105] Existing technology 1 optimizes the perf_event_read_value() algorithm in the Linux_Perf_API by parallelizing data acquisition and reducing the number of interrupts, resulting in a significant reduction in overhead. Our proposed method further innovates and optimizes this method for the ARM heterogeneous multi-core architecture, achieving approximately a 32% reduction in time overhead compared to comparison file 1 under large-core conditions, approximately a 49% reduction compared to the perf_event_read_value() method, and an additional 15% improvement under small-core conditions.

[0106] Based on the PMC data collected by simpleperf, the acquisition error of this method and the perf_event_read_value() method under different loads is calculated, and the results are as follows. Figure 7 As shown, the average error of this method is basically maintained within 1%, which can meet the relevant applications of PMC.

[0107] In summary, this method can achieve high-precision, low-latency PMC acquisition in kernel mode, providing an efficient and accurate PMC acquisition solution for ARM heterogeneous multi-core platforms.

Claims

1. A PMC parallel acquisition method for ARM heterogeneous multi-core processors, characterized in that: Specifically, the following steps are included: Step 1: Initialize and identify the type of the CPU cores undertaking the data acquisition task, create CPU masks for large and small cores, and allocate per-CPU data structures; initialize global synchronization primitives, create a configured PMC event set for each online CPU core, configure and enable performance counters; if user-defined PMC event configurations exist, load the user configurations, otherwise use the system default event configurations. Step 2: Create a dedicated sampling thread for each online CPU core; After all threads are initialized, they enter the ready state and wait. Once the main control thread confirms that all threads are ready, it sends a global start signal. All threads adopt a unified sampling strategy and begin sampling synchronously. Each sampling thread periodically reads the PMC counter value of its bound core. The actual sampling overhead of each core is dynamically measured, and the optimal sampling ratio is calculated in real time based on the load status and core type. Specifically: s2.1 Determine the target CPU core type. For large cores, directly return the baseline ratio of 1.

0. For small cores, first obtain the reference large core, and then measure the actual PMC sampling time overhead_big and overhead_little of the large and small cores respectively. s2.2 Calculate the hardware-specific base ratio R_base = overhead_little / overhead_big; s2.

3. Obtain the utilization rate current_load of the target CPU, and calculate the load perception factor load_factor=f(current_load)=1.0+(current_load-0.5)*α through the load perception function f(), where α represents the sensitivity coefficient; s2.4 Calculate the initial adaptive ratio: adaptive_ratio = R_base × load_factor; Introduce boundary constraints and calculate the dynamic sampling ratio factor: sampling_ratio = max(lb down ,min(lb up ,adaptive_ratio), where max and min represent taking the maximum and minimum values ​​respectively, lb down lb up These represent the lower boundary and the upper boundary, respectively. s2.5 Returns the dynamic sampling ratio factor sampling_ratio after hardware measurement, load awareness and boundary protection, providing intelligent frequency scheduling for heterogeneous multi-core PMC sampling; Step 3: For large and small core PMC data, dynamically adjust the judgment criteria, and after completing the data analysis, send a termination signal to the sampling thread to close performance events, unmap memory, and release resources.

2. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 1, characterized in that: In step 1, a CPU hot-plug callback function is registered via cpuhp_setup_state(). When a core comes online, cpu_online_callback automatically creates a PMU event for the new core and starts monitoring; when a core goes offline, cpu_offline_callback safely stops the relevant monitoring and releases resources.

3. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 1, characterized in that: During the creation of sampling threads, an error handling mechanism is designed: if thread creation fails, the created threads are stopped in a loop and a failure is returned; after thread creation is completed, wake_up_process() is used to wake up all threads to start executing the initialization logic; then wait_event_timeout() is called to wait for all threads to enter the ready state, ensuring that all threads complete the necessary preparation work before sampling begins; when all threads are ready, a global start flag is set, and wake_up_all() is used to wake up the waiting threads, triggering the synchronous start of parallel sampling; if not all threads are ready after the timeout, an error is reported and failure is returned.

4. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 1, characterized in that: During the sampling process, for large cores, the standard sampling frequency is maintained; for small cores, a reference large core is obtained through cpumask_first(), and the actual PMC sampling time overhead (overhead_big) and overhead_little of the reference large core and small core are measured respectively using ktime_get() in conjunction with execute_pmc_sampling(), and the adaptive sampling ratio (adaptive_ratio) is calculated to control the sampling ratio of the small core.

5. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 4, characterized in that: The adaptive sampling ratio, adaptive_ratio, is: adaptive_ratio=R_base×load_factor R_base=overhead_little / overhead_big load_factor=f(current_load) Where R_base represents the hardware-specific base ratio, load_factor represents the load-aware factor, current_load represents the utilization of the target CPU, and f() represents the load-aware function.

6. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 5, characterized in that: The load sensing function f() satisfies: ① When the target CPU utilization current_load=0.5, f(0.5)=1.0; ② When the target CPU utilization current_load = 1.0, f(1.0) > 1.0; ③ When the utilization of the target CPU current_load → 0.0, f(0.0) < 1.

0.

7. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 5, characterized in that: Based on the adaptive sampling ratio (adaptive_ratio), boundary constraints are introduced to calculate the dynamic sampling ratio factor (sampling_ratio): sampling_ratio= max(lb down ,min(lb up ,adaptive_ratio)) Where max and min represent taking the maximum and minimum values ​​respectively, lb down lb up These represent the lower boundary and the upper boundary, respectively. The sampling ratio of the small core is controlled by the dynamic sampling ratio factor sampling_ratio.

8. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 1, characterized in that: In the data analysis phase of step 3, all online CPUs in the system are traversed through a loop structure. For each CPU, its unique PMC data structure is first obtained, and the core data that has been sampled is filtered out by judging the sampling completion flag. Then, the type of the current CPU is determined by the core type mask. Statistical analysis is performed on each PMC event on the CPU, and its Z score z_score is calculated. Different thresholds are set for large cores and small cores. When the number of events with z_score > threshold in a certain sampling point reaches a preset statistical threshold, the sampling point is marked as abnormal and recorded.

9. The PMC parallel acquisition method for an ARM heterogeneous multi-core processor as described in claim 8, characterized in that: For small cores, set the threshold to... ~ For large cores, set the threshold to [value]. ~ This represents the standard deviation of PMC events.

10. A PMC parallel acquisition system based on an ARM heterogeneous multi-core processor, characterized in that: It includes a system initialization and configuration module, a data acquisition and monitoring module, and a data processing and system termination module; The system initialization and configuration module includes an IPH unit and a CHPE unit; the IPH unit is used to identify, classify and initialize the CPU cores that undertake the acquisition task, and call the CHPE unit to form a set of acquisition events for the PMUs to be acquired. The data acquisition and monitoring module includes an SHPS unit, an EPSC unit, and a CSPR unit. The SHPS unit allocates acquisition tasks based on the event set content and the big / small core structure packaged by the EPSC unit. The EPSC unit collects CPU utilization and sampling data during the acquisition process, calls the CSPR unit, calculates the dynamic sampling factor, and returns it to the SHPS unit to adjust the sampling frequency of the big and small cores. Finally, the sampled raw PMC data is transmitted to the data processing and system termination module. Specifically, the target CPU core type is first determined. For big cores, a baseline ratio of 1.0 is returned directly. For small cores, after obtaining the reference big core, the actual PMC sampling time overhead_big and overhead_little of the big and small cores are measured respectively, and the hardware-specific base ratio R_base = overhead_little / overhead_big is calculated. Then, the target CPU utilization current_load is obtained, and the load perception factor load_factor = f(current_load) = 1.0 + (current_load - 0.5) * α is calculated through the load perception function f(), where α represents the sensitivity coefficient. The initial adaptive ratio is calculated and boundary constraints are introduced to calculate the dynamic sampling ratio factor sampling_ratio. The data processing and system termination module includes a PPDA unit and an SPR unit; the PPDA unit performs statistical analysis on the raw PMC data input from the EPSC unit, and stores the PMC data into memory space after confirming that there is no abnormal data; the SPR unit is used for the recycling and cleanup of all system resources after the data collection task is completed.

Images