Cache consistency maintenance method, multi-core system and electronic device

Abstract

The present application discloses a cache consistency maintenance method, a multi-core system and an electronic device, the method is applied to a multi-core system, the multi-core system includes multiple nodes; the method includes: requesting first data from a consistency node through a first request node; obtaining the first data through the consistency node to provide a copy of the first data to the first request node; recording the existence of a copy of the first data in the first request node through the consistency node. Therefore, the embodiments of the present application can solve the problem that the cache consistency method in the prior art requires a large storage space and has a large communication overhead.

Description

Technical Field

[0001] The present application belongs to the field of communication technology, and specifically relates to a cache consistency maintenance method, a multi-core system and an electronic device. Background Art

[0002] With the rapid development of multi-core processors and Network on Chip (NoC) technology, the number of processor cores in modern computer systems continues to increase, which makes cache consistency particularly important. Cache coherence means that caches between multiple processor cores must be consistent, ensuring that data modifications made by one core can be known to other cores in a timely manner, thereby avoiding inconsistent data seen by cores, resulting in data loss, calculation errors and other problems. In order to achieve cache consistency, the industry has proposed and widely adopted a variety of protocols and methods.

[0003] Among them, common cache consistency protocols include Modified Exclusive Shared Invalid (MESI) protocol, Modified Owned Exclusive Shared Invalid (MOESI) protocol, Modified Shared Invalid (MSI) MSI and Coherent Hub Interface (CHI) protocol. MESI protocol is one of the basic protocols for cache consistency maintenance. It ensures consistency by maintaining four states of each cache block. MOESI adds the owned state on the basis of MESI, which is used to indicate that the cache block has been modified but shared in multiple caches. MSI protocol is one of the simplest cache consistency protocols, which only defines three states of cache blocks, namely modified, shared, and invalid. CHI protocol provides a more efficient cache consistency maintenance mechanism. Especially in complex NoC systems, it uses a transaction model to manage cache consistency through a series of requests and responses.

[0004] In addition, the MESI protocol is suitable for small-scale, multi-core shared bus systems, maintaining cache consistency through simple state transitions and bus sniffing mechanisms; the CHI protocol is used in complex large-scale multi-core systems, providing high performance and good scalability through distributed messaging and transaction processing mechanisms, adapting to the needs of modern on-chip networks and complex system architectures.

[0005] Although CHI's cache consistency protocols and methods can effectively manage cache consistency in multi-core systems, these methods also face some challenges as the number of processor cores increases and the complexity of NoC systems increases, as described below:

[0006] (1) State complexity: In a multi-core system, the cache consistency protocol needs to track the state of each cache line to ensure that all processor cores see the latest consistent data when accessing data. Each state change requires corresponding hardware logic and storage resources to track and manage, which increases the complexity of the hardware and storage overhead. In particular, when the number of cores increases, the number of states that need to be tracked also increases accordingly, making the management of these states more complex. In addition, different state transition rules and conditions also increase the complexity of design and verification.

[0007] (2) Communication overhead: Cache consistency protocols require frequent communication between processor cores to ensure that all caches remain consistent. For example, snooping. Snooping is when all processor cores listen to memory access requests from other cores on the bus or NoC to maintain cache consistency. It can be seen that in large-scale systems, this communication overhead will increase significantly and may become a bottleneck for system performance. For example, when a processor core needs to access a cache line, it needs to send a probe request to all other cores and wait for a response, which will cause a lot of communication delays and bus / network congestion. In addition, communication overhead also includes the energy consumption of data transmission. When the system scale increases, the energy consumption problem becomes more significant.

[0008] From the above, we can see that in a NoC system with a large number of cores, the coherence node (Home Node, HN) needs to record the detailed status of the upper-level cache, which requires the snoop filter (SF) static random-access memory (SRAM) to have a large storage space; at the same time, in order to accurately obtain the status of the upper-level cache, it may be necessary to frequently access the SF SRAM, resulting in a large communication overhead, thus affecting the timing and performance of the overall system. Summary of the invention

[0009] The purpose of the embodiments of the present application is to provide a cache consistency maintenance method, a multi-core system and an electronic device, which can solve the problem that the cache consistency method in the prior art requires a large storage space and has a large communication overhead.

[0010] In a first aspect, an embodiment of the present application provides a cache consistency maintenance method, the method being applied to a multi-core system, the multi-core system comprising a plurality of nodes; the method comprising:

[0011] Requesting first data from a consistency node through a first requesting node;

[0012] Obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node;

[0013] The consistency node records that a copy of the first data exists in the first requesting node.

[0014] In a second aspect, an embodiment of the present application provides a multi-core system, the multi-core system comprising a first requesting node and a consistency node;

[0015] The first requesting node is used to: request first data from the consistency node;

[0016] The consistency node is used to:

[0017] obtaining the first data to provide a copy of the first data to the first requesting node;

[0018] Record that a copy of the first data exists in the first requesting node.

[0019] In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.

[0020] In a fourth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored, and when the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.

