Hardware event group scheduling method of computer processor performance monitoring unit

Abstract

The invention discloses a hardware event group scheduling method for a computer processor performance monitoring unit. The method comprises the following steps: S1, acquiring an event group set and the number of counters; s2, performing descending sorting on the event groups according to the number of events by using a non-incremental sorting strategy; s3, initializing an empty round; s4, iteratively distributing the event group to an existing round or creating a new round; and S5, outputting the round set of the existing round or the new round obtained in the step S4 as a scheduling scheme of the event group on a performance monitoring counter, and the method has the advantages that a hardware event group scheduling problem is converted into a one-dimensional boxing problem, and a non-incremental sorting strategy and an iterative greedy distribution strategy are utilized, so that the time complexity of a hardware event scheduling process is remarkably reduced, and the scheduling efficiency is improved. A low-overhead and high-precision performance data observation scheme is constructed, on the premise that accuracy is guaranteed, efficient execution of large-scale performance analysis tasks is achieved, and performance monitoring efficiency and system performance observation precision are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to a computer system performance monitoring method, in particular to a hardware event group scheduling method of a computer processor performance monitoring unit. BACKGROUND

[0002] In the field of computer system performance monitoring, performance sampling tools (such as Linux perf) need to interact with performance monitoring units (PMUs). The interaction mode is to schedule limited performance monitoring counter (PMC) resources according to pre-defined event groups of upper indicators, using time-sharing strategy, to schedule event groups to PMCs, organize different rounds, and finally convert the raw count data collected by PMUs into corresponding upper-level high-level performance indicators according to specific formulas. Common performance monitoring tools, such as Perf, LIKWID and PAPI, all use time division multiplexing technology to schedule hardware event groups to PMCs to achieve efficient tracking of multiple indicators. They often use fixed event group division like LIKWID or kernel scheduling defects like Linux perf, resulting in underutilization of general PMCs. For example, Linux perf, when scheduling 8 events, due to idle fixed PMCs and allocation failure of general PMCs, the total sampling ratio drops from 700% to 625%.

[0003] Current mainstream performance analysis methods, such as multi-level top-down microarchitecture analysis (TMA), face complex hardware event scheduling challenges in the implementation process. Taking TMA as an example, this type of method needs to monitor dozens or even hundreds of hardware events simultaneously by layer-by-layer disassembly of system performance bottlenecks, covering multiple microarchitecture dimensions such as instruction pipeline, cache hierarchy, memory subsystem, and then calculating dozens of performance indicators such as instruction cycle number (CPI), cache miss rate (MPKI), branch prediction error rate, etc. These events need to be sampled through performance monitoring counters (PMCs), but the number of PMCs in modern processors is usually only 4-16 (such as Intel Xeon series containing 3-4 fixed PMCs and 4-8 general PMCs, and Arm processors generally have 1 fixed PMC and 6-12 general PMCs), resulting in the need to schedule event groups in rounds through time division multiplexing (Time Multiplexing) technology.

[0004] However, the existing PMCs time division multiplexing method has a significant problem of low resource utilization efficiency. Specifically, it shows that:

[0005] 1. Unreasonable event group division leads to PMC idling:

[0006] Mainstream tools (such as Linux perf and LIKWID) often employ a predefined event group strategy, but the number of events per group is far less than the capacity of the PMC (Programmable Controller). For example, LIKWID's predefined event groups typically contain only 2-4 events, while the general number of PMCs on an Intel Cascade Lake processor is 4. This results in an actual PMC utilization rate of only 50%-100% in a single round of scheduling (50% utilization if the event group contains 2 events). When monitoring 100 events, it needs to be divided into 25-50 event groups, leading to a surge in rounds.

[0007] 2. Round redundancy and observation window shrinkage:

