Multi-core cross-on-chip memory access method, device, storage medium and product

Abstract

The application discloses a multi-core cross-road memory access method and device, a storage medium and a product, relates to the technical field of computer architecture and processor design, and the multi-core cross-road memory access method comprises the following steps: obtaining memory access requests of CPU cores in each CPU core cluster, wherein the CPU core cluster is obtained by dividing a plurality of CPU cores; based on a local combiner corresponding to each CPU core cluster, merging corresponding memory access requests to obtain local batch requests of each CPU core cluster; sending the local batch requests to a preset global combiner; based on the global combiner, merging each local batch request to obtain a global batch request; and sending the global batch request to a preset computing fast interconnection controller to complete cross-road memory access of each CPU core. The application combines a large number of cross-road memory access requests into a global batch request, thereby improving system throughput and protocol efficiency.

Description

Technical Field

[0001] This application relates to the fields of computer architecture and processor design technology, and in particular to multi-core cross-channel memory access methods, devices, storage media and products. Background Technology

[0002] With the rapid growth in demand for data centers and high-performance computing, multi-processor systems are widely used. In NUMA (Non-Uniform Memory Access) architectures, each processor socket has local memory, and the latency of accessing local memory is much lower than that of accessing remote memory. In high-core-count systems, CXL (ComputeExpress Link) has become a key technology for cross-socket communication.

[0003] Current cross-path memory access methods route memory access requests to CXL through the core's CMN Mesh network (consistent mesh network), and then encapsulate and transmit them through CXL to achieve cross-path access to the memory of another core. However, in high-concurrency scenarios, when a large number of CPU cores generate cross-path requests simultaneously, a large number of cross-path requests are sent to CXL at the same time. Each request data transmission requires CXL to spend a fixed amount of protocol overhead, causing congestion in CXL's queue, thereby reducing the system's throughput and protocol efficiency. Summary of the Invention

[0004] The main objective of this application is to provide a multi-core cross-path memory access method, device, storage medium, and product, which aims to solve the technical problem that current methods reduce system throughput and protocol efficiency.

[0005] To achieve the above objectives, this application proposes a multi-core cross-channel memory access method, the method comprising: Obtain memory access requests from each CPU core in each CPU core cluster, wherein the CPU core cluster is obtained by dividing multiple CPU cores; Based on the local merger corresponding to each CPU core cluster, the corresponding memory access requests are merged to obtain the local batch requests for each CPU core cluster. The local batch requests are sent to a preset global merger. Based on the global merger, the local batch requests are merged to obtain a global batch request. The global batch request is sent to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core.

[0006] In one embodiment, the local merger includes a local merge queue, and the step of merging the corresponding memory access requests based on the local merger corresponding to each CPU core cluster to obtain the local batch requests for each CPU core cluster includes: Obtain the local queue depth of the local merge queue, and determine the local merge window duration based on the local queue depth; Based on the request priority field of the memory access request, determine whether the memory access request is a priority request; If the memory access request is not the priority sending request, then the memory access request is merged based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request to obtain the local batch request.

[0007] In one embodiment, the step of merging the memory access requests based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request to obtain the local batch requests includes: Obtain the merged request address and merged operation type of the merged access requests in the local merge queue, wherein the merged access requests are obtained by merging the memory access requests; For each memory access request, calculate the difference between the merged request address and the request address to obtain the request address difference; If the requested address difference is within a preset address difference threshold, and the merged operation type is the same as the requested operation type, then the memory access request is added to the local merge queue, and the memory access request is merged with the merged access request to obtain a new merged access request. Determine whether the merged access request meets the preset global merging condition. If it does not meet the condition, return to the step of obtaining the memory access requests of each CPU core in each CPU core cluster until the local merging queue meets the global merging condition, and then use the merged access request as the local batch request.

[0008] In one embodiment, the step of determining whether the merged access request meets the preset global merging conditions further includes: The number of merged access requests and the merge window timer of the local merger are obtained, wherein the merge window timer is reset to a preset initial value after each memory access request is added to the local merge queue. Determine whether the number of merged requests is lower than the local queue depth, and whether the merge window timer is lower than the local merge window duration; If the number of merged requests is lower than the local queue depth and the merge window timer is lower than the local merge window duration, then the local merge queue is determined to not meet the global merge conditions.

[0009] In one embodiment, the global merger includes a global merge queue, and the step of merging the local batch requests based on the global merger to obtain a global batch request includes: Obtain the global queue depth of the global merge queue, and determine the global merge window duration based on the global queue depth; Based on a preset polling order, the local batch requests corresponding to each local merger are added to the global merge queue in sequence to obtain a global queue request; Calculate the difference between the request addresses of each of the global queue requests to obtain the global request address difference; From the global request address differences, determine the target request address difference that is lower than the preset global address difference threshold, and merge the global queue requests corresponding to the target request address difference to obtain a global merged request; Based on the global merge window duration, it is determined whether the global merge request meets the preset request sending conditions. If it does not meet the conditions, the process returns to the step of adding the local batch requests corresponding to each local merger to the global merge queue in turn, based on the preset polling order, until the global merge request meets the request sending conditions, and the global merge request is used as the global batch request.

[0010] In one embodiment, the step of determining whether the global merge request meets the preset request sending conditions based on the global merge window duration includes: Obtain the number of merged requests in the global merge request and the merge window timer of the global merger; Determine whether the number of merged requests is lower than a preset batch threshold and whether the merge window timer is lower than the global merge window duration; If the number of merged requests is not less than the batch threshold, or the merge window timer is not less than the global merge window duration, then the global merge request is determined to meet the request sending conditions.

[0011] In one embodiment, after the step of sending the global batch request to a preset compute fast interconnect controller to complete cross-path memory access for each of the CPU cores, the method further includes: The system receives return data sent by the compute fast interconnect controller, wherein the return data includes the request ID of each memory access request in the global batch request and the request return data of each memory access request; Based on the request ID and a preset request lookup mapping table, determine the target CPU core corresponding to each request ID; The data returned by each request is distributed to the corresponding target CPU core.

