A multi-core oriented distributed storage management apparatus and computing device

Abstract

This invention discloses a distributed storage management device and computing device for multi-core systems. The distributed storage management device includes a DVM proxy module, a DVM remote sending module, and a DVM remote receiving module, each deployed in each core. The DVM proxy module receives DVM request messages containing invalidation address information submitted by the core node in its core, and uses a distributed broadcast mechanism to send the DVM request messages to the core nodes and IO nodes of its core and other cores, thereby invalidating the invalidation addresses carried in the DVM request messages to achieve a unified memory view. This invention aims to solve the cache consistency problem of invalidating large areas of address space data in multi-core systems, including broadcasting invalidation information of DVM operations, avoiding deadlocks in DVM synchronization operations between multiple cores, and optimizing the excessively long execution latency of DVM operations in multi-core scenarios.

Description

Technical Field

[0001] This invention relates to the field of multi-chip inter-chip consistency interconnect technology, and more specifically to a distributed storage management device and computing device for multi-chip systems. Background Technology

[0002] Inter-chip coherent interconnects are primarily used for coherent connections between processors (or accelerators). They ensure cache coherency across multiple processors, overcoming resource bottlenecks of individual chips and coordinating and integrating the computing, storage, and I / O resources of various processors. To meet the current performance demands for high bandwidth and low latency between processors (or accelerators), major international chip manufacturers have proposed various chip coherent interconnect technologies at different times in recent years, such as CCIX and CXL interconnect technologies. Large processors composed of multiple chips can form a globally shared coherent system, providing abundant hardware resources and facilitating parallel computing among chips, thus shortening computation time. However, in the practice of multi-chip coherent interconnect interoperability, the time cost of maintaining cache coherency between chips increases with the number of chips. This is especially true in scenarios such as process migration, multi-process synchronization, and process termination, where data invalidation in large address spaces is required, placing even higher demands on cache coherency latency.

[0003] To address the issue of large-scale address space data obsolescence, the CHI protocol introduces DVM (Distributed Virtual Memory) operations. These operations can perform global obsolescence and synchronization for different buffer types, thereby unifying the memory view and maintaining cache consistency. DVM operations can be categorized into TLB page table obsolescence, branch predictor obsolescence, instruction cache obsolescence, and synchronization operations. The first three are asynchronous obsolescence operations, which can initiate other DVM request messages without waiting for completion, allowing multiple operations to run concurrently. Synchronization operations ensure that all requesting nodes (such as processor core nodes and main I / O nodes) complete all received asynchronous operations, serving a synchronization function; they themselves do not carry any obsolescence information.

[0004] The DVM data path primarily involves interactions between all requesting nodes (processor core nodes and IO nodes requiring obsolescence), DVM operation management nodes (DN: DVM Node), and routing nodes (CELL). Any processor core node (referred to as a core node) can act as both the initiator and completer of a DVM request message. CELL nodes mainly function as routers and interconnectors, ensuring communication between all connected modules. DN nodes are DVM operation management nodes, responsible for receiving and broadcasting all DVM operations within the system. When a core node sends a DVM request message, it is transmitted to the DN node via the CELL node. Upon receiving a complete DVM message, the DN node broadcasts it to all other core nodes and IO nodes requiring obsolescence. Each core node (or IO node) that receives a DVM message sends a response message to the DN node. Once all response messages are collected, the DN node sends a response message to the original requesting node, indicating that the DVM request message has been completed. Through the above process, DVM messages carrying obsolescence information can be broadcast to all nodes in the system that need obsolescence, and obsolescence can be performed, thereby unifying the memory view and achieving cache consistency. Simultaneously, by using different types of DVM operations and filling in address information, different obsolescence objects can be obsolescenced. It should be noted that the CHI protocol is designed for single-die systems and does not involve multi-die interconnects. That is, the DVM operations described above can only solve the cache consistency problem for large areas of address space in a single die. To solve the cache consistency problem for large areas of address space in multi-die systems, the fundamental issues are: first, how to broadcast the obsolescence information carried by the DVM operation to the core nodes or IO nodes of all other dies; second, how to avoid deadlock problems in DVM synchronization operations between multiple dies; and finally, how to optimize the excessive execution latency of DVM operations in multi-die scenarios. Summary of the Invention

[0005] The technical problem to be solved by the present invention is as follows: In view of the above-mentioned problems of the prior art, the present invention provides a distributed storage management device and computing device for multi-core particles. The present invention aims to solve the cache consistency problem of invalidation of large address space data in multi-core particles, including the problem of broadcasting invalidation information of DVM operation, avoiding deadlock of DVM synchronization operation between multi-core particles, and optimizing the excessively long execution latency of DVM operation in multi-core particle scenarios.