[0008] Inefficient event grouping directly increases the number of scheduling rounds. Assuming a scenario requires monitoring 60 events, with a general PMC count of 4, the theoretical minimum number of rounds is 15. However, existing methods, due to unoptimized event groups (e.g., each group contains only 2 events), may actually require up to 30 rounds. Each scheduling round consumes a fixed amount of time (e.g., the default scheduling interval in Linux perf is 4ms), increasing the total observation time from 15 × 4ms = 60ms to 30 × 4ms = 120ms. This doubles the observation window, but halves the effective sampling count per unit time.

[0009] 3. Data distortion under workload fluctuations:

[0010] When the tested workload exhibits performance fluctuations (such as periodic loads or abrupt changes in cache behavior), expanding the observation window can introduce time misalignment errors. For example, if an application experiences two phases (50ms each) of "high load - low load" within 100ms, and a 30-round scheduling (total time 120ms) is used, the event sampling during the high load phase may be scattered across multiple rounds, causing the raw counts to fail to accurately reflect instantaneous performance characteristics. Furthermore, Linux perf's polling scheduling strategy does not distinguish between fixed PMCs and general PMCs, potentially leading to fixed PMCs being idle in some rounds, further exacerbating resource waste and sampling bias (e.g., experiments show that fixed PMC utilization is only 62.5%-87.5% with 8-event scheduling).

[0011] 4. Reduced sampling ratio and error accumulation:

[0012] The core formula for time-division multiplexing is In the formula, c^ represents the final count result, c raw For the original count, t enabled For the sampling time of a single event group, t total For the total sampling time, this formula depends on the sampling ratio t. enabled / t total The accuracy of the sampling time t for a single event group increases with the number of rounds.enabled Shorten (such as 30 rounds of scheduling, each group accounts for only 3.3%), original count c raw Statistical noise may occur due to insufficient sampling. Especially for low frequency events (such as TLB miss), small sampling ratio will cause the count result to approach zero, which cannot reflect the real load characteristics, and finally lead to more than 20% error of performance indicators, such as ITLB MPKI indicator error even up to 60% in some scenarios.

[0013] The following is a typical case of prior art: in SPEC CPU 2017 benchmark test, when monitoring 8 events using Linux perf, the sampling ratio of fixed PMC event cpu_clk_unhalted.thread is reduced from 100% when 7 events to 75.15% when 8 events, and the sampling ratio of general PMC event itlb_misses.stlb_hit fluctuates by 37.5%, which directly leads to the deviation of CPI, cache miss rate and other indicators from the true value. Such problems are particularly prominent in cloud native, real-time computing and other workload fluctuation frequent scenarios, which may mislead the performance optimization direction and even miss the key bottleneck point. SUMMARY

[0014] The technical problem to be solved by the present application is to provide a hardware event group scheduling method for a computer processor performance monitoring unit, which can improve the performance monitoring efficiency and system performance observation accuracy.

[0015] The technical solution adopted by the present application to solve the above technical problem is: a hardware event group scheduling method for a computer processor performance monitoring unit, the scheduling method comprising the following steps:

[0016] S1. Obtain an event group set and a counter number;

[0017] S2. Sort the event groups in descending order according to the number of events using a non-decreasing sorting strategy;

[0018] S3. Initialize an empty round;

[0019] S4. Iteratively distribute event groups to existing rounds or create new rounds;

[0020] S5. Output the round set of the existing round or the new round obtained in step S4 as the scheduling scheme of the event groups on the performance monitoring counter.

[0021] Compared with the prior art, the advantages of the present application are that the hardware event group scheduling method of the computer processor performance monitoring unit based on the bin packing theory is provided to solve the problems of long search time and low efficiency of the existing hardware event group scheduling algorithm in large-scale performance analysis scenarios, the scheduling strategy of the hardware event group on the PMC is optimized, the hardware event group scheduling problem is converted into a one-dimensional bin packing problem, the non-decreasing sorting strategy and the iterative greedy allocation strategy are used to realize the efficient scheduling of the hardware event group on the performance monitoring counter (PMC), the time complexity of the hardware event scheduling process is significantly reduced, the low-overhead and high-precision performance data observation scheme is constructed, the efficient execution of the large-scale performance analysis task is realized under the premise of ensuring the accuracy, and the performance monitoring efficiency and the precision of the system performance observation are improved.