[0012] In addition, to achieve the above objectives, this application also proposes a multi-core cross-channel memory access device, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the multi-core cross-channel memory access method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the multi-core cross-channel memory access method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the multi-core cross-channel memory access method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application obtains memory access requests from each CPU core in each CPU core cluster. The CPU core cluster is obtained by dividing multiple CPU cores. Based on the local merger corresponding to each CPU core cluster, the corresponding memory access requests are merged to obtain local batch requests for each CPU core cluster. The local batch requests are sent to a preset global merger. Based on the global merger, the local batch requests are merged to obtain a global batch request. The global batch request is sent to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core.

[0016] Compared to current cross-path memory access methods that require CXL to incur fixed-time protocol overhead for data transmission during cross-path requests, leading to congestion in the CXL queue and reducing system throughput and protocol efficiency, this application merges a large number of cross-path memory access requests into a global batch request, thereby improving system throughput and protocol efficiency. Specifically, this application divides the CPU into multiple clusters. A local merger for each cluster initially merges the memory access requests of the CPU cores in each cluster to obtain local batch requests. After obtaining the local batch requests for each CPU cluster, this application uses a global merger to merge the local batch requests into a global batch request and sends it to the compute fast interconnect controller. This allows the compute fast interconnect controller to process cross-path memory access requests in batches, eliminating the need to process each request individually for a fixed amount of time, thus improving system throughput and protocol efficiency. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an embodiment of the multi-core cross-path memory access method of this application. Figure 2 This is a schematic diagram of the system architecture provided in Embodiment 1 of the multi-core cross-path memory access method of this application; Figure 3 This is a schematic diagram of the local merger workflow provided in Embodiment 1 of the multi-core cross-path memory access method of this application; Figure 4 This is a schematic diagram of the global merger workflow provided in Embodiment 1 of the multi-core cross-path memory access method of this application; Figure 5 This is a performance comparison diagram provided for Embodiment 1 of the multi-core cross-path memory access method of this application; Figure 6 This is a flowchart illustrating Embodiment 2 of the multi-core cross-path memory access method of this application; Figure 7 This is a flowchart illustrating Embodiment 3 of the multi-core cross-path memory access method of this application; Figure 8This is a schematic diagram of the device structure of the hardware operating environment involved in the multi-core cross-path memory access method in the embodiments of this application; Figure 9 This is a schematic diagram illustrating the data acquisition consent process involved in the multi-core cross-path memory access method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or multi-core cross-channel memory access device capable of performing the above functions. The following description uses a multi-core cross-channel memory access device as an example to illustrate this embodiment and the subsequent embodiments.

[0024] With the rapid growth in demand for data centers and high-performance computing, multi-processor systems are widely used. In NUMA (Non-Uniform Memory Access) architectures, each processor socket has local memory, and the latency of accessing local memory is much lower than that of accessing remote memory. In high-core-count systems, CXL (ComputeExpress Link) has become a key technology for cross-socket communication.

[0025] Current cross-path memory access methods route memory access requests to CXL through the core's CMN Mesh network (consistent mesh network), and then encapsulate and transmit them through CXL to achieve cross-path access to the memory of another core. However, in high-concurrency scenarios, when a large number of CPU cores generate cross-path requests simultaneously, a large number of cross-path requests are sent to CXL at the same time. Each request data transmission requires CXL to spend a fixed amount of protocol overhead, causing congestion in CXL's queue, thereby reducing the system's throughput and protocol efficiency.

[0026] Furthermore, the current method's fragmented, small-granularity requests cannot fully utilize CXL's batch transfer capabilities, and the user-space NUMA strategy cannot affect kernel-space memory allocations such as device drivers and DMA (Direct Memory Access) buffers, leading to a large number of uncontrollable cross-path accesses. Moreover, the ARM (Advanced RISC Machine), CMN, and CXL controllers are licensed IP (IP cores), making it impossible to directly modify their internal logic, severely limiting the space for in-depth hardware-level optimization.

[0027] Based on this, embodiments of this application provide a multi-core cross-path memory access method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the multi-core cross-path memory access method of this application.

[0028] In this embodiment, the multi-core cross-path memory access method includes steps S10~S40: Step S10: Obtain the memory access requests of each CPU core in each CPU core cluster, wherein the CPU core cluster is obtained by dividing multiple CPU cores. It should be noted that a CPU core is a hardware computing unit in a processor that performs arithmetic and logical operations, executes instructions, and processes data. A CPU core cluster is a logical grouping of multiple CPU cores according to preset rules. Each cluster contains a fixed number of cores. In this embodiment, 128 cores are divided into 8 clusters, each with 16 cores, and each cluster is configured with one local merger (first stage). The outputs of the 8 local mergers are converged into one global merger (second stage). A memory access request is a read or write operation instruction issued by the CPU core to the memory subsystem, which includes information such as the target memory address, operation type, and data payload.

[0029] It should also be noted that this embodiment uses the CPU core, local merger, global merger, and CXL to form a cross-channel memory access system. The overall architecture of the system in this embodiment can be referred to Figure 2 The key parameter configurations in this embodiment's architecture can be referenced in Table 1 below: Table 1: System Design Parameters

[0030] In the table, the MUX in the pure combinational logic MUX delay refers to a multiplexer. Furthermore, the system in this embodiment also includes a control register and a statistics register. The information of the control register is shown in Table 2 below: Table 2: Control Register Information Table

[0031] Among them, MODULE_ENABLE is the module enable register, MODULE_STATUS is the module status register, BYPASS_FORCE is the forced bypass register, LOCAL_WINDOW is the local merge window register, GLOBAL_WINDOW is the global merge window register, and MAX_BATCH_SIZE is the maximum batch size register.