[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0007] A distributed storage management device for multiple cores includes a DVM proxy module, a DVM remote sending module, and a DVM remote receiving module, each deployed in each core. The DVM proxy module receives DVM request messages containing invalidated address information submitted by the core node in its core, broadcasts the DVM request messages in a distributed manner (including adding them to a local transaction queue and broadcasting the DVM request messages in the local transaction queue to the core node and I / O nodes of the core to invalidate the invalidated addresses carried in the DVM request messages to achieve a unified memory view), and generates DVM broadcast messages and submits them to the DVM remote sending module. The DVM remote sending module receives the DVM broadcast messages from the DVM proxy module. The DVM remote receiving module receives DVM broadcast messages from DVM remote sending modules in other cores and submits them to the DVM proxy module. The DVM proxy module then sends DVM request messages from DVM broadcast messages from other cores to a remote transaction queue and broadcasts these messages to the core nodes and I / O nodes of the core to invalidate the invalidated addresses carried in the DVM request messages, thus achieving a unified memory view. Finally, it generates DVM response messages and submits them to the DVM remote sending module for transmission to other cores.

[0008] Optionally, the DVM proxy module includes three pipelines: a first DVM request pipeline, a second broadcast response pipeline, and a third DVM broadcast request pipeline. The DVM request pipeline is used to receive and process DVM request messages from all core nodes in the kernel and other kernels. The broadcast response pipeline is used to collect responses to DVM broadcast messages and reply with DVM response messages to the original core node. The DVM broadcast request pipeline is used to transmit obsolete address information to all core nodes, I / O nodes that need it, and the DVM remote transmission module.

[0009] Optionally, the DVM request pipeline includes four stations: M0, M1, R1, and R2; the broadcast response pipeline includes four stations: M0, M1, R1, and R2, and is merged with the DVM request pipeline; the DVM broadcast request pipeline includes two stations: S1 and S2; station M0 is located at the link layer. From station M0 to station M1, the DVM request pipeline first checks if there is any free space in the local transaction queue or the remote transaction queue. If there is no free space, a retransmission response message is sent to the original requesting node; if there is a free space, a credit granting message is sent to the original requesting node or a retransmission response message is received. The system receives DVM request messages, parses them, and stores the DVM obsolescence address information and control information from the message into the idle entries of either the local or remote transaction queue, based on the requesting device type. The local transaction queue records DVM request messages from all core nodes of the local core, while the remote transaction queue records DVM request messages from all core nodes of other cores. From station M0 to station M1, the broadcast response pipeline receives DVM response messages and updates the broadcast counters of the corresponding transaction entries in the local or remote transaction queues. From station M1 to station R1, DV... The M-request pipeline and broadcast response pipeline categorize the DVM broadcast messages or DVM response messages to be sent from the local or remote transaction queue into four types: local asynchronous, local synchronous, remote asynchronous, and remote synchronous. A round-robin arbitration algorithm is used to select one transaction from each of these four types. From station R1 to station R2, the DVM request pipeline and broadcast response pipeline use an LRU arbitration algorithm to select one of the four transaction items. Based on the arbitration result, station R2 generates the transmission vector for the DVM broadcast message or sends the DVM response message. The vector corresponds to the destination node to which the DVM broadcast message is sent. After obtaining the sending vector of the DVM broadcast message, the DVM broadcast state machine converts the sending vector into a recognizable physical identifier (TgtID) to transmit the DVM broadcast message to each destination node. From station S1 to station S2, the DVM broadcast request pipeline assembles a new DVM broadcast message and fills it with destination nodes that are not currently being broadcast, according to the DVM broadcast state machine. In station S2, the DVM broadcast request pipeline sends the DVM broadcast message and tells the DVM broadcast state machine that the destination node has been sent.

[0010] Optionally, the DVM broadcast state machine includes five states: Idle (IDLE), Active (ACTIVE), Send Data Identifier and Receive Data (SENT_DBID_DBVALID), Send DVM Broadcast Message (SENTREQ), and Send Response Message (SENTCOMP). The Idle (IDLE) state indicates that a transaction queue item is idle; the Active (ACTIVE) state indicates that a transaction queue item has received a DVM request; the Send Data Identifier and Receive Data (SENT_DBID_DBVALID) state indicates that a transaction queue item has received a DVM invalidation message; and the Send DVM Broadcast Message (SENTREQ) state indicates that a transaction queue item has received a DVM invalidation message. The SENTREQ broadcast state indicates that a transaction queue item is in the state of sending a DVM broadcast message, and the SENTCOMP response state indicates that a transaction queue item is sending a response message. The DVM broadcast state machine enters the IDLE state after system startup. The transition conditions for the five states are as follows: State transition condition ①: In the IDLE state, when a transaction queue item is not requested, it is in the IDLE state; State transition condition ②: In the IDLE state, when a transaction queue item is requested, it transitions to the ACTIVE state; State transition condition ③: In the ACTIVE state... Under IVE, the transaction queue item unconditionally transitions to the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ④: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue item has not collected all DVM obsolescence information, the transaction queue item remains in the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ⑤: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue item collects all DVM obsolescence information, the transaction queue item transitions to the Send DVM state. SENTREQ broadcast message state; State transition condition ⑥: Under the SENTREQ state, when the transaction queue item collects all the response messages for the DVM broadcast request, the transaction queue item transitions to the SENTCOMP state; State transition condition ⑦: Under the SENTREQ state, when an error is detected in the verification of the collected DVM obsolescence information data, an error response message is sent to the original requesting node, and the transaction queue item transitions to the IDLE state; State transition condition ⑧: Under the SENTCOMP state, the transaction queue item unconditionally transitions to the IDLE state.

