A method and system for optimizing congestion of multi-processor cross-chip interconnect

Abstract

The application discloses a kind of multi-processor cross-chip interconnection congestion optimization method and system, characterized in that by synchronously collecting the interconnection bus index of processor non-core side and the memory access instruction sampling record of core side, whether it meets congestion trigger condition is judged in real time;When congestion, interconnection bus pressure curve and the memory access pressure curve of each process are constructed, the linear correlation between curves, the peak time coincidence degree and the peak window contribution proportion are calculated, the comprehensive attribution score is obtained and the bottleneck process is screened out;According to the bottleneck process feature, thread affinity binding or memory bulk migration based on improved move_pages2 interface is dynamically selected to optimize;If congestion is not alleviated, secondary hardware flow limiting is triggered;The advantage is that cross-chip congestion can be actively located and eliminated before performance inflection point, which greatly reduces tail delay, improves throughput and stability.

Description

Technical Field

[0001] This invention relates to the field of computer system performance tuning technology, and in particular to an optimization method and system for multiprocessor cross-chip interconnect congestion. Background Technology

[0002] With the widespread adoption of Non-Uniform Memory Access (NUMA) architecture in modern multi-processor servers, processors exchange data across chips via high-speed interconnect buses (such as Intel UPI, AMD Infinity Fabric, or ARMHCCS). While the Auto-NUMA mechanism built into operating systems (such as Linux) attempts to dynamically balance memory layout by monitoring memory access frequency, its optimization logic revolves entirely around memory access frequency and cannot perceive the congestion status of the physical interconnect bus in real time, such as bandwidth saturation and queuing latency on data links. This neglect of the underlying physical interconnect status makes it difficult for the system to make optimal task and memory scheduling decisions when facing peak cross-chip communication.

[0003] On the other hand, traditional system monitoring tools (such as sar) can only provide macro-level bus utilization statistics. They not only cannot accurately attribute high traffic loads to specific process controllers, but also lack the ability to predict congestion evolution. In practical applications, these tools usually intervene only after system throughput has already dropped sharply, i.e., after the performance inflection point has occurred. As a result, they cannot avoid severe tail latency jitter caused by interconnect congestion, which seriously affects the quality of service and response determinism of multiprocessor systems under high load. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide an optimization method and system for multiprocessor cross-chip interconnect congestion, which can detect the physical congestion status of the cross-chip interconnect bus in real time and accurately attribute it to specific processes, thereby proactively implementing optimization before the performance inflection point occurs to avoid severe tail delay jitter.

[0005] The technical solution adopted by this invention to solve the above-mentioned technical problem is: an optimization method for multiprocessor cross-chip interconnect congestion, comprising the following steps: Step 1: Based on the processor instruction cycle, synchronously collect interconnect bus indicators on the non-core side of the processor and memory access instruction sampling records on the core side of the processor. Step 2: Based on the collected interconnect bus metrics and memory access instruction sampling records, determine in real time whether the cross-chip interconnect bus meets the congestion triggering conditions. If yes, proceed to step 3; otherwise, return to step 1. Step 3: Perform differential, normalization, and time-series processing on the interconnect bus indicators according to the preset time window to obtain the interconnect bus pressure curve; perform weighted aggregation on the memory access instruction sampling records according to the preset time window to obtain the process-level memory access pressure curve corresponding to each process; obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve of each process, and calculate the comprehensive attribution score accordingly; select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low. Step 4: Based on the running characteristics and memory overhead of the bottleneck process, dynamically select thread affinity binding or memory batch migration as optimization methods to optimize the bottleneck process. Step 5: Continuously monitor the interconnect bus indicators within the set observation window period to determine whether the cross-chip interconnect bus congestion has been alleviated. If yes, exit the optimization process; if no, trigger the secondary hardware rate limiting mechanism. Based on the service level identifier carried in the memory access request of the bottleneck process, call the hardware resource allocation interface to implement instantaneous bandwidth limiting and return to execute step 1.