[0032] The information in the statistical register table of this embodiment is shown in Table 3 below: Table 3: Statistical Register Information Table

[0033] Among them, TOTAL_REQUESTS is the total number of requests register, LOCAL_MERGE_COUNT is the local merge count register, GLOBAL_MERGE_COUNT is the global merge count register, BATCH_COUNT is the batch request count register, and AVG_BATCH_SIZE is the average batch size register.

[0034] It is understood that in this embodiment, all CPU cores are grouped according to the cluster partitioning method, and the local merger corresponding to each cluster independently obtains the requests of its cores. This can decompose the originally globally disordered large number of concurrent requests into multiple locally ordered request streams, which facilitates the subsequent implementation of the first-level merging within the cluster.

[0035] Step S20: Based on the local merger corresponding to each CPU core cluster, merge the corresponding memory access requests to obtain the local batch requests of each CPU core cluster. It should be noted that the local merger is a hardware logic unit deployed at the front end of each CPU core cluster, responsible for the first-level merging processing of memory access requests issued by all CPU cores within the cluster. A local batch request is a single aggregated request generated after the local merger has merged multiple memory access requests. It contains the addresses, types, and data information of multiple original requests and is output in batch form.

[0036] It is understandable that this embodiment uses a preset merging window in the local merger to perform real-time detection and merging of address continuity and type of memory access requests within the same CPU core cluster. This allows for the aggregation of scattered small requests into large-granularity local batch requests near the data source. This embodiment significantly reduces the number of requests that would otherwise need to be transmitted across the cluster one by one before global merging. This reduces the number of data transfers between the local and global mergers and provides a higher proportion of continuous address segment inputs for subsequent global secondary merging, thereby improving the efficiency of the entire merging pipeline and reducing the number of protocol interactions in the CXL link. Specifically, the overall process of local merging in this embodiment can be referred to... Figure 3 .

[0037] Step S30: Send the local batch requests to a preset global merger. Based on the global merger, merge the local batch requests to obtain a global batch request. It should be noted that the global merger is a hardware logic unit deployed after all local mergers, responsible for performing a second-level merging process on all local batch requests. The global batch request is the final aggregated request generated by the global merger after merging multiple local batch requests. It contains the addresses, types, and data information of multiple original memory access requests and is output to the downstream CXL controller in a single batch format.

[0038] It is understood that this embodiment further aggregates the initially merged local batch requests from each CPU core cluster into a global merger for secondary merging, thereby aggregating scattered batch requests across multiple clusters into larger global batch requests. This significantly reduces the number of requests ultimately sent to remote memory via the CXL controller compared to the original number of requests, substantially reducing the number of protocol interactions and queue congestion probability on the CXL link, while effectively reducing the fixed protocol overhead for each transmission, thus significantly improving overall throughput performance. The overall process of global merging in this embodiment can be referred to... Figure 4 .

[0039] Step S40: The global batch request is sent to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core.

[0040] It should be noted that the Compute Fast Interconnect (CXL) controller is a hardware interface control unit that complies with the Compute Fast Interconnect (CXL) protocol specification and is responsible for managing high-speed data exchange between the local CPU and remote memory or other devices. Cross-socket memory access refers to the operation of the socket where the current CPU core resides accessing the remote physical memory mounted on another socket. Its data path must pass through an inter-chip interconnect link (such as CXL), and the access latency is significantly higher than that of local memory access.

[0041] It is understood that in this embodiment, the global batch request generated after two-level merging is directly sent to the compute fast interconnect controller. This batch request already aggregates a large number of original small-granularity requests, allowing the compute fast interconnect controller to complete data transmission tasks that originally required multiple interactions with a single protocol interaction. This embodiment significantly reduces the protocol handshake and acknowledgment overhead on the link, effectively alleviating queue congestion pressure on the compute fast interconnect controller, and fully utilizing the link's large-granularity batch transmission capability, thereby improving the effective bandwidth of cross-path memory access and reducing the average access latency overall. The schematic diagram and performance comparison diagram of the two-level hierarchical merging effect of this embodiment can be found in [reference needed]. Figure 5 .

[0042] In one feasible implementation, the specific implementation following the step of sending the global batch request to a preset compute fast interconnect controller to complete cross-path memory access for each of the CPU cores can also be: The system receives return data sent by the compute fast interconnect controller, wherein the return data includes the request ID of each memory access request in the global batch request and the request return data of each memory access request; Based on the request ID and a preset request lookup mapping table, determine the target CPU core corresponding to each request ID; The data returned by each request is distributed to the corresponding target CPU core.

[0043] It should be noted that the returned data is the complete data information sent back by the compute fast interconnect controller to the request initiator after completing the remote memory access operation. Its content includes the request ID and the data payload or operation status corresponding to that request. The request ID is a unique identifier assigned by hardware logic to each memory access request when it is initiated and enters the merging pipeline, used to track and distinguish different original requests throughout the request-response chain. The request return data is a status indication of the specific read result or write operation completion corresponding to each original memory access request. The request lookup mapping table is a hardware lookup structure stored in the global merger or distribution logic, used to record the correspondence between each valid request ID and its corresponding target CPU core, so as to achieve the routing of response messages to the correct core.

[0044] It is understood that this embodiment reverses the decoupling of the merged batch response data and accurately routes it to the CPU core that initiated each original request by using the request ID and a preset request lookup mapping table. This ensures that even with a significant reduction in the number of requests, each core can still correctly receive its own return data without errors or loss, thus ensuring the reliability of the optimization scheme in multi-core high-concurrency scenarios.

[0045] In summary, this embodiment obtains the memory access requests of each CPU core in each CPU core cluster. The CPU core cluster is obtained by dividing multiple CPU cores. Based on the local merger corresponding to each CPU core cluster, the corresponding memory access requests are merged to obtain local batch requests for each CPU core cluster. The local batch requests are sent to a preset global merger. Based on the global merger, the local batch requests are merged to obtain a global batch request. The global batch request is sent to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core.