[0011] Optionally, the DVM remote sending module includes two pipelines, wherein the first pipeline is a DVM broadcast request pipeline, used to send the cross-core DVM broadcast message sent by the DVM agent module to other cores; the second pipeline is a DVM broadcast response pipeline, used to reply with a DVM response message to the DVM agent module of the core after collecting the responses to the DVM broadcast requests of other cores.

[0012] Optionally, the first pipeline of the DVM remote transmission module includes four stations: R10 to R13. Station R10 is located at the link layer and is used to establish a data path to the link layer connected to it. From station R10 to station R11, the DVM broadcast message is parsed, and the DVM obsolescence address information and control information in the message are stored in the idle item of the transmission transaction queue (DVM Tracker1). The transmission transaction queue (DVM Tracker1) is used to record the DVM obsolescence address information and the completion status of the DVM request. From station R11 to station R12, if the DVM remote transmission module has not handshaked with the remote core, it directly sends a DVM response message. If the handshake is successful, the message is retrieved from the transmission transaction queue (DVM Tracker1). In Tracker1, a DVM broadcast message is selected to form a new cross-core state machine. From station R12 to station R13, the multi-core state machine fills the new message with the routing information of the destination cores that have not yet been broadcast. From station R13 to station D1 of the second pipeline, a new message is sent and the multi-core state machine is informed that the destination core has been sent. If there are still destination cores that have not been broadcast, the routing information will continue to be updated and sent until all destination cores have been broadcast to the station. Only then can station R12 accept the next cross-core state machine message.

[0013] Optionally, the second pipeline of the DVM remote transmission module includes three stations, D1 to D3, where D1 is a link layer station. From D1 to D2, the DVM broadcast response message is parsed and matched with the transaction queue item in the transmission transaction queue (DVM Tracker1). From D2 to D3, a transaction queue item that has collected all kernel responses is selected from the transmission transaction queue (DVM Tracker1), and the corresponding DVM response message is concatenated. D3 is used to send the DVM response message.

[0014] Optionally, the DVM remote receiving module includes two pipelines. The first pipeline is a cross-core request message pipeline, used to receive cross-core messages from DVM remote sending modules of other cores and send the request messages to the DVM agent module of the core. The second pipeline is a DVM response pipeline, used to receive DVM response messages, cancel the transaction queue entry of the corresponding DVM broadcast message, and send cross-core DVM response messages.

[0015] Optionally, the first pipeline of the DVM remote receiving module includes a receive transaction queue (DVMTracker2) and a retransmission buffer. The receive transaction queue (DVM Tracker2) is used to receive DVM request messages from other cores across cores. The retransmission buffer is mainly used to handle flow control with the DVM agent module. When the DVM agent module sends a retransmission response message, the retransmission buffer updates the transaction queue entries in the receive transaction queue (DVM Tracker2) to the retransmission state and waits for the DVM agent module to send a credit grant message until the transaction queue entries in the receive transaction queue (DVMTracker2) that are in the retransmission state are selected and sent.

[0016] Furthermore, the present invention also provides a computing device including a multi-chip microprocessor and a memory interconnected thereto, wherein the multi-chip microprocessor includes the multi-chip-oriented distributed memory management device.

[0017] Compared with the prior art, the present invention can mainly achieve the following beneficial effects:

[0018] 1. This invention proposes a distributed broadcast method for multi-core distributed storage management by designing a multi-core distributed storage management device. This method broadcasts DVM messages carrying invalidation address information to all nodes within the system that need to be invalidated, and then invalidates them, thereby unifying the memory view and achieving cache consistency. Distributed broadcasting offers significant advantages: each core has its own DVM agent module, allowing for localized broadcasting and reducing broadcast time. Simultaneously, each DVM agent module has its own transaction queue, enabling independent transaction processing and improving task parallelism.

[0019] 2. This invention proposes a method to solve deadlock and save cross-die latency by designing a distributed storage management device for multiple dies. The DVM proxy module solves the deadlock problem by providing transaction management methods for local and remote transaction queues and a state machine for the state transition of each transaction. The DVM proxy module, DVM remote receiving module, and DVM remote receiving module save cross-die latency by setting up a dedicated DVM buffer, allowing DVM messages to be transmitted directly from the starting die to the destination die without waiting. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the dual-core structure of the distributed storage management device in an embodiment of the present invention.

[0021] Figure 2 This is a schematic diagram of the DVM request message broadcast inside the core in an embodiment of the present invention.

[0022] Figure 3This is a schematic diagram of the structure of the DVM agent module in an embodiment of the present invention.

[0023] Figure 4 This is a schematic diagram illustrating the working principle of the DVM broadcast state machine in the DVM proxy module of this invention.