[0021] In a fifth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the first aspect.

[0022] In a sixth aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the first aspect.

[0023] In an embodiment of the present application, the first request node of the multi-core system can request the first data from the consistency node, thereby obtaining the first data through the consistency node to provide a copy of the first data to the first request node, and record the existence of the copy of the first data in the first request node through the consistency node. It can be seen that in an embodiment of the present application, it is possible to record in the consistency node whether the request node has a cached copy without recording the specific cache line status, thereby reducing the number of accesses to the consistency node, reducing storage overhead and hardware complexity; and, by recording in the consistency node whether there is a cached copy by the request node, when a request node needs to request data, it can send a request to the consistency node without having to send a probe request to other request nodes, thereby reducing communication delays, reducing network congestion, and reducing communication overhead. Therefore, the embodiment of the present application can solve the problem that the cache consistency method in the prior art requires a large storage space and has a large communication overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 It is a flow chart of a cache consistency maintenance method according to an embodiment of the present application;

[0025] Figure 2 It is one of the schematic diagrams of a specific implementation method of the cache consistency maintenance method of the embodiment of the present application;

[0026] Figure 3 This is a second schematic diagram of a specific implementation of the cache consistency maintenance method of an embodiment of the present application;

[0027] Figure 4 This is a third schematic diagram of a specific implementation of the cache consistency maintenance method of an embodiment of the present application;

[0028] Figure 5 is a structural block diagram of a multi-core system according to an embodiment of the present application;

[0029] Figure 6 It is a structural block diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.

[0031] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the terms used in this way are interchangeable where appropriate, so that the embodiments of the present application can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0032] The cache consistency maintenance method provided by the embodiment of the present application is described in detail below through specific embodiments and application scenarios in conjunction with the accompanying drawings.

[0033] The embodiment of the present application provides a cache consistency maintenance method, which can be applied to a multi-core system, the multi-core system includes a plurality of nodes; it can be understood that the nodes can also be referred to as processor cores or components;

[0034] The multi-core system adopts the CHI protocol, including at least one request node (Request Node, RN), a consistency node (Home Node, HN), and a slave node (Slave Node, SN); the consistency node can also be called a management node.

[0035] HN is a key component in the CHI protocol, responsible for managing and maintaining cache consistency;

[0036] In the CHI protocol, RN is the node that initiates the request, usually a processor core, a direct memory access (DMA) engine, or other device that can initiate a memory access request.

[0037] SF is a storage device that records the status of the upper cache line;

[0038] Slave nodes refer to memory, therefore, slave nodes can also be called memory.

[0039] See also Figure 1 , the cache consistency maintenance method may include the following steps 101 to 103:

[0040] Step 101: Request first data from a consistency node through a first request node.

[0041] The first requesting node requests the first data from the consistency node, which can be used to perform a read operation or a write operation, etc. Exemplarily, when used to perform a read operation, the first requesting node can send a read request (ReadNotSharedDirty) to the consistency node.

[0042] Step 102: Obtain the first data through the consistency node to provide a copy of the first data to the first requesting node.

[0043] It should be noted that, in step 102, after the consistency node receives the request for the first data sent by the first requesting node, it triggers the consistency node to search for the first data to obtain the first data. It is understandable that if the consistency node finds a copy of the first data in its own cache (e.g., the last level cache (LLC)), the consistency node can provide the copy of the first data to the first requesting node; if the consistency node finds that other nodes have a copy of the first data, the other nodes can provide the copy of the first data to the first requesting node.

[0044] Step 103: Record, through the consistency node, that a copy of the first data exists in the first requesting node.

[0045] After the first requesting node obtains the first data, a copy of the first data exists in the cache of the first requesting node, that is, the first requesting node has a cache line of the first data, and the consistency node records the copy of the first data in the first requesting node.

[0046] It should be noted that in the embodiment of the present application, in the consistency node, only whether each requesting node has a cache copy is recorded, and the specific cache line status is not recorded.

[0047] It can be known from the above steps 101 to 103 that in the embodiment of the present application, the first request node of the multi-core system can request the first data from the consistency node, thereby obtaining the first data through the consistency node to provide a copy of the first data to the first request node, and record the existence of the copy of the first data in the first request node through the consistency node. It can be seen that in the embodiment of the present application, it is possible to record in the consistency node whether the request node has a cached copy without recording the specific cache line status, thereby reducing the number of accesses to the consistency node, reducing storage overhead and hardware complexity; and, by recording in the consistency node whether there is a cached copy by the request node, when a request node needs to request data, it can send a request to the consistency node without sending a probe request to other request nodes, thereby reducing communication delays, reducing network congestion, and reducing communication overhead. Therefore, the embodiment of the present application can solve the problem that the cache consistency method in the prior art requires a large storage space and has a large communication overhead.

[0048] Optionally, in step 102, obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node includes the following steps A-1 to A-4:

[0049] Step A-1: ​​querying, through the consistency node, whether there is a copy of the first data in the cache of the consistency node;