[0046] Compared to current cross-path memory access methods that require CXL to incur fixed-time protocol overhead for data transmission during cross-path requests, leading to congestion in the CXL queue and reducing system throughput and protocol efficiency, this embodiment merges a large number of cross-path memory access requests into a global batch request, thereby improving system throughput and protocol efficiency. Specifically, this embodiment divides the CPU into multiple clusters. A local merger for each cluster initially merges the memory access requests of the CPU cores in each cluster to obtain local batch requests. After obtaining the local batch requests for each CPU cluster, this embodiment uses a global merger to merge the local batch requests into a global batch request and sends it to the compute fast interconnect controller. This allows the compute fast interconnect controller to process cross-path memory access requests in batches, eliminating the need to process each request individually for a fixed amount of time, thus improving system throughput and protocol efficiency.

[0047] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 6 The local merger includes a local merge queue. In step S20, the multi-core cross-path memory access method further includes steps S21-S23: Step S21: Obtain the local queue depth of the local merge queue, and determine the local merge window duration based on the local queue depth; It should be noted that the local merge queue is a hardware storage structure deployed within each local merger. It is used to temporarily store the raw memory access requests or partially merged intermediate entries acquired by that local merger, awaiting processing by the merge decision logic. The local queue depth is the number of requests or entries currently stored in the local merge queue, reflecting the real-time occupancy level of the queue. The local merge window duration is the merge waiting time used by each local merger during the first-level merge; this duration determines the time range within which the local merger is allowed to accumulate requests before outputting a batch of merge results.

[0048] It is understandable that this embodiment dynamically adjusts the merging window duration based on the real-time depth of the local merging queue. The local queue depth directly reflects the density of requests arriving within the current cluster. This allows for proactively shortening the waiting time to reduce queuing latency during periods of high request density, and proactively extending the waiting time to accumulate more mergeable requests during periods of low request density. Through this queue status feedback-based adjustment method, the local merger maintains high merging efficiency under different load scenarios, while avoiding additional latency introduced by an excessively long fixed window or a decrease in merging rate due to an excessively short window, thereby optimizing the overall performance of cross-path access.

[0049] Step S22: Based on the request priority field of the memory access request, determine whether the memory access request is a priority sending request; It should be noted that the request priority field is a flag or numerical field carried in the request information of each memory access request, used to identify the relative urgency or service quality level of the request.

[0050] Priority sending requests refer to special memory access requests that are determined by the request priority field to need to bypass the regular merging wait and be sent directly to the next level of processing. They are usually used to carry latency-sensitive critical data or control instructions.

[0051] It should also be noted that the request priority field includes not only priority to send requests but also priority to merge requests. When the request priority field is priority to merge requests, the local merger will merge access requests that do not have priority to merge requests.

[0052] It is understood that this embodiment directly reads and determines the priority field of each request through hardware logic, thereby distinguishing urgent requests from ordinary batch requests at the entry point of the merging process. This embodiment enables high-priority requests to be forwarded quickly without queuing and waiting for the local merging window to time out, significantly reducing the cross-path access latency of critical requests, while ordinary requests continue to participate in the merging process for bandwidth optimization.

[0053] Step S23: If the memory access request is not the priority sending request, then based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request, the memory access request is merged to obtain the local batch request.

[0054] It should be noted that the request operation type is a field in the memory access request that identifies the type of operation, used to distinguish between different access behaviors such as read operations or write operations. The request address is the physical address or a unique number in the system address space of the target memory location pointed to by the memory access request.

[0055] It is understood that this embodiment only performs merging operations on non-priority requests, and the merging decision simultaneously considers the corresponding accumulation time, the consistency of request operation types, and the continuity of request addresses. This maximizes the merging of ordinary requests without affecting the real-time performance of critical requests. This embodiment ensures the correctness of the merging result through dual verification of operation type and address, ensuring that only requests accessing the same type of memory region and with adjacent addresses can be aggregated. Furthermore, dynamic adjustment of the window duration ensures that the merging operation does not wait indefinitely, achieving a balance between latency and merging rate.

[0056] In one feasible implementation, the specific implementation of merging the memory access requests based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request to obtain the local batch request can also be: Obtain the merged request address and merged operation type of the merged access requests in the local merge queue, wherein the merged access requests are obtained by merging the memory access requests; For each memory access request, calculate the difference between the merged request address and the request address to obtain the request address difference; If the requested address difference is within a preset address difference threshold, and the merged operation type is the same as the requested operation type, then the memory access request is added to the local merge queue, and the memory access request is merged with the merged access request to obtain a new merged access request. Determine whether the merged access request meets the preset global merging condition. If it does not meet the condition, return to the step of obtaining the memory access requests of each CPU core in each CPU core cluster until the local merging queue meets the global merging condition, and then use the merged access request as the local batch request.

[0057] It should be noted that a merged access request is an intermediate aggregated entry in the local merge queue that has participated in the merge process and represents a temporary result where multiple original memory access requests have been merged into one. The merged request address is the starting address or latest accumulated address of the contiguous address segment currently corresponding to the merged access request, used for subsequent continuity checks with new request addresses. The merged operation type is the request operation type carried by the merged access request. This type is determined by the first original request being merged upon initial creation and must remain consistent with the operation type of the requests to be added during subsequent merges.

[0058] The request address difference is the numerical difference between the request address of the currently pending memory access request and the address of the merged request. The address difference threshold is a preset maximum allowable difference used to determine whether two addresses are consecutive or mergeable; this threshold corresponds to the size of a cache line. The global merge condition is a preset trigger condition used to determine whether the local merger can output the currently merged access request as a local batch request to the global merger; it can be set based on factors such as queue depth, merge window timeout, or the cumulative number of requests.