[0024] Figure 5 This is a schematic diagram illustrating the working principle of the DVM remote transmission module in an embodiment of the present invention.

[0025] Figure 6 This is a schematic diagram illustrating the working principle of the DVM remote receiving module in an embodiment of the present invention. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0027] like Figure 1 As shown, this embodiment of the distributed storage management device for multiple cores includes a DVM proxy module, a DVM remote sending module, and a DVM remote receiving module, each deployed in each core. The DVM proxy module receives DVM request messages containing invalidated address information submitted by the core node in its core, broadcasts the DVM request messages in a distributed manner (including adding them to a local transaction queue and broadcasting the DVM request messages in the local transaction queue to the core node and I / O nodes of the core to invalidate the invalidated addresses carried in the DVM request messages to achieve a unified memory view), and generates DVM broadcast messages and submits them to the DVM remote sending module. The DVM remote sending module is used to transmit the DVM broadcast messages from the DVM proxy module... The DVM broadcast message and DVM response message are sent to other cores with which it communicates; the DVM remote receiving module is used to receive DVM broadcast messages sent by DVM remote sending modules in other cores and submit the DVM broadcast messages to the DVM proxy module; the DVM proxy module sends the DVM request messages in the DVM broadcast messages from other cores into the remote transaction queue and broadcasts the DVM request messages in the remote transaction queue to the core node and IO node of the core to invalidate the invalidated addresses carried in the DVM request messages to achieve a unified memory view, and then generates DVM response messages and submits the DVM response messages to the DVM remote sending module to broadcast to other cores with which it communicates.

[0028] like Figure 1As shown, core node 0 of core node 0 transmits a DVM message carrying address invalidation information to the DVM proxy module; the DVM proxy module then transmits the DVM broadcast message to core node 1, core node 2 of core node 0, and the DVM remote transmission module; next, the DVM remote transmission module sends the DVM broadcast message to the DVM remote receiving module of core node 1; the DVM remote receiving module of core node 1 transmits the DVM broadcast message to the DVM proxy module of core node 1; the DVM proxy module of core node 1 then transmits the DVM broadcast message to the core node 1's DVM remote receiving module. The process involves collecting DVM response messages from three core nodes: core node 0, core node 1, and core node 2. Then, it replies with a DVM response message to the DVM remote receiving module of core node 1. The response message is then transmitted to the DVM proxy module of core node 0 via the DVM remote sending module. After collecting the DVM response messages from core node 1, core node 2, and the DVM remote sending module, the DVM proxy module of core node 0 replies with a DVM response message to core node 0, indicating that the DVM operation is complete. Figure 2 As shown, for a specific core consisting of core nodes 0 to 3, the DVM request message broadcasting method within the core is as follows: Core node 0 transmits a DVM message carrying address invalidation information to the DVM agent module; the DVM agent module transmits the DVM broadcast message to core nodes 1, 2, and 3 respectively; then, after waiting to collect the response messages from the three cores, it replies with a response message to core node 0, notifying that the DVM operation has been completed.

[0029] In this embodiment, the DVM proxy module employs distributed broadcasting. Each core node has only one DVM proxy module, which receives DVM requests from all processor core nodes (referred to as core nodes) within its core node and broadcasts each DVM request to its own core node, the core nodes of other core nodes, and any I / O nodes that require it. Simultaneously, the DVM proxies between core nodes communicate via the DVM remote sending module and the DVM remote receiving module. To prevent deadlock, the DVM proxy module provides transaction management methods for local and remote transaction queues, as well as a state transition machine for each transaction.

[0030] like Figure 3 As shown, the DVM proxy module in this embodiment includes three pipelines: the first is a DVM request pipeline, the second is a broadcast response pipeline, and the third is a DVM broadcast request pipeline. The DVM request pipeline is used to receive and process DVM request messages from all core nodes in the kernel and other kernels. The broadcast response pipeline is used to collect responses to DVM broadcast messages and reply with DVM response messages to the original core node. The DVM broadcast request pipeline is used to transmit obsolete address information to all core nodes, I / O nodes that need it, and the DVM remote transmission module.