[0050] Step A-2: when there is no copy of the first data in the cache of the consistency node, the consistency node queries whether there is a record of a copy of the first data in other requesting nodes, and the other requesting nodes include requesting nodes other than the first requesting node;

[0051] Step A-3: when the consistency node does not record that a copy of the first data exists in the other requesting node, requesting a copy of the first data from a slave node through the consistency node;

[0052] Step A-4: Providing a copy of the first data to the first requesting node through the slave node.

[0053] It should be noted that in an embodiment of the present application, a data copy can be stored in the cache of a consistency node, so that when a requesting node requests the data, the consistency node can quickly provide it to the requesting node, thereby reducing latency.

[0054] Therefore, when the consistency node receives a request for the first data sent by the first requesting node, it can first search in the local cache whether there is a copy of the first data. If so, it can be directly provided to the first requesting node.

[0055] In an embodiment of the present application, in the consistency node, it is recorded whether each requesting node has a cached copy; therefore, if there is no copy of the first data in the cache of the consistency node, the consistency node can search whether it has a record of the existence of copies of the first data in other requesting nodes; if such a record exists, the consistency node can request a copy of the first data from the requesting node corresponding to the record; and if such a record does not exist, the consistency node can request a copy of the first data from the slave node.

[0056] It can be seen that in the embodiment of the present application, the consistency node can quickly obtain the first data requested by the first requesting node based on whether there is a cache copy of each requesting node recorded by it, thereby reducing communication overhead and improving processing speed.

[0057] In addition, in step A-4, the slave node may directly send a copy of the first data to the first requesting node, or may send a copy of the first data to a consistency node, which then forwards the copy to the first requesting node.

[0058] Optionally, in the above step 102, the step of obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node further includes the following steps A-5 to A-6:

[0059] Step A-5: when the consistency node records that a copy of the first data exists in the second requesting node, requesting the copy of the first data from the second requesting node through the consistency node;

[0060] Step A-6: Send a copy of the first data to the first requesting node through the second requesting node.

[0061] It can be seen from steps A-5 to A-6 that in an embodiment of the present application, in the consistency node, there is a record of whether each requesting node has a cached copy; therefore, if there is no copy of the first data in the cache of the consistency node, the consistency node can search whether it has a record of the existence of copies of the first data in other requesting nodes; if such a record exists, the consistency node can request a copy of the first data from the requesting node corresponding to the record, thereby reducing communication overhead and improving processing speed.

[0062] Optionally, in the case where a copy of the first data exists in the second requesting node, the method further includes the following step B-1:

[0063] Step B-1: Send a copy of the first data to the consistency node through the second request node.

[0064] From this, it can be seen that if the consistency node records that a copy of the first data exists in the second request node, the consistency node can instruct the second request node to transmit the copy of the first data to the first request node and return a copy to the consistency node.

[0065] It should be noted that when a consistency node requests the first data from a slave node, the slave node only needs to provide a copy of the first data to the first requesting node, and there is no need to store a copy of the first data in the cache of the consistency node. The reason for this is that when a consistency node requests the first data from a slave node, only the first requesting node requests the first data, and other requesting nodes do not need it for the time being. Therefore, at this time, a copy of the first data may not be stored in the cache of the consistency node to save space.

[0066] When the consistency node requests the first data from the second request node, the second request node needs to return a copy of the first data to the consistency node. The reason for this is that when the consistency node requests the first data from the second request node, the first request node needs the first data, and before that, the second request node also needs the first data (because there is a copy of the first data in the second request node, so the second request node needs the first data), that is, there are currently two request nodes that need the first data. Therefore, in order for other request nodes to need the first data quickly in the future, the consistency node needs to store a copy of the first data in the cache.

[0067] Optionally, the method further comprises the following step C-1 or C-2:

[0068] Step C-1: downgrading the state of the copy of the first data in the second requesting node through the second requesting node;

[0069] In the embodiment of the present application, the requesting node can use the MESI protocol to ensure cache consistency, that is, the cache status has four states: Modified, Exclusive, Shared, and Invalid.

[0070] It can be seen from step C-1 that after the second requesting node provides a copy of the first data to the first requesting node, the status of the copy of the first data can be downgraded, for example, from UC (Exclusive) to SC (Shared), but the copy of the first data will be retained on the second requesting node.

[0071] Step C-2: invalidate the copy of the first data in the second requesting node through the second requesting node.

[0072] It can be seen from step C-2 that after the second requesting node provides a copy of the first data to the first requesting node, the copy of the first data can be invalidated, so that the copy of the first data will not be retained on the second requesting node.

[0073] It should be noted that if the second request node provides a copy of the first data to the first request node, and the second request node executes step C-2, then the copy of the first data will not be retained on the second request node, but the consistency node records that the second request node has a copy of the first data, which makes the record of the consistency node inaccurate. Therefore, the record of the consistency node can be updated. The following introduces two feasible update methods.

[0074] Update method 1:

[0075] Optionally, the method further comprises:

[0076] Step E-1: Sending first indication information to the consistency node through the second requesting node;