[0006] Compared with existing technologies, the advantages of this invention lie in its ability to simultaneously collect interconnect bus metrics from the non-core side of the processor and memory access instruction sampling records from the core side. This allows for real-time perception of the physical congestion status of the interconnect bus at the instruction cycle granularity, rather than relying solely on memory access frequency. This overcomes the shortcomings of traditional Auto-NUMA mechanisms, which are completely unaware of underlying bus bandwidth saturation and queuing latency. Furthermore, by performing multi-dimensional comprehensive analysis of the interconnect bus pressure curve and the memory access pressure curve of each process—including linear correlation, peak time overlap, and peak window contribution ratio—a comprehensive attribution score is calculated to accurately locate the bottleneck process causing congestion. This solves the problem that traditional monitoring tools can only provide macroscopic bus utilization but cannot pinpoint high-level congestion processes. The problem of attributing traffic to specific process controllers is addressed. Since the entire attribution and optimization process is proactively initiated upon meeting congestion triggering conditions, it can intervene before the system throughput reaches a performance inflection point with a sharp decline. Optimization of bottleneck processes is achieved through dynamic selection of thread affinity binding or batch memory migration. When the aforementioned soft optimization methods fail to fully alleviate congestion, this invention triggers a secondary hardware rate limiting mechanism. Based on the service level identifier in the bottleneck process's memory access request, it calls the hardware resource allocation interface to implement instantaneous bandwidth limiting, forming a hierarchical protection chain from soft attribution to soft optimization to hard rate limiting. Ultimately, this achieves efficient, stable, and closed-loop optimization of cross-chip interconnect congestion in multiprocessor systems under high load. Experimental data shows that, in the Flink TPC-H 50GB test scenario, this invention significantly reduces the P99 tail latency from 520.4ms to 135.2ms compared to the native Auto-NUMA mechanism, an improvement of 74.0%. Simultaneously, the average throughput increases from 12,400 Requests / s to 18,900 Requests / s, an improvement of 52.4%. The average utilization of the cross-chip bus decreases from 88.50% to 62.10%, and the queuing latency ratio decreases from 0.58 to 0.18, representing reductions of 26.4% and 68.9% respectively. Furthermore, the QPS stability variance shrinks from 850.2 to 120.5, a reduction of 85.8%, significantly alleviating tail latency jitter and improving service response determinism.

[0007] Furthermore, in step 1, the interconnect bus metrics include one or more of the following: transmit direction flow control unit count, cross-chip link throughput, interconnect request retry count, interconnect request queuing cycle count, link active cycle count, and remote memory access request count; the memory access instruction sampling record includes one or more of the following: sampling timestamp or processor cycle count, process identifier, thread identifier, processor core number, instruction address, memory access type, memory access address, memory access latency, cache hit status, memory access source information, and local or remote NUMA node identifier. This allows for a comprehensive description of the bus physical congestion state (such as retries, queuing cycles, and remote memory access frequency) from different dimensions, as well as precise association with specific processes, threads, cores, and NUMA nodes. This provides a rich and accurate data foundation for subsequent congestion determination and bottleneck process attribution, significantly improving the coverage and location accuracy of the analysis.

[0008] Furthermore, in step 2, the congestion triggering condition is that the bus utilization rate is greater than 75% and the queuing delay ratio exceeds a preset threshold; wherein the bus utilization rate is calculated according to the formula... get, This indicates the average response time for an interconnect bus request. This indicates the peak processing capacity of the bus per unit time. This indicates bus utilization; queuing delay percentage is calculated using the formula. get, Indicates the percentage of queuing delays. This indicates the number of cycles that a bus request has been pending / queued in the buffer. This indicates the number of cycles the bus is in an active transmission state. It avoids misjudgments or omissions caused by a single metric, ensuring that the optimization process is only initiated when bus pressure significantly increases and actual queuing begins, thus enabling accurate prediction of performance inflection points.

[0009] Furthermore, the specific operation process of step 3 is as follows: First, the interconnect bus indicators are differentially divided according to the preset time window to obtain the count increment within each time window. Each count increment is divided by the length of the time window to obtain the interconnect bus pressure value per unit time. The interconnect bus pressure values ​​per unit time corresponding to all time windows are normalized and arranged in chronological order of the start time of the time window to form the interconnect bus pressure curve. Meanwhile, the memory access instruction sampling records are weighted and aggregated according to the same preset time window: for each memory access instruction sampling record, the sampling weight is set according to one or more factors among memory access type, memory access latency, whether it is a remote NUMA access, cache hit status, micro-operation overhead and processor current operating frequency compensation coefficient, and the sampling weights belonging to the same process identifier are accumulated in the corresponding time window to obtain the weighted memory access pressure value of the process in the time window. The weighted memory access pressure values ​​of each time window are arranged in chronological order of the start time of the time window to form the process-level memory access pressure curve corresponding to each process; Subsequently, the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve for each process were calculated. Based on these factors, a comprehensive attribution score was calculated for each process. The top N processes, ranked by their comprehensive attribution scores from highest to lowest, were selected as bottleneck processes. The comprehensive attribution score of the i-th process was denoted as... , , This is an indicator of the linear correlation between the process-level memory access pressure curve of the i-th process and the interconnect bus pressure curve. The peak time overlap between the process-level memory access pressure curve and the interconnect bus pressure curve of the i-th process is denoted as . Let α represent the contribution percentage of the i-th process within the peak window of the interconnect bus pressure curve, and let α, β, and γ be the corresponding weighting coefficients, where α ≥ 0, β ≥ 0, γ ≥ 0, and α + β + γ = 1. This approach comprehensively measures the causal relationship of each process to interconnect congestion from three perspectives: consistency of time trends, degree of peak alignment, and contribution during peak periods. This allows for accurate identification of the true bottleneck process, avoiding misattribution that might result from relying solely on a single correlation indicator.