[0059] It should also be noted that this embodiment first checks whether a queue exists in the local merger before merging. If no queue exists, a new queue entry is created and a timer is started. Furthermore, in this embodiment, if the requested address difference is outside the address difference threshold, or if the operation type of the memory access request differs from the operation type requested in the queue, a new queue is created, and the corresponding content request is added to the new queue.

[0060] Understandably, this implementation performs dual matching based on the address difference between merged entries and new requests, and the operation type. It also dynamically determines whether the output conditions are met after each merge, thus continuously accumulating as many mergeable requests as possible within a single merge window until a preset threshold is met before outputting. The introduction of global merge conditions allows the merge operation to balance queue depth and waiting time, preventing excessive delays caused by long waits for a few mergeable requests, thereby maximizing the merge rate and ensuring real-time request performance.

[0061] In one feasible implementation, the specific implementation of determining whether the merged access request meets the preset global merging conditions can also be: The number of merged access requests and the merge window timer of the local merger are obtained, wherein the merge window timer is reset to a preset initial value after each memory access request is added to the local merge queue. Determine whether the number of merged requests is lower than the local queue depth, and whether the merge window timer is lower than the local merge window duration; If the number of merged requests is lower than the local queue depth and the merge window timer is lower than the local merge window duration, then the local merge queue is determined to not meet the global merge conditions.

[0062] It should be noted that the number of merged requests refers to the number of original memory access requests that have been aggregated for the merged access request, reflecting the degree of merging of that entry. The merge window timer is a hardware timer inside the local merger used to measure the elapsed time of the current merge window. This timer is reset each time a new memory access request is successfully added to the local merge queue. The initial value is the starting count value assigned when the merge window timer is reset, used to mark the start of a new round of merge waiting cycles.

[0063] It is understood that this implementation method simultaneously reflects the idle level of the queue by comparing the number of merged requests with the local queue depth, and reflects the remaining waiting time by comparing the merge window timer with the local merge window duration. This allows for the continuous accumulation of requests when there is still space in the queue and time permits, thereby maximizing the number of original requests contained in each local batch request.

[0064] In summary, this embodiment dynamically adjusts the merging window duration based on the local queue depth, ensuring that the merging waiting time matches the current request arrival rate. This avoids insufficient merging rate under low load or queue overflow under high load due to a fixed window. Simultaneously, this embodiment uses pre-priority judgment to remove urgent requests from the merging process, guaranteeing low-latency forwarding of critical requests without affecting the batch accumulation of ordinary requests. Furthermore, this embodiment considers address differences and operation types in the merging decision-making process and uses the number of merged requests and the merging window timer to determine the global merging condition after each merge. This ensures that the merging process fully utilizes the remaining queue capacity to maximize batch size without introducing additional latency due to unlimited waiting. Ultimately, this allows the local merger to automatically achieve a high merging rate and low average latency under different load scenarios, effectively reducing the request pressure on subsequent global merging and CXL links.

[0065] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 7 The global merger includes a global merge queue, and the local merger includes a local merge queue. In step S30, the multi-core cross-path memory access method further includes steps S31-S35: Step S31: Obtain the global queue depth of the global merge queue, and determine the global merge window duration when merging based on the global queue depth; It should be noted that the global merge queue is a hardware storage structure deployed within the global merger, used to temporarily store the local batch requests sent from each of the local mergers, awaiting processing by the second-level merge decision logic of the global merger. The global queue depth is the number of local batch requests or partially merged intermediate entries currently stored in the global merge queue, reflecting the real-time occupancy level of the queue. The global merge window duration is the merge waiting time adopted by the global merger during the second-level merge; this duration determines the time range within which the global merger allows the local batch requests to accumulate before outputting a batch of global batch requests.

[0066] It is understood that in this embodiment, the global merge window duration is dynamically adjusted according to the real-time global queue depth of the global merge queue. The global queue depth directly reflects the convergence arrival density of local batch requests from all local mergers. This allows for proactively shortening the waiting time when request convergence is dense to reduce queuing delay and overflow risk of the global merge queue, and proactively extending the waiting time when request convergence is sparse to accumulate more local batch requests from different clusters for secondary merging.

[0067] Step S32: Based on the preset polling order, the local batch requests corresponding to each local merger are added to the global merge queue in sequence to obtain the global queue request; It should be noted that the polling order is the cyclic selection order used by the global merger when receiving the local batch requests from multiple local mergers, to fairly traverse each of the local mergers. The global queue request is the set of all pending entries temporarily stored in the global merge queue after the local batch requests generated by each of the local mergers are added to the global merge queue in the polling order.

[0068] It is understood that this embodiment uses the polling order to cyclically select among the local mergers and adds the corresponding local batch requests to the global merge queue one by one. This ensures that each local merger has an equal chance of being selected in each round of input arbitration, preventing the global merge queue from being occupied by dense requests from certain local mergers for a long time. Simultaneously, by adding the local batch requests to the global merge queue in an orderly manner to form the global queue request, the global merge queue simultaneously aggregates batch requests from multiple different CPU core clusters. This allows the global merger to identify and aggregate requests with consecutive addresses across clusters in the second-level merge, thereby improving the overall merging efficiency of the final global batch requests.

[0069] Step S33: Calculate the difference between the request addresses of each of the global queue requests to obtain the global request address difference; It should be noted that the global request address difference is a numerical difference calculated between the request addresses of any two global queue requests in the global merge queue, and is used to determine whether the memory addresses pointed to by different global queue requests are adjacent or consecutive.

[0070] It is understood that this embodiment quantifies the spatial relationship between addresses into a specific numerical value by performing difference calculation on the request addresses of the global queue requests, thereby enabling the global merger to accurately determine which local batch requests from different CPU core clusters are consecutive in address based on this numerical value.