[0077] Step E-2: when the first indication information indicates that the copy of the first data in the second requesting node is invalid, updating the first record to the second record according to the first indication information by the consistency node;

[0078] The first record is that a copy of the first data exists in the second requesting node, and the second record is that a copy of the first data does not exist in the second requesting node.

[0079] It can be seen from steps E-1 to E-2 that if the copy of the first data of the second request node is to be invalidated, the second request node can send the above-mentioned first indication information to the consistency node to inform it that the copy of the first data is invalid. The consistency node can then promptly update the original first record to the second record so that the record of the consistency node is consistent with the actual status of the cached copy in the request node.

[0080] It is understandable that, in the embodiments of the present application, the order of the two processes of "the second requesting node invalidating the copy of the first data" and "sending the first indication information to the consistency node" is not limited.

[0081] Update method 2:

[0082] Optionally, the method further comprises the following steps F-1 to F-2:

[0083] Step F-1: when the third requesting node sends a target request to the consistency node, the consistency node updates the first record to a second record, wherein the target request is used to indicate the authority to obtain the first data, the first record is a copy of the first data existing in the second requesting node, and the second record is a copy of the first data not existing in the second requesting node;

[0084] Step F-2: Send second indication information to the second requesting node through the consistency node, wherein the second indication information is used to indicate that the copy of the first data is to be invalidated.

[0085] From steps F-1 to F-2, it can be seen that if the copy of the first data of the second request node is invalidated, then the second request node may not update the first record to the second record first, but, when receiving a target request for the first data from other request nodes (such as the third request node mentioned above), update the first record to the second record. Wherein, the target request is used to obtain the authority of the first data, then except for the copy of the first data of the initiator of the target request, the copies of the data in other request nodes must be invalidated. Therefore, after receiving this target request, the consistency node needs to notify other request nodes to invalidate the copies of the first data and update the local record, so that communication overhead can be saved.

[0086] In addition, compared with the existing technology, the cache line status of the requesting node tracked by the consistency node may change, making the status information unreliable. The specific reasons include the following:

[0087] First point: Changes in state during transaction initiation:

[0088] When a requesting node initiates a transaction (such as a read request), the transaction has not yet been completed and may be affected by a snoop message sent by a consistency node. For example, when a requesting node initiates a read request and has not yet received data, if a consistency node sends a snoop request, the requesting node may modify its cache line status based on the content of the snoop request.

[0089] Second point: Silent Change causes inaccurate status:

[0090] Silent Change means that the cache line state of the requesting node changes without explicitly notifying the consistency node. This situation will cause the cache state information of the requesting node tracked by the consistency node to be inaccurate.

[0091] The third point: Snoopee's state changes when responding to SNP messages:

[0092] In the cache coherence protocol, Snoopee refers to all requesting nodes that do not initiate requests during the snoop process. When a coherence node sends a snoop message, Snoopee needs to respond to the message. During the response process, the state of Snoopee's cache line may change. In order to respond to the snoop request, Snoopee may choose to evict some cache lines to free up space or meet coherence requirements. This eviction operation changes the state of the cache line.

[0093] In an embodiment of the present application, if the cache line status of the requesting node changes in the cases of the first to third points mentioned above, the above two update methods can be used to timely update whether there are cache copies in each requesting node recorded in the consistency node, so that the records of the consistency node are consistent with the actual status of the cache copies in the requesting node.

[0094] In summary, the specific implementation of the cache consistency maintenance method of the embodiment of the present application can be described as follows:

[0095] It should be noted that there are 4 RNs (ie, RN0, RN1, RN2, RN3) and 1 HN in the system in the following implementation manner.

[0096] Among them, in the following implementation, RN uses MESI protocol to ensure cache consistency. That is, the cache status needs to be modified (Modified), dedicated (Exclusive), shared (Shared), invalid (Invalid);

[0097] The cache states of LLC in HN are invalid (Invalid, I), clean (Clean, C) (ie, unmodified), and dirty (Dirty, D) (ie, modified). This simplification helps to reduce the complexity of cache state management and improve system performance.

[0098] The snoop filter (SF) in the HN records whether there is a cache on the RN, without recording the specific cache line status, for example, by recording the presence or absence of the cache on the RN through 1-bit data (exemplarily, when the bit value is I (i.e. Invalid), it indicates that it does not exist, and when it is V (i.e. Valid), it indicates that it exists; or when the bit value is 0, it indicates that it does not exist, and when it is 1, it indicates that it exists). This method reduces the storage requirements of the SF static random-access memory (SRAM) and reduces the hardware complexity.

[0099] SF is a storage device that records the status of the upper cache line;

[0100] In addition, when the system is just powered on, the cache status of RN0, RN1, RN2 and RN3 are all I (Invalid), and the RNs status of the SF record in the HN are also all I.

[0101] In addition, RN can also be called RN-Fully (F), and HN can also be called HN-F.

[0102] Implementation method 1: Figure 2 As shown, it includes the following steps 1 to 10:

[0103] Step 1: RN2 sends a read request (ReadNotSharedDirty) to HN to obtain the first data;

[0104] Step 2: HN queries LLC for a cache line without the first data, and SF does not record a cache copy of the first data in other RNs; that is, at this time, the state of the cache line of the first data in LLC is: invalid (Invalid, I);

[0105] Step 3: HN records that RN2 has a cache copy of the first data;

[0106] Among them, because in step 1, RN2 requests the first data from HN, RN2 will subsequently obtain the first data, and thereafter, the first data will exist in RN2. Therefore, in step 3, HN can record the cache copy of the first data in RN2;

[0107] in addition, Figure 2 "SF: IIII" in the figure indicates that SF records that: there is no cache copy of the first data in RN0 to RN3; for example, SF: IIVI indicates that SF records that: there is no cache copy of the first data in RN0, RN1, and RN3, and there is a cache copy of the first data in RN2;

[0108] Step 4: HN sends a read request (ReadNoSnP) for a non-sniffable address area to SN to request first data from SN; wherein SN generally refers to a memory;

[0109] It is understandable that if the SN currently has no resources to process the request when it receives the ReadNotSnP in step 4, then the SN may perform subsequent steps 5 and 6:

[0110] Step 5: SN sends a retry confirmation (RetryAck) to HN;

[0111] Step 6: SN sends a grant indication (PCrdGrant) to HN to inform HN that it can request data;

[0112] Step 7: After receiving PCrdGrant, HN resends ReadNoSnP to SN;

[0113] Step 8: SN sends dedicated transaction data (CompData_UC) to RN2, that is, SN sends a copy of the first data to RN2;

[0114] Step 9: RN2 sends a transaction response (CompAck) to HN to inform HN that it has received a copy of the first data;

[0115] Step 10: RN2 changes the cache line state of the first data from I to Exclusive (UC).

[0116] It should be noted that if the SN receives the ReadNotSnP in step 4 and there are resources to process the request, step 8 can be executed, and steps 5, 6 and 7 do not need to be executed.

[0117] Implementation method 2: Based on implementation method 1, further, as Figure 3 As shown, it includes the following steps 1 to 10:

[0118] Step 1: RN1 initiates a request to read the same cache line in implementation mode 1, that is, RN1 sends a ReadNotSharedDirty request to HN to read the first data;

[0119] Step 2: HN queries LLC for a cache line without the first data, and SF records that RN2 has a cache copy of the first data; that is, at this time, the state of the cache line of the first data in LLC is: invalid (Invalid, I);

[0120] Step 3: HN records that RN1 has a cache copy of the first data;

[0121] Among them, because in step 1, RN1 requests the first data from HN, RN1 will obtain the first data later, and thereafter, the first data will exist in RN1. Therefore, in step 3, HN can record the cache copy of the first data in RN1;

[0122] Step 4: HN sends a snoop reply forwarding message (SnpNotSharedDirtyFwd) to RN2 to request the first data from RN2;

[0123] Step 5: RN2 sends the shared transaction data (CompData_SC) to RN1, that is, RN2 directly forwards the first data to RN1;

[0124] It should be noted that after step 5, RN2 may perform steps 6 and 7, or steps 8 and 9:

[0125] Step 6: RN2 sends a snoop data response (SnpRespData_SC_Fwded_SC) to HN, indicating that its own cache state is SC and the forwarded cache state is SC, so as to inform HN that the cache of its first data is downgraded, that is, changed to SC;

[0126] Step 7: The cache line state of the first data of RN2 is changed from UC to SC;

[0127] Step 8: RN2 sends a snoop data response (SnpRespData_I_Fwded_SC) to HN, indicating that its own cache state is I and the forwarded cache state is SC, so as to inform HN that the cache of its first data is invalid;

[0128] Step 9: The cache line state of the first data of RN2 is changed from UC to I;

[0129] It can be seen that after RN2 provides a copy of the first data to RN1, there are two processing situations for the cache on RN2. One is that the cache state of RN2 itself will be downgraded, for example, from UC to SC, but the cache copy will be retained on RN2; the other is to directly invalidate the local cache. It should be noted that no matter which processing situation RN2 adopts, SF can directly record that both RN1 and RN2 have cache copies.

[0130] It should also be noted that after RN2 provides the first data to RN1, it also needs to return a copy of the first data to HN; for example, the copy of the first data can be carried in the message in the above step 6 or step 8, so that a copy of the first data exists in the LLC of HN, and the status of the LLC can be updated in step 12.

[0131] Among them, in the above-mentioned implementation mode one, HN does not retain a copy of the first data during the process of RN2 requesting the first data, while in implementation mode two, HN retains a copy of the first data during the process of RN1 requesting the first data. The reason is that: the copy is retained only when there are at least two RNs that need the first data, which can speed up the process. For example, if RN3 also requests the first data later, HN can directly provide a copy of the first data to RN3; and it avoids the situation where only one RN needs the first data, while other RNs do not need the first data, but copies are also retained in HN, resulting in a waste of space.

[0132] Step 10: RN1 changes the cache line state of the first data from I to SC;