[0010] Furthermore, in step 4, when the bottleneck process is characterized as a short-running or computationally intensive task, and its memory overhead is less than a preset memory threshold, thread affinity binding is selected as an optimization method: by calling the taskset interface, the target process is forced to run on the same processor core. This achieves fast and lightweight mitigation of specific types of congestion.

[0011] Furthermore, in step 4, when the bottleneck process is characterized by long-duration, large-data tasks, and its memory overhead consists of high-frequency remote memory accesses with memory usage exceeding a preset memory threshold, then memory batch migration based on the `move_pages2` interface is chosen as an optimization method: the process's physical memory pages are moved from remote NUMA nodes to the local memory node where the processor core currently running the process resides. This fundamentally eliminates the need for cross-chip access, reduces interconnect bus utilization, and because the task duration is long, the overhead of the migration can be offset by the subsequent significant reduction in cross-chip latency, thus achieving significant net performance gains.

[0012] Furthermore, the interface move_pages2 includes a batching mechanism: merging contiguous physical memory pages for processing, reducing the performance overhead of system calls and TLB refreshes.

[0013] Furthermore, the `move_pages2` interface includes an exception skipping strategy: if individual physical memory pages fail during migration due to locking or restricted permissions, only the error code is recorded, and processing of subsequent physical memory pages continues. This exception skipping strategy avoids the fragile "one page failure, complete shutdown" pattern of traditional methods. Even if a small number of pages cannot be migrated, the migration operation can still complete the relocation of the vast majority of remaining pages, thereby reducing the task interruption rate caused by migration failures to an extremely low level and ensuring the robustness and availability of the optimized process.

[0014] Furthermore, the mitigation in step 5 refers to a bus utilization rate ≤75% and a queuing delay percentage not exceeding a preset threshold. This ensures the convergence and adaptability of the optimization process, avoiding optimization oscillations or resource waste caused by ambiguous exit conditions.

[0015] An optimization system for multiprocessor cross-chip interconnect congestion includes a multi-dimensional data monitoring module, a congestion trigger determination module, a correlation traffic attribution module, a strategy execution module, and a feedback module. The multidimensional data monitoring module is connected to the hardware performance monitoring unit and is used to synchronously collect interconnect bus indicators on the non-core side of the processor and memory access instruction sampling records on the core side of the processor based on the processor instruction cycle. The congestion trigger determination module is used to determine in real time whether the cross-chip interconnect bus meets the congestion trigger conditions based on the collected interconnect bus indicators and memory access instruction sampling records. If yes, the correlation traffic attribution module is executed; if no, the multi-dimensional data monitoring module is returned to be executed. The aforementioned correlation traffic attribution module is used to perform differential, normalization, and time-series processing on interconnect bus indicators according to a preset time window to obtain the interconnect bus pressure curve; to perform weighted aggregation on memory access instruction sampling records according to a preset time window to obtain the process-level memory access pressure curve corresponding to each process; to obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve of each process, and to calculate the comprehensive attribution score accordingly, and select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low; The strategy execution module is used to dynamically select thread affinity binding or memory batch migration as optimization methods based on the running characteristics and memory overhead of the bottleneck process, so as to optimize the bottleneck process. The feedback module is used to continuously monitor the interconnect bus indicators within the set observation window period to determine whether the cross-chip interconnect bus congestion has been alleviated. If so, the optimization process is exited; if not, a secondary hardware rate limiting mechanism is triggered. Based on the service level identifier carried in the memory access request of the bottleneck process, the hardware resource allocation interface is called to implement instantaneous bandwidth limiting and return to the execution multi-dimensional data monitoring module. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall process of the present invention; Figure 2 This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0018] like Figure 1 As shown, an optimization method for multiprocessor cross-chip interconnect congestion includes the following steps: Step 1: Based on the processor instruction cycle, synchronously collect interconnect bus metrics on the non-core side of the processor and memory access instruction sampling records on the core side of the processor. Interconnect bus metrics refer to hardware count data collected by the performance monitoring unit of the non-core side of the processor or the on-chip interconnect system, used to characterize the load status of cross-processor or cross-chip interconnect links. Interconnect bus metrics include one or more of the following: send direction flow control unit count, cross-chip link throughput, interconnect request retry count, interconnect request queuing cycle count, link active cycle count, and remote memory access request count. Memory access instruction sampling records are collected on the core side through precise event sampling mechanisms such as Intel PEBS or ARM SPE. Memory access instruction sampling records include one or more of the following: sampling timestamp or processor cycle count, process identifier, thread identifier, processor core number, instruction address, memory access type, memory access address, memory access latency, cache hit status, memory access source information, and local or remote NUMA node identifier. The process identifier and thread identifier are obtained by associating the sampling records with the operating system scheduling context.