[0071] Step S34: Determine the target request address difference that is lower than the preset global address difference threshold from each of the global request address differences, and merge the global queue requests corresponding to the target request address difference to obtain a global merged request; It should be noted that the global address difference threshold is a preset maximum allowable difference used to determine whether the addresses of two global queue requests are consecutive or can be merged. This threshold corresponds to the size of a cache line. The target request address difference is the difference selected from the global request address differences whose value is lower than the global address difference threshold. The global merge request is an intermediate aggregated entry formed by merging multiple global queue requests corresponding to the target request address difference through the global merger. It represents a temporary result where multiple local batch requests from different local mergers have been aggregated into one.

[0072] It is understood that this embodiment only merges global queue requests whose global request address difference is lower than the global address difference threshold. This threshold is set corresponding to the cache line size, ensuring that only requests from different sources with truly contiguous addresses belonging to the same memory access stream are aggregated into the globally merged request. This embodiment, based on precise address difference filtering and merging, effectively avoids erroneously merging requests with discontinuous addresses or belonging to different access modes, reducing the total number of requests ultimately sent to the compute fast interconnect controller, significantly reducing protocol overhead and improving effective bandwidth utilization.

[0073] Step S35: Based on the global merge window duration, determine whether the global merge request meets the preset request sending conditions. If it does not meet the conditions, return to the step of adding the local batch requests corresponding to each local merger to the global merge queue in turn based on the preset polling order to obtain the global queue request, until the global merge request meets the request sending conditions, and then use the global merge request as the global batch request.

[0074] It should be noted that the request sending condition is a preset set of trigger rules used to determine whether the global merger can output the current global merge request to the computing fast interconnect controller. It can be comprehensively determined based on whether the global merge window timer has expired, whether the number of original requests that have been aggregated in the global merge request has reached a threshold, or whether the global merge queue is full.

[0075] It is understood that this embodiment uses the global merge window duration as the core time constraint, and controls the output timing of the global merge request by cyclically judging the request sending conditions. Thus, while the global merge window has not expired, more local batch requests are continuously obtained from each of the local mergers for secondary merging. This causes the number of original requests aggregated in the global merge request to increase continuously with the increase of the polling rounds, thereby further compressing the total number of requests at the global level and increasing the amount of data transmitted in a single batch.

[0076] In one feasible implementation, the specific implementation of determining whether the global merge request meets the preset request sending conditions based on the global merge window duration can also be: Obtain the number of merged requests in the global merge request and the merge window timer of the global merger; Determine whether the number of merged requests is lower than a preset batch threshold and whether the merge window timer is lower than the global merge window duration; If the number of merged requests is not less than the batch threshold, or the merge window timer is not less than the global merge window duration, then the global merge request is determined to meet the request sending conditions.

[0077] It should be noted that the batch threshold is a preset numerical limit used to determine whether the global merge requests have accumulated to a sufficient degree of aggregation. When the number of merged requests in the global merge request is not lower than this threshold, it indicates that the current aggregation scale has reached a sufficient condition for sending. The merge window timer is a hardware timer inside the global merger used to measure the time elapsed in the current global merge window. The number of globally merged requests is the number of original memory access requests or local batch requests that have been aggregated by the global merge request, reflecting the degree of merging of the global merge request.

[0078] It is understood that this implementation uses either a batch threshold or a global merging window duration as the criterion for determining whether the request sending conditions are met. That is, as long as the aggregated number of the global merging request reaches a sufficient scale or the waiting time reaches a preset upper limit, the output is triggered immediately. This allows for rapid triggering of sending based on quantity conditions in request-intensive scenarios, making full use of the advantages of batch transmission to reduce protocol overhead. At the same time, in request-sparse scenarios, the time condition ensures that the request will not experience unacceptable delays due to long waiting times for the quantity to reach the target.

[0079] In one embodiment, the step of determining whether the global merge request meets the preset request sending conditions based on the global merge window duration further includes: Obtain the number of merged requests in the global merge request, the merge window timer, the current queue level of the global merge queue, and the emergency request count reported by each of the local mergers; Based on the current queue level and the emergency request count, the effective lower limit of the batch threshold and the global merge window duration are dynamically adjusted. The higher the current queue level, the lower the batch threshold is reduced. The higher the emergency request count, the shorter the effective lower limit is. Based on the comparison results of the number of merged requests and the corrected batch threshold, the comparison results of the merge window timer and the corrected effective lower limit, and the comparison results of the continuous address span of the global merge request and the preset span upper limit, it is determined whether the global merge request meets the preset request sending conditions.

[0080] It should be noted that the current queue level is the percentage or proportion of the number of entries currently stored in the global merge queue relative to the total queue capacity, reflecting the queue's remaining acceptance capacity. The urgent request count is the cumulative number of priority requests identified by each local merger within its merge window. This count is periodically reported by each local merger to the global merger to indicate the density of high-priority requests in the current system.

[0081] The effective lower bound is the minimum allowable waiting time determined after the global merge window duration is adjusted by the urgent request count. This lower bound is shortened when urgent requests are concentrated, forcing the global merge request to be output earlier. The contiguous address span is the size of the address range covered by the global merge request from the first original request address to the last original request address, measured in cache lines or bytes. The upper span is a preset maximum allowed value for the contiguous address span, used to prevent a single global batch request from exceeding the transmission capacity limit of the compute fast interconnect controller or link due to an excessively large address coverage range.

[0082] It should also be noted that exceeding the consecutive address span limit means that the address range covered by a single batch request exceeds the hardware capacity of the CXL link for a single transmission. In this case, even if the number of requests and the waiting time meet the conditions, transmission must be prohibited to prevent transmission failure or link anomalies. Therefore, in the embodiment, only when the consecutive address span does not exceed the preset span limit, and either the number of merged requests reaches the target or the merge window timeout is met simultaneously, is it determined that the current global merge request has sufficient conditions to be sent.