[0133] Step 11: RN1 sends a transaction response (CompAck) to HN to inform HN that it has received a copy of the first data;

[0134] Step 12: HN changes the cache line state of LLC from I to C.

[0135] It should be noted that if the SN receives the ReadNotSnP in step 4 and there are resources to process the request, step 8 can be executed, and steps 5, 6 and 7 do not need to be executed.

[0136] Implementation method 3: Based on implementation method 2, further, as Figure 4 As shown, it includes the following steps 1 to 10:

[0137] Step 1: RN0 sends a permission (ReadUnique) request to HN, that is, RN1 obtains the permission of the first data from HN. In this case, except for the copy of the initiator, the copies of other RNs need to be invalidated;

[0138] Step 2: HN queries LLC for a cache line containing the first data, and then invalidates it. That is, at this time, the state of the cache line of the first data in LLC changes from C to I.

[0139] Step 3: HN records that RN0 has a cache copy of the first data, and updates RN1 and RN2 so that no cache copy of the first data exists;

[0140] Among them, because in step 1, RN0 requests the first data from HN, RN0 will subsequently obtain the first data, and thereafter, the first data will exist in RN0. Therefore, in step 3, HN can record the cache copy of the first data in RN0;

[0141] In addition, as described in step 1, the ReadUnique request indicates that, except for the initiator's copy, all copies of other RNs need to be invalidated; therefore, the copies of the first data in RN1 and RN2 need to be invalidated, and in step 3, the cache copies of the first data that do not exist in RN1 and RN2 can be updated;

[0142] Step 4: HN sends a SnpUnique message to RN2 to notify RN2 to invalidate the cache copy of the first data;

[0143] Step 5: HN sends SnpUnique to RN1, notifying RN1 to invalidate the cache copy of the first data;

[0144] Step 6: RN2 sends a snoop response (SnpResp_I) to HN, informing HN that it has invalidated the cache copy of the first data;

[0145] Step 7: RN2 invalidates the cache copy of the first data, and updates the state from SC to I;

[0146] It should be noted that if in implementation mode 2, RN2 executes steps 6 and 7 (that is, if RN2 does not invalidate the copy of the first data in implementation mode 2), then in implementation mode 3, step 7 exists; if in implementation mode 2, RN2 executes steps 8 and 9 (that is, if RN2 invalidates the copy of the first data in implementation mode 2), then in implementation mode 3, step 7 does not exist;

[0147] Step 8: RN1 sends a snoop data response (SnpRespData_I) to HN indicating that its own cache state is 1, transmits the data copy back to HN and notifies HN that it has invalidated its own cache copy of the first data;

[0148] Step 9: RN1 invalidates the cache copy of the first data, and updates the state from SC to I;

[0149] Step 10: HN sends dedicated transaction data (CompData_UC) to RN0;

[0150] Step 11: RN0 sends a transaction response (CompAck) to HN to inform HN that it has received a copy of the first data;

[0151] Step 12: The cache line state of the first data of RN0 is changed from I to UC.

[0152] It can be seen from Implementation Method 3 that after Implementation Method 2, if RN2 invalidates the cache copy of the first data, in the SF of HN, the cache copy of the first data in RN2 recorded therein may not be updated first, but may be updated in step 3 of Implementation Method 3 after receiving the ReadUnique request from other RNs.

[0153] The solution of implementation mode 3 optimizes the problem of inaccurate RN Cache status recorded in SF; inaccurate records may cause SNP messages to be sent to RNs that do not have Cache when obtaining data from Snoopee, especially when there are many cores, there will be a lot of messages on the Network, wasting bandwidth. Here, Snoopee refers to all RNs that are not the initiators of the request in the CHI protocol.

[0154] Alternatively, it is understandable that in the second implementation mode, after receiving SnpRespData_I_Fwded_SC sent by RN2, HN updates the record of the original cache copy of the first data in RN2 to the record of the cache copy of the first data not existing in RN2.

[0155] It should also be noted that the execution order of the steps in the above implementation is not limited to that described above.

[0156] To sum up, in the embodiment of the present application, the HN includes the LLC and ensures that the internal caches of multiple RNs are consistent with the LLC of the HN; the HN sets the SF, records the cache status of all RNs participating in the cache consistency, and sends a sniff message (Snoop Message) to the RN as needed, and completes the LLC state migration according to the confirmation message (ACK Message), updates the SF state, and passes the data to other nodes such as SN and RN through Message as needed.

[0157] It can be seen that the embodiments of the present application have the following advantages:

[0158] (1) By recording the cache presence or absence of RN in SF, there is no need to record the specific cache line status, thereby reducing hardware complexity and storage overhead;

[0159] (2) Reduce communication overhead: By directly recording the cache status of the RN, the number of communications between the HN and the RN is reduced, the communication overhead is reduced, and the overall performance of the system is improved;

[0160] (3) Improve system flexibility: The cache management strategy of NINE is adopted to improve the flexibility of the system, so that the system can better adapt and adjust under different workloads, thereby improving the performance and scalability of the system;