[0019] Step 2: Based on the collected interconnect bus metrics and memory access instruction sampling records, determine in real time whether the cross-chip interconnect bus meets the congestion triggering conditions. If yes, proceed to Step 3; otherwise, return to Step 1. The congestion triggering conditions are: bus utilization greater than 75% and queuing delay percentage exceeding a preset threshold. Bus utilization is calculated using the formula... get, This indicates the average response time for an interconnect bus request. This indicates the peak processing capacity of the bus per unit time. This indicates bus utilization; queuing delay percentage is calculated using the formula. get, Indicates the percentage of queuing delays. This indicates the number of cycles that a bus request has been pending / queued in the buffer. This indicates the number of cycles in which the bus is in an active transmission state. The preset threshold range is set between 0.2 and 0.5, and the default value is set to 0.35. It can be dynamically adjusted according to the system's sensitivity to latency.

[0020] Step 3: Perform differential, normalization, and time-series processing on the interconnect bus metrics according to a preset time window to obtain the interconnect bus pressure curve; perform weighted aggregation on the memory access instruction sampling records according to a preset time window to obtain the process-level memory access pressure curve corresponding to each process; obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve for each process, and calculate the comprehensive attribution score accordingly. Select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low. In this embodiment, N=5. The specific operation process is as follows: First, the interconnect bus indicators are differentially analyzed according to preset time windows to obtain the count increment within each time window. Each count increment is then divided by the length of the time window to obtain the interconnect bus pressure value per unit time. The interconnect bus pressure values ​​per unit time corresponding to all time windows are then normalized and arranged in chronological order of their start times to form an interconnect bus pressure curve. The specific operation process is as follows: The current attribution observation window is divided into M consecutive time windows according to the time window length Δt, where M = T / Δt. The current attribution observation window refers to the most recent sliding time interval used to construct the interconnect bus pressure curve and the process-level memory access pressure curve. Its length is denoted as T, with a preferred value range of 10s to 60s and a default value of 30s. The preset time window length is denoted as Δt, with a preferred value range of 100ms to 5s and a default value of 1s. For example, when T = 30s and Δt = 1s, the current attribution observation window is divided into 30 time windows, k = 1, 2, ..., 30. The increment of the count of the q-th hardware count data in the k-th time window is denoted as ΔC_{q,k}. This increment is divided by the time window length Δt to obtain the unit time index value v_{q,k} of the q-th hardware count data in the k-th time window. The calculation formula is: v_{q,k}=ΔC_{q,k} / Δt, where q represents the sequence number of the hardware count data, q=1,2,…,Q, Q represents the number of hardware count data included in the interconnect bus index, and Q≥2, k represents the k-th time window in the current attribution observation window, and the value of k is 1≤k≤M; Since the dimensions and value ranges of different hardware count data are different, range normalization is performed on the unit-time index value of each hardware count data within the current attribution observation window to obtain the normalized index value Z_{q,k}. The calculation formula is: Z_{q,k}=(v_{q,k}-v_{q,min}) / (v_{q,max}-v_{q,min}+ε), where v_{q,min} and v_{q,max} represent the minimum and maximum unit-time index values ​​of the q-th hardware count data within all time windows in the current attribution observation window, respectively, and ε is a minimal constant to prevent the denominator from being zero; the default value is 10. -9 ; After normalizing the hardware count data, the normalized index values ​​within the same time window are weighted and summed according to preset weights to obtain the normalized integrated interconnect bus pressure value B_k corresponding to the k-th time window. The calculation formula is: B_k=Σ_{q=1}^{Q}λ_qZ_{q,k}, where B_k represents the normalized integrated interconnect bus pressure value corresponding to the k-th time window within the current attribution observation window; λ_q represents the weight coefficient corresponding to the q-th hardware count data, λ_q≥0, and Σ_{q=1}^{Q}λ_q=1. In this embodiment, when the hardware count data includes cross-chip link throughput, interconnect request queuing cycle count, interconnect request retry count, and remote memory access request count, the corresponding weights can be set to 0.4, 0.3, 0.2, and 0.1, respectively; or they can be dynamically adjusted according to processor platform characteristics, service latency sensitivity, or system optimization strategy. Finally, the normalized integrated interconnect bus pressure values ​​B_1, B_2, ..., B_M corresponding to each time window within the current attribution observation window are arranged in chronological order of their start times, forming the interconnect bus pressure curve B={B_1, B_2, ..., B_M}.