[0083] It is understood that this embodiment introduces the current queue level and the number of urgent requests as dynamic correction factors, so that the effective lower limit of the batch threshold and the global merging window duration are adjusted in real time according to the congestion of the global queue and the density of high-priority requests in the system. Thus, when the global merging queue is close to full, the output threshold is actively lowered to prevent data loss, and when there is an outbreak of urgent requests, the waiting time is actively compressed to ensure the transmission of critical data.

[0084] Furthermore, this embodiment ensures that the address coverage of the final output global batch request will not exceed the hardware limit of a single transmission of the CXL link due to excessive merging by introducing a comparison between the continuous address span and the upper limit of the span. This avoids transmission failure or retries caused by excessively large batches, and ultimately enables the global merger to stably output batch transmissions under complex conditions such as extremely high concurrency, sudden emergency requests, or limited queue resources.

[0085] In one embodiment, the step of dynamically adjusting the effective lower limit of the batch threshold and the global merging window duration based on the current queue level and the emergency request count further includes: Obtain the normalized water level value and the normalized emergency value. The normalized water level value is obtained by the current queue water level through piecewise linear mapping, and the normalized emergency value is obtained by the emergency request count through exponential decay smoothing. The normalized water level value is input into the water level threshold correction curve, and the threshold correction coefficient is output. The slope of the water level threshold correction curve is greater in the high water level range than in the low water level range. The normalized emergency value is input into the emergency duration correction curve, and the duration correction coefficient is output. The slope of the emergency duration correction curve is greater in the high emergency range than in the low emergency range. Multiply the threshold correction coefficient by the base value of the batch threshold to obtain the corrected batch threshold; multiply the duration correction coefficient by the base value of the global merge window duration to obtain the corrected effective lower limit.

[0086] It should be noted that the normalized water level value maps the current queue water level to a dimensionless value within a preset standard range, used to unify the water level representation under different queue capacities. Piecewise linear mapping uses linear functions with different slopes to transform the current queue water level according to different load ranges, making small changes in high load ranges more significantly reflected in the normalized value. The normalized emergency value maps the emergency request count to a dimensionless value within a preset standard range after exponential decay smoothing over time, used to suppress excessive interference from instantaneous spikes on corrective decisions.

[0087] The water level threshold correction curve is a function curve describing the mapping relationship between the normalized water level value and the threshold correction coefficient. This curve has a steeper slope when the normalized water level value is in the high water level range, resulting in a more drastic reduction in the batch threshold when the queue is more crowded. The emergency duration correction curve is a function curve describing the mapping relationship between the normalized emergency value and the duration correction coefficient. This curve has a steeper slope when the normalized emergency value is in the high emergency range, resulting in a more drastic reduction in the effective lower limit when emergency requests are more frequent.

[0088] The threshold correction factor is a scaling factor used to scale the base value of the batch threshold, and its value ranges from greater than 0 to less than 1. The duration correction factor is a scaling factor used to scale the base value of the global merging window duration, and its value ranges from greater than 0 to less than 1. The base value is the original configuration value of the batch threshold or the global merging window duration without dynamic correction. The corrected batch threshold is the actual threshold for the current judgment period obtained by multiplying the base value of the batch threshold by the threshold correction factor. The corrected effective lower limit is the actual effective lower limit for the current judgment period obtained by multiplying the base value of the global merging window duration by the duration correction factor.

[0089] It is understood that this embodiment uses piecewise linear mapping to process the current queue level, so that the normalized level value increases faster when the queue is close to full capacity than in the low level range. Thus, with the cooperation of the level threshold correction curve, the more crowded the queue, the greater the decrease in the corrected batch threshold, so that the fuller the queue, the lower the output threshold.

[0090] Furthermore, this embodiment employs exponential decay smoothing to process the emergency request count, ensuring that the corrected effective lower limit does not fluctuate drastically due to occasional high-priority requests within a very short period. This avoids prematurely cutting off the merging and accumulation of normal batch requests when the emergency request count is artificially high. Moreover, the water level threshold correction curve and the emergency duration correction curve in this embodiment adopt larger slopes in the high water level and high emergency intervals, respectively. This allows the correction sensitivity of the batch threshold and the effective lower limit to adaptively increase with increasing system pressure, thereby maximizing the preservation of the global merger's batch accumulation capability under moderate load and improving system stability and transmission efficiency.

[0091] In summary, this embodiment dynamically adjusts the global merge window duration based on the global queue depth, ensuring that the waiting time of the global merger matches the global request aggregation rate. This avoids insufficient merging rate under low load or queue congestion under high load due to a fixed window. At the same time, this embodiment fairly adds the output of each local merger to the global merge queue through polling order, ensuring that multiple CPU cores can obtain equal opportunities to participate in secondary merging regardless of which cluster they are in.

[0092] Furthermore, this embodiment, based on the precise calculation of global request address differences and threshold filtering, ensures that only requests from different clusters but with truly contiguous addresses are aggregated into a global merge request. This maximizes the data scale of a single batch transmission while ensuring data correctness, resulting in a further reduction in the number of global batch requests output by the global merger compared to the input local batch requests. Ultimately, the number of protocol transactions sent to the compute fast interconnect controller is minimized, thereby reducing fixed protocol overhead, alleviating queue congestion, and improving effective bandwidth utilization.

[0093] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the multi-core cross-path memory access method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0094] This application provides a multi-core cross-channel memory access device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-core cross-channel memory access method in Embodiment 1 above.

[0095] The following is for reference. Figure 8This document illustrates a structural diagram suitable for implementing a multi-core cross-channel memory access device according to embodiments of this application. The multi-core cross-channel memory access device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8 The multi-core cross-path memory access device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0096] like Figure 8 As shown, the multi-core cross-channel memory access device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. RAM 1004 also stores various programs and data required for the operation of the multi-core cross-channel memory access device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the multi-core cross-channel memory access device to communicate wirelessly or wiredly with other devices to exchange data. Although multi-core cross-channel memory access devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0097] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0098] The multi-core cross-path memory access device provided in this application, employing the multi-core cross-path memory access method described in the above embodiments, can solve the technical problem that current methods reduce system throughput and protocol efficiency. Compared with the prior art, the beneficial effects of the multi-core cross-path memory access device provided in this application are the same as those of the multi-core cross-path memory access method provided in the above embodiments, and other technical features of this multi-core cross-path memory access device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0099] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0100] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0101] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the multi-core cross-channel memory access method described in the above embodiments.