[0031] like Figure 3 As shown, the DVM request pipeline in this embodiment includes four stations: M0, M1, R1, and R2; the broadcast response pipeline also includes four stations: M0, M1, R1, and R2, and is merged with the DVM request pipeline; the DVM broadcast request pipeline includes two stations: S1 and S2; station M0 is located at the link layer. From station M0 to station M1, the DVM request pipeline first checks if there is any free space in the local or remote transaction queue. If there is no free space, it sends a retransmission response message to the original requesting node; if there is a free space, it sends a credit granting message to the original requesting node. The system receives or parses DVM request messages, and stores the DVM obsolescence address information and control information from the message into the idle entries of the local transaction queue or the remote transaction queue, based on the requesting device type. The local transaction queue records DVM request messages from all core nodes of the current core, while the remote transaction queue records DVM request messages from all core nodes of other cores. From station M0 to station M1, the broadcast response pipeline receives DVM response messages and updates the broadcast counter of the corresponding transaction item in the local or remote transaction queue. From station M1 to station R1... The DVM request pipeline and broadcast response pipeline categorize the DVM broadcast messages or DVM response messages to be sent from the local or remote transaction queue into four types: local asynchronous, local synchronous, remote asynchronous, and remote synchronous. A round-robin arbitration algorithm is used to select one transaction from each of these four types. From station R1 to station R2, the DVM request pipeline and broadcast response pipeline use an LRU arbitration algorithm to select one of the four transaction items. Based on the arbitration result, station R2 generates the transmission vector for the DVM broadcast message or sends a DVM response message. The sending vector corresponds to the destination node to which the DVM broadcast message is sent. After obtaining the sending vector of the DVM broadcast message, the DVM broadcast state machine converts the sending vector into a recognizable physical identifier (TgtID) to transmit the DVM broadcast message to each destination node. From station S1 to station S2, the DVM broadcast request pipeline assembles a new DVM broadcast message and fills in the DVM broadcast message with the destination nodes that are not currently being broadcast, according to the DVM broadcast state machine. In station S2, the DVM broadcast request pipeline sends the DVM broadcast message and tells the DVM broadcast state machine that the destination node has been sent.

[0032] like Figure 4As shown, the DVM broadcast state machine in this embodiment includes five states: Idle (IDLE), Active (ACTIVE), Send Data Identifier and Receive Data (SENT_DBID_DBVALID), Send DVM Broadcast Message (SENTREQ), and Send Response Message (SENTCOMP). The Idle (IDLE) state indicates that the transaction queue item is idle; the Active (ACTIVE) state indicates that the transaction queue item has received a DVM request; the Send Data Identifier and Receive Data (SENT_DBID_DBVALID) state indicates that the transaction queue item has received a DVM invalidation message; and the Send DVM Broadcast Message (SENTREQ) state indicates that the transaction queue item has received a DVM invalidation message. The SENTREQ broadcast message state indicates that a transaction queue item is in the state of sending a DVM broadcast message, and the SENTCOMP response message state indicates that a transaction queue item is sending a response message. The DVM broadcast state machine enters the IDLE state after system startup. The transition conditions for the five states are as follows: State transition condition ①: In the IDLE state, when a transaction queue item is not requested, it is in the IDLE state; State transition condition ②: In the IDLE state, when a transaction queue item is requested, it transitions to the ACTIVE state; State transition condition ③: In the ACTIVE state... Under TIVE, the transaction queue entry unconditionally transitions to the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ④: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue entry has not collected all DVM obsolescence information, the transaction queue entry remains in the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ⑤: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue entry collects all DVM obsolescence information, the transaction queue entry transitions to the Send DVM state. Broadcast Message State (SENTREQ); State Transition Condition ⑥: Under the SENTREQ state, when the transaction queue item collects all the response messages for the DVM broadcast request, the transaction queue item transitions to the SENTCOMP state; State Transition Condition ⑦: Under the SENTREQ state, when an error is detected in the verification of the collected DVM obsolescence information data, an error response message is sent to the original requesting node, and the transaction queue item transitions to the Idle state (IDLE); State Transition Condition ⑧: Under the SENTCOMP state, the transaction queue item unconditionally transitions to the Idle state.

[0033] The DVM remote transmission module receives cross-core DVM broadcast messages from the DVM agent module and broadcasts these messages to the cores it communicates with. To minimize latency caused by flow control, the DVM remote transmission module and the DVM agent need to agree on a threshold for the number of broadcast messages that can be sent. For example, when the threshold is 4, the DVM agent can only send 4 DVM broadcast messages to the DVM remote transmission module simultaneously.

[0034] like Figure 5 As shown, the DVM remote sending module in this embodiment includes two pipelines. The first pipeline is a DVM broadcast request pipeline, which is used to send the cross-core DVM broadcast message sent by the DVM proxy module to other cores. The second pipeline is a DVM broadcast response pipeline, which is used to reply with a DVM response message to the DVM proxy module of the core after collecting the responses to the DVM broadcast requests from other cores.

[0035] like Figure 5 As shown, the first pipeline of the DVM remote transmission module in this embodiment includes four stations: R10 to R13. Station R10 is located at the link layer and is used to establish a data path for the link layer connected to it. From station R10 to station R11, the DVM broadcast message is parsed, and the DVM obsolescence address information and control information in the message are stored in the idle item of the transmission transaction queue (DVMTracker1). The transmission transaction queue (DVM Tracker1) is used to record the DVM obsolescence address information and the completion status of the DVM request. From station R11 to station R12, if the DVM remote transmission module has not handshaked with the remote core, it directly sends a DVM response message. If the handshake is successful, the message is retrieved from the transmission transaction queue (DVM Tracker1). In Tracker1, a DVM broadcast message is selected to form a new cross-core state machine. From station R12 to station R13, the multi-core state machine fills the new message with the routing information of the destination cores that have not yet been broadcast. From station R13 to station D1 of the second pipeline, a new message is sent and the multi-core state machine is informed that the destination core has been sent. If there are still destination cores that have not been broadcast, the routing information will continue to be updated and sent until all destination cores have been broadcast to the station. Only then can station R12 accept the next cross-core state machine message.