[0161] (4) Reduce hardware complexity: Reduce the number of HN accesses to memory and SF SRAM, simplify the logic of cache status management, reduce hardware complexity, and improve system maintainability and reliability.

[0162] In particular, it should be noted that the selection of cache management strategy also affects the performance of HN. The cache management strategy determines the storage and consistency maintenance method of data between caches at different levels. The method refers to whether LLC and upper-level caches are exclusive, non-exclusive, or non-inclusive and non-exclusive (NINE).

[0163] In the Inclusive cache strategy, the lower-level cache (such as the Last Level Cache (LLC) cache) includes all the data in the upper-level cache (such as the second-level (L2) cache). This means that if a data block exists in the L2 cache, it must also exist in the LLC cache. The advantage of this strategy is that it is simple to implement, but the disadvantage is data redundancy, which leads to data redundancy between cache levels and increases the total cache storage requirements. At the same time, the lower-level cache includes all the data in the upper-level cache, which may cause useful data to be frequently replaced.

[0164] In the Exclusive cache strategy, the data in the upper cache and the lower cache are not repeated. Each data block exists only in one cache level, that is, if a data block exists in the L2 cache, it will not exist in the LLC cache, and vice versa. Its advantage is that there is no data redundancy, and the data in different levels of cache will not be repeated, which optimizes storage utilization. The storage space in each cache level is used to store independent data blocks, which increases the cache capacity of the overall system. However, the disadvantages are also obvious. It requires a more complex mechanism to maintain cache consistency, especially when data blocks are moved out or replaced. At the same time, it may also increase access latency because data exists independently in caches of different levels.

[0165] In the embodiment of the present application, the cache between LLC and RN adopts the management strategy of NINE, which is described as follows:

[0166] The details are as follows:

[0167] (1) RN sends ReadNotSharedDirty. If the data is found in other RNs, HN will keep a copy of the data.

[0168] (2) When a cache line has copies in both RN and HN, the corresponding cache line in RN is evicted without affecting the corresponding cache line in LLC.

[0169] It can be seen that the NINE cache strategy adopted in the embodiment of the present application does not require data to exist uniquely between caches of different levels, nor does it require data to exist in the lower cache when the upper cache exists. This strategy adds great flexibility to the design of HN.

[0170] See also Figure 5 As shown, the embodiment of the present application provides a multi-core system, such as Figure 5 As shown, the multi-core system includes a first request node 501 and a consistency node 502;

[0171] The first requesting node 501 is used to: request the first data from the consistency node 502;

[0172] The consistency node 502 is used for:

[0173] Obtaining the first data to provide a copy of the first data to the first requesting node 501;

[0174] It is recorded that a copy of the first data exists in the first requesting node 501.

[0175] Optionally, the multi-core system further includes a slave node 503:

[0176] The consistency node 502 obtains the first data to provide a copy of the first data to the first requesting node 501, including:

[0177] Query whether there is a copy of the first data in the cache of the consistency node 502;

[0178] In the case that there is no copy of the first data in the cache of the consistency node 502, query whether there is a copy of the first data in other requesting nodes, where the other requesting nodes include requesting nodes other than the first requesting node;

[0179] In the case that the consistency node 502 does not record that a copy of the first data exists in the other requesting node, requesting a copy of the first data from the slave node 503;

[0180] The slave node 503 is used to provide a copy of the first data to the first requesting node 501 .

[0181] Optionally, the multi-core system further includes a second requesting node 504:

[0182] The consistency node 502 obtains the first data to provide a copy of the first data to the first requesting node 501, further comprising:

[0183] In a case where the consistency node 502 records that a copy of the first data exists in the second requesting node, requesting the second requesting node 504 for a copy of the first data;

[0184] The second requesting node is used to: send a copy of the first data to the first requesting node 501.

[0185] Optionally, when a copy of the first data exists in the second requesting node 504 , the second requesting node 504 is further used to: send the copy of the first data to the consistency node 502 .

[0186] Optionally, the second requesting node 504 is further configured to:

[0187] downgrading the state of the copy of the first data in the second requesting node;

[0188] or,

[0189] The copy of the first data in the second requesting node is invalidated.

[0190] Optionally, the second requesting node 504 is further used to: send first indication information to the consistency node;

[0191] The consistency node 502 is further configured to: update the first record to the second record according to the first indication information when the first indication information indicates that the copy of the first data in the second requesting node is in an invalid state;

[0192] The first record is that a copy of the first data exists in the second requesting node, and the second record is that a copy of the first data does not exist in the second requesting node.

[0193] Optionally, the multi-core system further includes a third requesting node 505;

[0194] The consistency node 502 is further used to: when the third requesting node 505 sends a target request to the consistency node 502, update the first record to a second record, wherein the target request is used to indicate the authority to obtain the first data, the first record is a copy of the first data that exists in the second requesting node, and the second record is a copy of the first data that does not exist in the second requesting node;