[0022] 1. The one-dimensional bin packing theory is used for modeling, the best approximation ratio is realized by the algorithm, and the scheduling round is close to the theoretical minimum R min , which significantly improves the utilization rate of the PMC resource, and the utilization rate of the PMC resource on the Intel IceLake platform is improved by 25%.

[0023] 2. Compared with the existing algorithm, the time complexity of the scheduling process is greatly reduced, and the near-optimal solution can be quickly generated in the large-scale performance analysis scenario.

[0024] 3. The round switching overhead is reduced, the observation window fluctuation influence is reduced, the accuracy of the performance data collection is ensured, the data accuracy on the Intel IceLake platform is improved by 40%, and a more reliable basis is provided for system performance optimization.

[0025] The scheduling method is specifically as follows:

[0026] S1. Input acquisition: acquire the hardware event group set G={G1, G2, …, G i , G N} and the number of general performance monitoring counters C, wherein each event group G i contains events, i is the serial number of the hardware event group, is a positive integer from 1 to N, and N is the total number of hardware event groups;

[0027] S2. Event group sorting: the event groups are sorted in a non-decreasing order according to the number of events; m=1 when the event group has the maximum number of events, m=M when the event group has the minimum number of events, and the sorted event groups satisfy the relationship:

[0028] S3. Initialize empty rounds: define the round set as R={r j}, wherein j is the iteration number, let j = 1, create an initial round set R = { r1}, r1 is an empty round and is defined as the current round;

[0029] S4. Iterative distribution:

[0030] S4-1. Traverse the sorted event groups ;

[0031] S4-2. For the current round in the set R, check whether the remaining capacity of the performance monitoring counter can accommodate the current is yes, add to the current round and enter S4-3, otherwise add 1 to the iteration number, create a new round, and add the new round to the set R as the new current round, and add to the new current round and enter S4-3;

[0032] S4-3. Determine whether the traversal of all event groups is completed, yes enter S5, otherwise return to S4-1;

[0033] S5. Output result: take the round set R after traversing all event groups as the scheduling scheme of the event groups on the performance monitoring counter. DETAILED DESCRIPTION

[0034] The application will be further described in detail below in combination with examples.

[0035] Embodiment:

[0036] A hardware event group scheduling method of a computer processor performance monitoring unit, the scheduling method specifically comprises:

[0037] S1. Input acquisition: acquire a hardware event group set G = { G1, G2, … G i ,…,G N} and a general performance monitoring counter number C, wherein each event group G i contains events, i is the serial number of the hardware event group, which is a positive integer from 1 to N, and N is the total number of hardware event groups;

[0038] S2. Event group sorting: sort the event groups in a non-decreasing order according to the number of events; define m = 1 when the event group has the maximum number of events, and m = M when the event group has the minimum number of events, and the sorted event groups satisfy the relationship:

[0039] S3. Initialize an empty round: define a round set as R = { r j}, wherein j is the iteration number, let j = 1, create an initial round set R = { r1}, r1 is an empty round and is defined as the current round;

[0040] S4. Iterative distribution:

[0041] S4-1. Traverse the sorted event groups;

[0042] S4-2. For the current round in set R, check if the remaining capacity of the performance monitoring counter can accommodate the current Yes, add to the current round and go to S4-3, otherwise, add 1 to the iteration number, create a new round, and add the new round to set R as the new current round, and add to the new current round and go to S4-3;

[0043] S4-3. Determine if all event groups have been traversed, yes, go to S5, otherwise, return to S4-1;

[0044] S5. Output the result: the round set R after traversing all event groups is the scheduling scheme of the event groups on the performance monitoring counter.

[0045] The following is a specific example.