[0021] Meanwhile, the memory access instruction sampling records are weighted and aggregated according to the same preset time window: for each memory access instruction sampling record, the sampling weight is set according to one or more factors among memory access type, memory access latency, whether it is a remote NUMA access, cache hit status, micro-operation overhead and processor current operating frequency compensation coefficient, and the sampling weights belonging to the same process identifier are accumulated in the corresponding time window to obtain the weighted memory access pressure value of the process in the time window. The weighted memory access pressure values ​​of each time window are arranged in chronological order of the start time of the time window to form the process-level memory access pressure curve corresponding to each process; Subsequently, the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve for each process were calculated. Based on these factors, a comprehensive attribution score was calculated for each process. The top N processes, ranked by their comprehensive attribution scores from highest to lowest, were selected as bottleneck processes. The comprehensive attribution score of the i-th process was denoted as... , , This is an indicator of the linear correlation between the process-level memory access pressure curve of the i-th process and the interconnect bus pressure curve. The peak time overlap between the process-level memory access pressure curve and the interconnect bus pressure curve of the i-th process is denoted as . The contribution percentage of the i-th process within the peak window of the interconnect bus pressure curve is denoted as α, β, and γ, which are the corresponding weighting coefficients, and α≥0, β≥0, γ≥0, α+β+γ=1. The linear correlation is used to measure the degree to which the process-level memory access pressure change explains the interconnect bus pressure change. The peak time coincidence is used to measure whether the peak value of the process-level memory access pressure and the peak value of the interconnect bus pressure occur simultaneously within a preset time offset range. The preset time offset range is ±1 to ±3 time windows, with a default of ±1 time window. For example, when the time window length is 1s, the preset time offset range is ±1s to ±3s, preferably ±1s. The peak window contribution percentage is used to measure the proportion of the process's contribution to the total memory access pressure within the interconnect bus congestion peak window.

[0022] Step 4: Based on the running characteristics and memory overhead of the bottleneck process, dynamically select thread affinity binding or memory batch migration as optimization methods to optimize the bottleneck process. When the bottleneck process is characterized as a short-running or computationally intensive task, and the memory overhead is less than the preset memory threshold, thread affinity binding is selected as an optimization method: the target process is forced to run on the same processor core by calling the taskset interface. When the bottleneck process is characterized by long-running, large-data tasks, high-frequency remote memory access (i.e., the processor accesses memory mounted on another processor socket across the interconnect bus, resulting in high latency), and memory usage exceeds a preset memory threshold, then memory batch migration based on the move_pages2 interface is selected as an optimization method: the process's physical memory pages are moved from the remote NUMA node to the local memory node where the processor core currently running the process is located; in this embodiment, the preset memory threshold is 512MB; The `move_pages2` interface includes a batch processing mechanism that merges consecutive physical memory pages, and an exception skipping strategy that if an individual physical memory page fails during the migration process due to locking or restricted permissions, only the error code is recorded and the subsequent physical memory pages are processed.

[0023] Step 5: Within the set observation window (usually set to 5 to 30 seconds, with a default value of 10 seconds), continuously monitor the interconnect bus metrics to allow sufficient response time for the system to observe metric changes and prevent performance fluctuations caused by frequent migrations. Determine whether the cross-chip interconnect bus congestion has been alleviated. If yes, exit the optimization process; otherwise, trigger the secondary hardware rate limiting mechanism. Based on the service level identifier carried in the memory access request of the bottleneck process, call the hardware resource allocation interface (such as Intel RDT or ARM MPAM) to implement instantaneous bandwidth limiting and return to step 1. The alleviation refers to bus utilization ≤75% and queuing latency not exceeding a preset threshold. The preset threshold is set in the range of 0.2 to 0.5, with a default value of 0.35, which can be dynamically adjusted according to the system's sensitivity to latency.