[0036] like Figure 5As shown, the second pipeline of the DVM remote transmission module in this embodiment includes three stations, D1 to D3. Station D1 is the link layer. From station D1 to station D2, the DVM broadcast response message is parsed and matched with the transaction queue item in the transmission transaction queue (DVMTracker1). From station D2 to station D3, a transaction queue item that has collected all core responses is selected from the transmission transaction queue (DVM Tracker1), and the corresponding DVM response message is concatenated. Station D3 is used to send the DVM response message.

[0037] The DVM remote receiving module receives cross-core DVM broadcast messages from the DVM remote sending module and forwards them to the DVM agent module within the corresponding core. To reduce the time overhead of cross-core DVM broadcast messages, a dedicated DVM buffer is established to store DVM broadcast messages from different cores. For example, when communication with 7 cores is possible and the threshold number is 4, the DVM remote receiving module needs to set up 7 dedicated DVM buffers—receive transaction queues (DVM Tracker2)—with a depth of 4 to save on the overhead of cross-core flow control.

[0038] like Figure 6 As shown, the DVM remote receiving module in this embodiment includes two pipelines. The first pipeline is a cross-core request message pipeline, which is used to receive cross-core messages from the DVM remote sending module of other cores and send the request message to the DVM agent module of the core. The second pipeline is a DVM response pipeline, which is used to receive DVM response messages, cancel the transaction queue entry of the corresponding DVM broadcast message, and send cross-core DVM response messages.

[0039] like Figure 6 As shown, the first pipeline of the DVM remote receiving module in this embodiment includes a receive transaction queue (DVM Tracker2) and a retransmission buffer. The receive transaction queue (DVM Tracker2) is used to receive DVM request messages from other granules across granules. The retransmission buffer is mainly used to handle flow control between the DVM agent module and the DVM agent module. When the DVM agent module sends a retransmission response message, the retransmission buffer updates the transaction queue entries in the receive transaction queue (DVM Tracker2) to the retransmission state and waits for the DVM agent module to send a credit grant message until the transaction queue entries in the receive transaction queue (DVM Tracker2) that are in the retransmission state are selected and sent.

[0040] In summary, this embodiment implements a centralized proxy mechanism to solve the distributed broadcast problem by designing a DVM proxy module, a DVM remote sending module, and a DVM remote receiving module in each core. Each core contains only one DVM proxy node. All requesting nodes in the core send DVM requests to the same DVM proxy node, which then broadcasts the address invalidation information carried in the DVM request to all core nodes or I / O nodes. The term "distributed" refers to the fact that in a multi-core system, each core has one DVM proxy node. Each proxy node only manages the core node or I / O node of its assigned core. Furthermore, DVM requests need to be exchanged between proxies to achieve the broadcasting purpose. This embodiment employs distributed broadcasting of DVM request messages. This includes sending them to a local transaction queue and broadcasting the DVM request messages in the local transaction queue to the core nodes and I / O nodes of the corresponding core to invalidate the invalidated addresses carried in the DVM request messages, thus achieving a unified memory view. Additionally, a DVM proxy module sends DVM request messages from other cores to a remote transaction queue, and then broadcasts the DVM request messages in the remote transaction queue to the core nodes and I / O nodes of the corresponding core to invalidate the invalidated addresses carried in the DVM request messages, again achieving a unified memory view. By setting up two independent transaction queues for the DVM proxy node to handle local and remote requests respectively, and ensuring that only one synchronization request is broadcast at a time, the DVM proxy node can effectively resolve deadlock issues. Regarding deadlock, in a single-core system, the DVM proxy node must ensure that only one synchronization request is broadcast at a time; otherwise, deadlock may occur. For example, when the DVM proxy node receives two DVM synchronization requests from different cores, it can only broadcast one DVM synchronization request. The next DVM synchronization request can only be broadcast after all response messages have been received. This constraint must also be met in multi-core systems. Secondly, two independent transaction queues should be set up for the DVM agent nodes to handle local and remote requests respectively; otherwise, protocol-level deadlocks may occur. Regarding the issue of excessive execution latency of DVM operations in multi-core scenarios, the time overhead of DVM cross-core transmission mainly occurs in the cross-core path. During the cross-core transmission of DVM messages, the time overhead at the physical layer is difficult to optimize and needs to be optimized at the protocol layer. This embodiment implements a flow control mechanism that combines retransmission and credit mechanisms between protocol layers. This two-pronged flow control is applied when the receiver's hardware resources are limited. When the sender knows that the receiver cannot receive messages, the sender can only wait for the receiver to have resources before sending messages. This is combined with a dedicated DVM buffer. In this case, DVM messages can be directly transmitted from the origin core to the destination core without waiting, thus effectively solving the problem of excessive execution latency of DVM operations in multi-core scenarios.This embodiment, through the combination of the above-mentioned technical means, can solve the cache consistency problem of invalidating large areas of address space data in multi-core particles. This includes broadcasting the invalidation information of DVM operations to the core nodes and IO nodes of the particle and other particles, avoiding deadlocks in DVM synchronization operations between multiple particles, and optimizing the excessively long execution latency of DVM operations in multi-core particle scenarios, thereby improving the efficiency and reliability of distributed storage management in multi-core particles.