[0046] Suppose an Intel IceLake processor, which has 8 general performance monitoring counters (PMCs), that is, C = 8, and needs to monitor the following 12 hardware events, which are divided into 4 event groups, that is, N = 4:

[0047] · Event group G1: contains 3 events,

[0048] · Event group G2: contains 5 events,

[0049] · Event group G3: contains 2 events,

[0050] · Event group G4: contains 2 events,

[0051] The goal of the method of the present application is to optimize the scheduling strategy of event groups on PMCs, to reduce the number of rounds as much as possible and improve the utilization of performance monitoring counters PMCs.

[0052] Step 1: Obtain the hardware event group set G = {G1(3), G2(5), G3(2), G4(2)} and the number of general performance monitoring counters C = 8;

[0053] Step 2: Sort the event groups in non-decreasing order by the number of events; the maximum number of events is 5 and the minimum number of events is 2, the sorted event groups are {G2(5), G1(3), G3(2), G4(2)};

[0054] Step 3: Define the round set as R = {r j ​}, where j is the iteration number, let j = 1, create the initial round set R = {r1}, r1 is an empty round and is defined as the current round;

[0055] Step 4: Iterative allocation:

[0056] Traverse the sorted event groups, first allocate G2(5) to r1, check the remaining capacity of the performance monitoring counter C-r1=3, judge that the event group has not completed traversal, try to allocate G1(3) to r1, succeed, the remaining capacity C-r1=0, add 1 to the iteration number to create a new round r2, and add it to the set R as the new current round, judge that the event group has not completed traversal, allocate G3(2) to r2, the remaining capacity C-r2=6, judge that the event group has not completed traversal, try to allocate G4(2) to r2, succeed, the remaining capacity C-r2=4; At this time, it is judged that the traversal of all event groups has been completed, and step 5 is entered;

[0057] Step 5. Output result: the round set R = {r1{G2(5), G1(3)}, r2{G3(2), G4(2)}} is taken as the scheduling scheme of the event group on the performance monitoring counter.

Claims

1. A hardware event group scheduling method for a computer processor performance monitoring unit, characterized in that... The scheduling method includes the following steps: S1. Get the event group set and the counter count; S2. Sort the event groups in descending order by the number of events using a non-increasing sorting strategy; S3. Initialize empty rounds; S4. Iteratively assign event groups to existing rounds or create new rounds; S5. Output the set of existing or new rounds obtained in step S4 as the scheduling scheme of the event group on the performance monitoring counter.

2. The hardware event group scheduling method for a computer processor performance monitoring unit as described in claim 1, characterized in that... The scheduling method is specifically as follows: S1. Input Acquisition: Acquire the hardware event group set G = {G1, G2, ..., G...} i ,…,G N } and the number of general performance monitoring counters C, where each event group G i Include There are 10 events, where i is the sequence number of the hardware event group, which is a positive integer from 1 to N, and N is the total number of hardware event groups. S2. Event Group Sorting: Sort event groups in non-increasing order by the number of events; define m=1 for the event group with the maximum number of events, and m=M for the event group with the minimum number of events. The sorted event groups satisfy the following relation: S3. Initialize empty rounds: Define the round set as R = {r j }, where j is the iteration number. Let j = 1, create an initial set of rounds R = {r1}, where r1 is an empty round and is defined as the current round; S4. Iterative Allocation: S4-1. Sorted event groups Perform a traversal; S4-2. For the current round in set R, check if the remaining capacity of the performance monitoring counter can accommodate the current round. This will If the current iteration is added and proceeds to S4-3, otherwise the iteration count is incremented by 1 and a new iteration is created, which is then added to set R as the new current iteration. Join the new current round and enter S4-3; S4-3. Determine whether all event groups have been traversed. If yes, proceed to S5; otherwise, return to S4-1. S5. Output: The round set R after traversing all event groups is used as the scheduling scheme for the event groups on the performance monitoring counter.