[0024] In this embodiment, the secondary hardware rate limiting mechanism refers to a fallback intervention mechanism whereby the system further calls the processor hardware resource allocation interface to perform hardware-level resource constraints on the service level of the candidate bottleneck process when thread affinity binding or memory batch migration fails to restore cross-chip interconnect congestion to a preset safe range within the observation window. The preset safe range is: within K consecutive time windows, bus utilization ≤70% and queuing latency ≤0.30, where K is an integer between 2 and 5, and the default value is 3.

[0025] Instantaneous bandwidth limiting refers to the bandwidth limit control that is immediately applied to the target service level within the current control cycle after the system detects that congestion has not been alleviated, rather than a permanent limitation. When the interconnect bus utilization and queuing delay ratio are detected to return to the preset safe range in subsequent observation windows, the system gradually lifts, relaxes or readjusts the bandwidth limit and returns to step 1 to continue closed-loop monitoring.

[0026] like Figure 2 As shown, an optimization system for multi-processor cross-chip interconnect congestion includes a multi-dimensional data monitoring module, a congestion trigger determination module, a correlation traffic attribution module, a strategy execution module, and a feedback module. The multi-dimensional data monitoring module is connected to the hardware performance monitoring unit (PMU) and is used to synchronously collect interconnect bus indicators of the processor's non-core side and memory access instruction sampling records of the processor's core side based on the processor instruction cycle. The congestion trigger determination module is used to determine in real time whether the cross-chip interconnect bus meets the congestion trigger conditions based on the collected interconnect bus indicators and memory access instruction sampling records. If yes, the correlation traffic attribution module is executed; otherwise, the multi-dimensional data monitoring module is returned to be executed. The correlation traffic attribution module is used to perform differential, normalization, and time-series processing on interconnect bus indicators according to a preset time window to obtain the interconnect bus pressure curve; to perform weighted aggregation on memory access instruction sampling records according to a preset time window to obtain the process-level memory access pressure curve corresponding to each process; to obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve of each process, and to calculate the comprehensive attribution score based on this, and select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low; The strategy execution module is used to dynamically select thread affinity binding or memory batch migration as optimization methods based on the running characteristics and memory overhead of the bottleneck process, thereby optimizing the bottleneck process. The feedback module is used to continuously monitor interconnect bus indicators within a set observation window period to determine whether the cross-chip interconnect bus congestion has been alleviated. If so, the optimization process is exited; if not, a secondary hardware rate limiting mechanism is triggered. Based on the service level identifier carried in the memory access request of the bottleneck process, the hardware resource allocation interface is called to implement instantaneous bandwidth limiting and return to the execution multi-dimensional data monitoring module.

[0027] To verify the effectiveness of this invention, the following experiments were conducted. The experimental environment was as follows: The experimental server was a dual-socket NUMA architecture x86 server with an Intel Xeon Platinum 8383C (Ice Lake) processor interconnected via Intel UPI. It had 512GB of memory, NVMe SSD storage, and ran Ubuntu Server 22.04 LTS with a Linux kernel version of 5.x. The runtime environment included JDK 1.8, Apache Flink 1.17, Hadoop 3.3.1, and a TPC-H 50GB dataset.

[0028] Table 1: Performance Comparison of Flink TPC-H (50GB)

[0029] The experimental data in Table 1 show that, compared to the native Auto-NUMA mechanism, the proposed method achieves comprehensive performance improvements in the Flink TPC-H50GB scenario. Specifically, the P99 tail latency drops dramatically from 520.4ms to 135.2ms, a reduction of 74.0%. This is attributed to the invention's ability to detect the queuing latency ratio of the interconnect bus in real time and proactively intervene to optimize before the performance inflection point, thereby avoiding long queues of requests in the buffer. The average throughput increases from 12,400 Requests / s to 18,900. The increase in requests / s reached 52.4%, primarily due to the invention's precise identification of bottleneck processes causing congestion through comprehensive attribution scoring, and the dynamic selection of thread affinity binding or memory batch migration to eliminate them. This resulted in a decrease in the average cross-chip bus utilization rate from 88.50% to 62.10%, freeing up significant effective bandwidth to support more business requests. The queuing latency ratio decreased from 0.58 to 0.18, a reduction of 68.9%, directly verifying that the congestion triggering conditions calculated in real-time based on Pending_Cycles and Active_Cycles in this invention accurately reflect the bus queuing status, thereby driving the optimization process to promptly reduce unnecessary cross-chip accesses. The QPS stability variance decreased from 850.2 to 120.5, a reduction of 85.8%, indicating that the closed-loop optimization mechanism of this invention (including congestion mitigation judgment and secondary hardware rate limiting in step 5) effectively suppressed drastic fluctuations in throughput and significantly improved the system's service determinism under high load.