[0041] In addition, this embodiment also provides a computing device including a multi-chip microprocessor and a memory interconnected thereto, wherein the multi-chip microprocessor includes the multi-chip-oriented distributed storage management device.

[0042] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A distributed storage management device for multi-core memory, characterized in that, The system includes a DVM proxy module, a DVM remote sending module, and a DVM remote receiving module, each deployed in its own core. The DVM proxy module receives DVM request messages containing invalidated address information submitted by the core node in its core, and broadcasts these messages in a distributed manner. This includes adding the messages to a local transaction queue and broadcasting the DVM request messages in the local transaction queue to the core node and I / O nodes of the core to invalidate the invalidated addresses carried in the DVM request messages, thus achieving a unified memory view. It also generates DVM broadcast messages and submits them to the DVM remote sending module. The DVM remote sending module sends DVM broadcast messages and DVM response messages from the DVM proxy module to other cores with which it communicates. The DVM remote receiving module receives DVM broadcast messages from the DVM remote sending modules in other cores and submits these messages to the DVM proxy module. The DVM proxy module also sends DVM request messages from DVM broadcast messages in other cores to a remote transaction queue and broadcasts the DVM request messages in the remote transaction queue to the core node of the core. The system uses nodes and I / O nodes to invalidate the invalidated addresses carried in the DVM request messages to achieve a unified memory view. It then generates DVM response messages and submits them to the DVM remote transmission module for distribution to other communicating cores. The DVM proxy module includes three pipelines: a DVM request pipeline, a broadcast response pipeline, and a DVM broadcast request pipeline. The DVM request pipeline receives and processes DVM request messages from all core nodes of the core and other cores. The broadcast response pipeline is used to collect responses to DVM broadcast messages and reply with DVM response messages to the original core nodes. The DVM broadcast request pipeline is used to transmit obsolete address information to all core nodes, I / O nodes that need it, and the DVM remote transmission module. The DVM request pipeline includes four stations: M0, M1, R1, and R2. The broadcast response pipeline includes four stations: M0, M1, R1, and R2, and is merged with the DVM request pipeline. The DVM broadcast request pipeline includes two stations: S1 and S2. Station M0 is located at the link layer. From station M0 to station M1, the DVM request pipeline first checks if there is any free space in the local or remote transaction queue. If there is no free space, it sends a retransmission response message to the original requesting node. If there is a free space, it sends a credit grant message to the original requesting node or receives a DVM request message. Then, it parses the DVM request message and stores the DVM deactivation address information and control information in the message into the free space of the local or remote transaction queue, based on the requesting device type. The local transaction queue is used to record DVM request messages from all core nodes in the local core, and the remote transaction queue is used to record DVM request messages from all core nodes in other cores. From station M0 to station M1, the broadcast response pipeline receives the DVM response message and updates... The broadcast counter for the corresponding transaction item in the new local transaction queue or remote transaction queue; from station M1 to station R1, the DVM request pipeline and broadcast response pipeline divide the transaction items of the DVM broadcast message or DVM response message to be sent in the local transaction queue or remote transaction queue into the following four categories: local asynchronous, local synchronous, remote asynchronous, and remote synchronous, and select one transaction item from each of the above four categories using a round-robin arbitration algorithm; from station R1 to station R2, the DVM request pipeline and broadcast response pipeline select one of the four transaction items using an LRU arbitration algorithm, and station R2 generates the sending vector of the DVM broadcast message or sends the DVM response message according to the arbitration result, where the sending vector corresponds to the destination node to which the DVM broadcast message is sent; After obtaining the transmission vector of the DVM broadcast message, the DVM broadcast state machine converts the transmission vector into a recognizable physical identifier (TgtID) to transmit the DVM broadcast message to each destination node. From station S1 to station S2, the DVM broadcast request pipeline assembles a new DVM broadcast message and fills it with destination nodes that are not currently being broadcast, according to the DVM broadcast state machine. At station S2, the DVM broadcast request pipeline sends the DVM broadcast message and informs the DVM broadcast state machine that the destination node has been sent.