[0195] Second indication information is sent to the second requesting node 504, wherein the second indication information is used to indicate that the copy of the first data is to be invalidated.

[0196] The multi-core system provided in the embodiment of the present application can achieve Figures 1 to 4 To avoid repetition, the various processes implemented by the method embodiment are not described here.

[0197] Alternatively, if Figure 6 As shown, an embodiment of the present application also provides an electronic device 600, including a processor 601 and a memory 602, wherein the memory 602 stores programs or instructions that can be executed on the processor 601, and when the program or instructions are executed by the processor 601, the various steps of the above-mentioned cache consistency maintenance method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, they are not repeated here.

[0198] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned cache consistency maintenance method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0199] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.

[0200] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned cache consistency maintenance method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0201] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0202] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the cache consistency maintenance method embodiment as described above, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0203] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0204] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for an electronic device to execute the methods described in each embodiment of the present application.

[0205] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

Claims

1. A cache consistency maintenance method, characterized in that: The method is applied to a multi-core system, the multi-core system includes a plurality of nodes; the method includes: Requesting first data from a consistency node through a first requesting node; Obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node; Recording, by the consistency node, that a copy of the first data exists in the first requesting node; The obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node includes: querying, through the consistency node, whether there is a copy of the first data in the cache of the consistency node; In the case that there is no copy of the first data in the cache of the consistency node, the consistency node queries whether there is a record of a copy of the first data in other requesting nodes, and the other requesting nodes include requesting nodes other than the first requesting node; In a case where the consistency node does not record that a copy of the first data exists in the other requesting node, requesting a copy of the first data from a slave node through the consistency node; providing, by the slave node, a copy of the first data to the first requesting node; Among them, the cache between the consistency node's own cache and the request node adopts the NINE management strategy, and the NINE management strategy includes: the first request node sends a read request, if the data hits in other request nodes, the consistency node will retain a copy of the data; in the set cache line, if the request node and the consistency node have copies of the data at the same time, the corresponding cache line of the request node is evicted, which will not affect the corresponding cache line of the consistency node's own cache.

2. The method according to claim 1, characterized in that The obtaining the first data through the consistency node to provide a copy of the first data to the first requesting node also includes: In a case where the consistency node records that a copy of the first data exists in the second requesting node, requesting the copy of the first data from the second requesting node through the consistency node; A copy of the first data is sent to the first requesting node through the second requesting node.

3. The method according to claim 2, characterized in that In the case that a copy of the first data exists in the second requesting node, the method further includes: A copy of the first data is sent to the consistency node through the second requesting node.

4. The method according to claim 2, characterized in that: The method further comprises: downgrading, by the second requesting node, the state of the copy of the first data in the second requesting node; or, The copy of the first data in the second requesting node is invalidated by the second requesting node.

5. The method according to claim 4, characterized in that The method further comprises: Sending first indication information to the consistency node through the second requesting node; When the first indication information indicates that the copy of the first data in the second requesting node is in an invalid state, updating the first record to the second record according to the first indication information by the consistency node; The first record is that a copy of the first data exists in the second requesting node, and the second record is that a copy of the first data does not exist in the second requesting node.

6. The method according to claim 4, characterized in that The method further comprises: In the case where the third requesting node sends a target request to the consistency node, the first record is updated to a second record through the consistency node, wherein the target request is used to indicate the authority to obtain the first data, the first record is a copy of the first data that exists in the second requesting node, and the second record is a copy of the first data that does not exist in the second requesting node; Second indication information is sent to the second requesting node through the consistency node, wherein the second indication information is used to indicate that the copy of the first data is to be invalidated.

7. A multi-core system, characterized in that: The multi-core system includes a first request node and a consistency node; The first requesting node is used to: request first data from the consistency node; The consistency node is used to: obtaining the first data to provide a copy of the first data to the first requesting node; Recording that a copy of the first data exists in the first requesting node; The multi-core system further comprises a slave node: The consistency node obtains the first data to provide a copy of the first data to the first requesting node, including: Query whether there is a copy of the first data in the cache of the consistency node; In the case that there is no copy of the first data in the cache of the consistency node, query whether there is a record of a copy of the first data in other requesting nodes, and the other requesting nodes include requesting nodes other than the first requesting node; In a case where the consistency node does not record that a copy of the first data exists in the other requesting node, requesting a copy of the first data from a slave node; The slave node is used to: provide a copy of the first data to the first requesting node; Among them, the cache between the consistency node's own cache and the request node adopts the NINE management strategy, and the NINE management strategy includes: the first request node sends a read request, if the data hits in other request nodes, the consistency node will retain a copy of the data; in the set cache line, if the request node and the consistency node have copies of the data at the same time, the corresponding cache line of the request node is evicted, which will not affect the corresponding cache line of the consistency node's own cache.

8. An electronic device, characterized in that: It comprises a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the programs or instructions are executed by the processor, the steps of the cache consistency maintenance method as described in any one of claims 1 to 6 are implemented.

9. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the steps of the cache consistency maintenance method according to any one of claims 1 to 6 are implemented.

Images