[0030] Table 2: Comparison of Efficiency and Stability of Memory Migration Interface

[0031] The experimental data in Table 2 further reveals the substantial advantages of the improved move_pages2 interface compared to the native move_pages interface in this invention: The native move_pages interface uses a page-by-page processing method, migrating only 1 page at a time, resulting in significant system call overhead (based on 100% CPU cycles). In contrast, the batch processing mechanism introduced in this invention merges 256 consecutive physical memory pages into a single migration operation, drastically reducing system call overhead to 12.5%, a reduction of 87.5%. This directly supports the low-overhead feasibility of choosing memory batch migration as an optimization method for long-duration big data tasks in step 4. More importantly, the native interface uses a "one-page failure, all-out stop" strategy; if a page fails to migrate due to locking or restricted permissions, the entire migration process is interrupted, resulting in a task interruption rate as high as 15.2%. This invention incorporates an exception skipping strategy in move_pages2. When encountering individual failed pages, only the error code is recorded and subsequent pages are processed, drastically reducing the task interruption rate to 0.2%, a reduction of 98.6%, thus ensuring the robustness of the optimization process. The performance self-healing window duration is shortened from 8.5 seconds to 1.8 seconds, a reduction of 78.8%. This means that when congestion occurs, this invention can complete the memory redistribution of the bottleneck process and restore system performance at a faster speed, verifying the significant improvement in closed-loop convergence speed under the combined effect of batch processing and the exception skipping strategy.

Claims

1. An optimization method for multiprocessor cross-chip interconnect congestion, characterized in that... Includes the following steps: Step 1: Based on the processor instruction cycle, synchronously collect interconnect bus indicators on the non-core side of the processor and memory access instruction sampling records on the core side of the processor. Step 2: Based on the collected interconnect bus metrics and memory access instruction sampling records, determine in real time whether the cross-chip interconnect bus meets the congestion triggering conditions. If yes, proceed to step 3; otherwise, return to step 1. Step 3: Perform differential, normalization, and time-series processing on the interconnect bus indicators according to the preset time window to obtain the interconnect bus pressure curve; perform weighted aggregation on the memory access instruction sampling records according to the preset time window to obtain the process-level memory access pressure curve corresponding to each process; obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve of each process, and calculate the comprehensive attribution score accordingly; select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low. Step 4: Based on the running characteristics and memory overhead of the bottleneck process, dynamically select thread affinity binding or memory batch migration as optimization methods to optimize the bottleneck process. Step 5: Continuously monitor the interconnect bus indicators within the set observation window period to determine whether the cross-chip interconnect bus congestion has been alleviated. If yes, exit the optimization process; if no, trigger the secondary hardware rate limiting mechanism. Based on the service level identifier carried in the memory access request of the bottleneck process, call the hardware resource allocation interface to implement instantaneous bandwidth limiting and return to execute step 1.

2. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnection according to claim 1, characterized in that... In step 1, the interconnect bus metrics include one or more of the following: transmit direction flow control unit count, cross-chip link throughput, interconnect request retry count, interconnect request queuing cycle count, link active cycle count, and remote memory access request count; the memory access instruction sampling record includes one or more of the following: sampling timestamp or processor cycle count, process identifier, thread identifier, processor core number, instruction address, memory access type, memory access address, memory access latency, cache hit status, memory access source information, and local or remote NUMA node identifier.

3. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnection according to claim 1, characterized in that... In step 2, the congestion triggering condition is that the bus utilization rate is greater than 75% and the queuing delay ratio exceeds a preset threshold; wherein Bus utilization is based on the formula get, This indicates the average response time for an interconnect bus request. This indicates the peak processing capacity of the bus per unit time. Indicates bus utilization; Queue delay percentage according to formula get, Indicates the percentage of queuing delays. This indicates the number of cycles that a bus request has been pending / queued in the buffer. This indicates the number of cycles in which the bus is in an active transmission state.

4. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnection according to claim 1, characterized in that... The specific operation process of step 3 is as follows: First, the interconnect bus indicators are differentially divided according to the preset time window to obtain the count increment within each time window. Each count increment is divided by the length of the time window to obtain the interconnect bus pressure value per unit time. The interconnect bus pressure values ​​per unit time corresponding to all time windows are normalized and arranged in chronological order of the start time of the time window to form the interconnect bus pressure curve. Meanwhile, the memory access instruction sampling records are weighted and aggregated according to the same preset time window: for each memory access instruction sampling record, the sampling weight is set according to one or more factors among memory access type, memory access latency, whether it is a remote NUMA access, cache hit status, micro-operation overhead and processor current operating frequency compensation coefficient, and the sampling weights belonging to the same process identifier are accumulated in the corresponding time window to obtain the weighted memory access pressure value of the process in the time window. The weighted memory access pressure values ​​of each time window are arranged in chronological order of the start time of the time window to form the process-level memory access pressure curve corresponding to each process; Subsequently, the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve for each process were calculated. Based on these factors, a comprehensive attribution score was calculated for each process. The top N processes, ranked by their comprehensive attribution scores from highest to lowest, were selected as bottleneck processes. The comprehensive attribution score of the i-th process was denoted as... , , This is an indicator of the linear correlation between the process-level memory access pressure curve of the i-th process and the interconnect bus pressure curve. The peak time overlap between the process-level memory access pressure curve and the interconnect bus pressure curve of the i-th process is denoted as . Let α be the contribution percentage of the i-th process within the peak window of the interconnect bus pressure curve, and let α, β, and γ be the corresponding weight coefficients, where α≥0, β≥0, γ≥0, and α+β+γ=1.

5. The method for congestion awareness and dynamic closed-loop optimization across multiprocessor interconnects according to claim 1, characterized in that... In step 4, when the bottleneck process is characterized as a short-time task or a computationally intensive task, and the memory overhead is less than the preset memory threshold, thread affinity binding is selected as an optimization method: the target process is forced to run on the same processor core by calling the taskset interface.

6. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnect according to claim 1, characterized in that... In step 4, when the bottleneck process is characterized by long-running big data tasks, high-frequency remote memory accesses, and memory usage exceeding the preset memory threshold, memory batch migration based on the move_pages2 interface is selected as an optimization method: the process's physical memory pages are moved from the remote NUMA node to the local memory node where the processor core currently running the process is located.

7. The method for congestion awareness and dynamic closed-loop optimization across multiprocessor interconnects according to claim 6, characterized in that... The interface move_pages2 includes a batch processing mechanism: merging consecutive physical memory pages.

8. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnect according to claim 6, characterized in that... The interface move_pages2 includes an exception skipping strategy: if an individual physical memory page fails during the migration process due to locking or restricted permissions, only the error code is recorded and subsequent physical memory pages are processed.

9. The method for congestion awareness and dynamic closed-loop optimization of multiprocessor cross-chip interconnect according to claim 1, characterized in that... The mitigation in step 5 refers to a bus utilization rate of ≤75% and a queuing delay percentage not exceeding a preset threshold.

10. An optimization system for multiprocessor cross-chip interconnect congestion, characterized in that... It includes a multi-dimensional data monitoring module, a congestion trigger determination module, a correlation traffic attribution module, a policy execution module, and a feedback module. The multidimensional data monitoring module is connected to the hardware performance monitoring unit and is used to synchronously collect interconnect bus indicators on the non-core side of the processor and memory access instruction sampling records on the core side of the processor based on the processor instruction cycle. The congestion trigger determination module is used to determine in real time whether the cross-chip interconnect bus meets the congestion trigger conditions based on the collected interconnect bus indicators and memory access instruction sampling records. If yes, the correlation traffic attribution module is executed; if no, the multi-dimensional data monitoring module is returned to be executed. The aforementioned correlation traffic attribution module is used to perform differential, normalization, and time-series processing on interconnect bus indicators according to a preset time window to obtain the interconnect bus pressure curve; to perform weighted aggregation on memory access instruction sampling records according to a preset time window to obtain the process-level memory access pressure curve corresponding to each process; to obtain the linear correlation, peak time overlap, and peak window contribution ratio between the process-level memory access pressure curve and the interconnect bus pressure curve of each process, and to calculate the comprehensive attribution score accordingly, and select the top N processes as bottleneck processes according to the comprehensive attribution score from high to low; The strategy execution module is used to dynamically select thread affinity binding or memory batch migration as optimization methods based on the running characteristics and memory overhead of the bottleneck process, so as to optimize the bottleneck process. The feedback module is used to continuously monitor the interconnect bus indicators within the set observation window period to determine whether the cross-chip interconnect bus congestion has been alleviated. If so, the optimization process is exited; if not, a secondary hardware rate limiting mechanism is triggered. Based on the service level identifier carried in the memory access request of the bottleneck process, the hardware resource allocation interface is called to implement instantaneous bandwidth limiting and return to the execution multi-dimensional data monitoring module.

Images