2. The distributed storage management device for multi-core applications according to claim 1, characterized in that, The DVM broadcast state machine includes five states: Idle (IDLE), Active (ACTIVE), Send Data Identifier and Receive Data (SENT_DBID_DBVALID), Send DVM Broadcast Message (SENTREQ), and Send Response Message (SENTCOMP). The Idle (IDLE) state indicates that a transaction queue item is idle; the Active (ACTIVE) state indicates that a transaction queue item has received a DVM request; and the Send Data Identifier and Receive Data (SENT_DBID_DBVALID) state indicates that a transaction queue item has received DVM invalidation information and sends a DVM broadcast message. The state (SENTREQ) indicates that a transaction queue item is in the state of sending a DVM broadcast message, and the state (SENTCOMP) indicates that a transaction queue item is sending a response message. The DVM broadcast state machine enters the idle state (IDLE) after system startup. The transition conditions for the five states include: State transition condition ①: In the idle state (IDLE), when a transaction queue item is not requested, it is in the idle state; State transition condition ②: In the idle state (IDLE), when a transaction queue item is requested, it transitions to the active state (ACTIVE); State transition condition ③: In the active state (ACTIVE)... Under condition E), the transaction queue entry unconditionally transitions to the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ④: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue entry has not collected all DVM obsolescence information, the transaction queue entry remains in the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID); State transition condition ⑤: Under the Send Data Identifier and Receive Data State (SENT_DBID_DBVALID), when the transaction queue entry collects all DVM obsolescence information, the transaction queue entry transitions to Send DVM Broadcast. Message state (SENTREQ); State transition condition ⑥: Under the SENTREQ state, when the transaction queue item collects all the response messages for the DVM broadcast request, the transaction queue item transitions to the SENTCOMP state; State transition condition ⑦: Under the SENTREQ state, when an error is detected in the verification of the collected DVM obsolescence information data, an error response message is sent to the original requesting node, and the transaction queue item transitions to the Idle state (IDLE); State transition condition ⑧: Under the SENTCOMP state, the transaction queue item unconditionally transitions to the Idle state.

3. The distributed storage management device for multi-core components according to claim 1, characterized in that, The DVM remote transmission module includes two pipelines. The first pipeline is a DVM broadcast request pipeline, which is used to send the cross-core DVM broadcast message sent by the DVM agent module to other cores. The second pipeline is a DVM broadcast response pipeline, which is used to reply with a DVM response message to the DVM agent module of the core after collecting the responses to the DVM broadcast requests from other cores.

4. The distributed storage management device for multi-core components according to claim 3, characterized in that, The first pipeline of the DVM remote transmission module includes four stations: R10 to R13. Station R10 is located at the link layer and is used to establish a data path to the linked layer. From station R10 to station R11, the DVM broadcast message is parsed, and the DVM obsolescence address information and control information in the message are stored in the idle item of the transmission transaction queue (DVM Tracker1). The transmission transaction queue (DVM Tracker1) is used to record the DVM obsolescence address information and the completion status of the DVM request. From station R11 to station R12, if the DVM remote transmission module has not handshaked with the remote core, it directly sends a DVM response message. If the handshake is successful, the message is retrieved from the transmission transaction queue (DVM Tracker1). In Tracker1, a DVM broadcast message is selected to form a new cross-core state machine. From station R12 to station R13, the multi-core state machine fills the new message with the routing information of the destination cores that have not yet been broadcast. From station R13 to station D1 of the second pipeline, a new message is sent and the multi-core state machine is informed that the destination core has been sent. If there are still destination cores that have not been broadcast, the routing information will continue to be updated and sent until all destination cores have been broadcast to the station. Only then can station R12 accept the next cross-core state machine message.

5. The distributed storage management device for multi-core components according to claim 3, characterized in that, The second pipeline of the DVM remote transmission module includes three stations, D1 to D3. Station D1 is a link layer station. From station D1 to station D2, the DVM broadcast response message is parsed and matched with the transaction queue item in the transmission transaction queue (DVM Tracker1). From station D2 to station D3, a transaction queue item that has collected all core responses is selected from the transmission transaction queue (DVM Tracker1), and the corresponding DVM response message is concatenated. Station D3 is used to send the DVM response message.

6. The distributed storage management device for multi-core applications according to claim 1, characterized in that, The DVM remote receiving module includes two pipelines. The first pipeline is a cross-core request message pipeline, which is used to receive cross-core messages from the DVM remote sending module of other cores and send the request message to the DVM agent module of the core. The second pipeline is a DVM response pipeline, which is used to receive DVM response messages, cancel the transaction queue entry of the corresponding DVM broadcast message, and send cross-core DVM response messages.

7. The distributed storage management device for multi-core applications according to claim 6, characterized in that, The first pipeline of the DVM remote receiving module includes a receive transaction queue (DVM Tracker2) and a retransmission buffer. The receive transaction queue (DVM Tracker2) is used to receive DVM request messages from other cores across cores. The retransmission buffer is mainly used to handle flow control with the DVM agent module. When the DVM agent module sends a retransmission response message, the retransmission buffer updates the transaction queue entries in the receive transaction queue (DVM Tracker2) to the retransmission state and waits for the DVM agent module to send a credit grant message until it selects and sends the transaction queue entries in the receive transaction queue (DVM Tracker2) that are in the retransmission state.

8. A computing device comprising a multi-chip microprocessor and a memory interconnected, characterized in that, The multi-chip microprocessor includes the distributed storage management device for multi-chip microprocessors as described in any one of claims 1 to 7.

Images