[0102] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0103] The aforementioned computer-readable storage medium may be included in a multi-core cross-channel memory access device; or it may exist independently and not be assembled into a multi-core cross-channel memory access device.

[0104] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a multi-core cross-channel memory access device, cause the multi-core cross-channel memory access device to execute the aforementioned multi-core cross-channel memory access method.

[0105] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0108] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described multi-core cross-channel memory access method, thereby solving the technical problem that current methods reduce system throughput and protocol efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the multi-core cross-channel memory access method provided in the above embodiments, and will not be repeated here.

[0109] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the multi-core cross-channel memory access method described above.

[0110] The computer program product provided in this application can solve the technical problem that current methods reduce system throughput and protocol efficiency. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the multi-core cross-channel memory access method provided in the above embodiments, and will not be repeated here.

[0111] All user-related data involved in this application was obtained with the user's permission or consent, as per [reference]. Figure 9 In other words, when this application is applied to a specific product or technology, user permission is required to acquire and process the relevant data, and the processing of the relevant data must comply with relevant laws, regulations and regulatory standards.

[0112] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A multi-core cross-channel memory access method, characterized in that, The method includes: Obtain memory access requests from each CPU core in each CPU core cluster, wherein the CPU core cluster is obtained by dividing multiple CPU cores; Based on the local merger corresponding to each CPU core cluster, the corresponding memory access requests are merged to obtain the local batch requests for each CPU core cluster. The local batch requests are sent to a preset global merger. Based on the global merger, the local batch requests are merged to obtain a global batch request. The global batch request is sent to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core; The local merger includes a local merge queue. The step of merging the corresponding memory access requests based on the local merger corresponding to each CPU core cluster to obtain the local batch requests for each CPU core cluster includes: Obtain the local queue depth of the local merge queue, and determine the local merge window duration based on the local queue depth; Based on the request priority field of the memory access request, determine whether the memory access request is a priority request; If the memory access request is not the priority sending request, then the memory access request is merged based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request to obtain the local batch request; The global merger includes a global merge queue, and the step of merging the local batch requests based on the global merger to obtain a global batch request includes: Obtain the global queue depth of the global merge queue, and determine the global merge window duration based on the global queue depth; Based on a preset polling order, the local batch requests corresponding to each local merger are added to the global merge queue in sequence to obtain a global queue request; Calculate the difference between the request addresses of each of the global queue requests to obtain the global request address difference; From the global request address differences, determine the target request address difference that is lower than the preset global address difference threshold, and merge the global queue requests corresponding to the target request address difference to obtain a global merged request; Based on the global merge window duration, it is determined whether the global merge request meets the preset request sending conditions. If it does not meet the conditions, the process returns to the step of adding the local batch requests corresponding to each local merger to the global merge queue in turn, based on the preset polling order, until the global merge request meets the request sending conditions, and the global merge request is used as the global batch request.

2. The method as described in claim 1, characterized in that, The step of merging the memory access requests based on the local merging window duration, the request operation type of the memory access request, and the request address of the memory access request to obtain the local batch requests includes: Obtain the merged request address and merged operation type of the merged access requests in the local merge queue, wherein the merged access requests are obtained by merging the memory access requests; For each memory access request, calculate the difference between the merged request address of the merged access request and the request address of the memory access request to obtain the request address difference; If the requested address difference is within a preset address difference threshold, and the merged operation type is the same as the requested operation type, then the memory access request is added to the local merge queue, and the memory access request is merged with the merged access request to obtain a new merged access request. Determine whether the merged access request meets the preset global merging condition. If it does not meet the condition, return to the step of obtaining the memory access requests of each CPU core in each CPU core cluster until the local merging queue meets the global merging condition, and then use the merged access request as the local batch request.

3. The method as described in claim 2, characterized in that, The step of determining whether the merged access request meets the preset global merging conditions further includes: The number of merged access requests and the merge window timer of the local merger are obtained, wherein the merge window timer is reset to a preset initial value each time the memory access request is added to the local merge queue. Determine whether the number of merged requests is lower than the local queue depth, and whether the merge window timer is lower than the local merge window duration; If the number of merged requests is lower than the local queue depth and the merge window timer is lower than the local merge window duration, then the local merge queue is determined to not meet the global merge conditions.

4. The method as described in claim 1, characterized in that, The step of determining whether the global merge request meets the preset request sending conditions based on the global merge window duration includes: Obtain the number of merged requests in the global merge request and the merge window timer of the global merger; Determine whether the number of merged requests is lower than a preset batch threshold and whether the merge window timer is lower than the global merge window duration; If the number of merged requests is not less than the batch threshold, or the merge window timer is not less than the global merge window duration, then the global merge request is determined to meet the request sending conditions.

5. The method as described in claim 1, characterized in that, After the step of sending the global batch request to a preset compute fast interconnect controller to complete cross-path memory access for each CPU core, the method further includes: The system receives return data sent by the compute fast interconnect controller, wherein the return data includes the request ID of each memory access request in the global batch request and the request return data of each memory access request; Based on the request ID and a preset request lookup mapping table, determine the target CPU core corresponding to each request ID; The data returned by each request is distributed to the corresponding target CPU core.

6. A multi-core cross-channel memory access device, characterized in that, The device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the multi-core cross-channel memory access method as described in any one of claims 1 to 5.

7. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the multi-core cross-channel memory access method as described in any one of claims 1 to 5.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the multi-core cross-channel memory access method as described in any one of claims 1 to 5.

Images