Accelerated processing method, management node, storage medium, and computer program product

Abstract

The application provides a method for accelerating processing of a distributed virtual memory request, applied to a distributed virtual memory management node, and the method comprises the following steps: receiving and storing a distributed virtual memory request sent by a first request node; monitoring a processing time length of the distributed virtual memory request; and in response to the processing time length of the distributed virtual memory request exceeding a time length threshold, performing accelerated processing on the distributed virtual memory request. The application also provides a distributed virtual memory management node, a computer readable storage medium and a computer program product. According to the technical scheme of the application, the scheduling and broadcasting mechanism of the distributed virtual memory request can be optimized, the request accumulation can be effectively relieved, the risk of core blocking and request timeout can be reduced, and thus the overall performance of the system and the address consistency maintenance efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of virtual memory management technology, specifically to a method for accelerating the processing of distributed virtual memory requests, a distributed virtual memory management node, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, distributed virtual memory (DVM) requests are widely used in various virtual memory management scenarios in multi-core systems. In these scenarios, it is usually necessary to broadcast DVM requests to multiple relevant nodes in the system to ensure that each core maintains a consistent view of the virtual address space, thereby maintaining the correctness and consistency of the system.

[0003] To ensure system stability and resource controllability, existing mechanisms typically limit the maximum outstanding count of DVM broadcasts. When the number of sent but incomplete DVM broadcasts reaches this limit, the system must wait for at least one broadcast to complete before sending a new one. For synchronous DVM requests, to prevent request overlap and ensure sequential execution, the system usually requires a maximum outstanding count of 1. However, in a multi-core concurrent execution environment, multiple processor cores may simultaneously send requests to the DVM management node, causing requests to accumulate at the management node and preventing timely broadcast processing. This request backlog can block the requesting core or even trigger request timeouts, severely impacting system performance and responsiveness. Furthermore, related technologies lack effective monitoring and acceleration mechanisms for DVM request queuing status. Summary of the Invention

[0004] This application provides a method for accelerating the processing of DVM requests, a DVM management node, a computer-readable storage medium, and a computer program product, which at least solves the above-mentioned problems in the related art.

[0005] This application provides a method for accelerating the processing of DVM requests, applied to a DVM management node. The method includes: receiving and storing a DVM request sent by a first requesting node; monitoring the processing time of the DVM request; and accelerating the processing of the DVM request in response to the processing time of the DVM request exceeding a time threshold.

[0006] This application also provides a DVM management node, including a processor and a memory, wherein the memory stores a computer program; when the processor executes the computer program, it implements a method for accelerating the processing of DVM requests according to an embodiment of this application.

[0007] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement a method for accelerating the processing of DVM requests according to an embodiment of this application.

[0008] This application also provides a computer program product, which includes a computer program that, when executed by a processor, causes the processor to implement a method for accelerating the processing of DVM requests according to an embodiment of this application.

[0009] According to the technical solution of this application embodiment, by monitoring the processing time of DVM requests and accelerating the processing of DVM requests when the processing time of DVM requests exceeds the time threshold, the scheduling and broadcasting mechanism of DVM requests can be optimized, effectively alleviating request backlog, reducing the risk of kernel blocking and request timeout, thereby improving the overall system performance and address consistency maintenance efficiency. Attached Figure Description

[0010] The accompanying drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain the application and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art through the description of detailed exemplary embodiments with reference to the accompanying drawings, in which:

[0011] Figure 1 A schematic diagram of various protocol nodes interconnected in the consensus bus interface architecture is shown.

[0012] Figure 2 This application scenario illustrates a method for accelerating the processing of DVM requests according to an embodiment of this application;

[0013] Figure 3 A flowchart of a method for accelerating the processing of DVM requests according to an embodiment of this application is shown;

[0014] Figure 4 A flowchart is shown of a software acceleration scheme for accelerating the processing of DVM requests according to an embodiment of this application;

[0015] Figure 5 A detailed flowchart of the steps in a method for accelerating the processing of DVM requests according to an embodiment of this application is shown;

[0016] Figure 6 A flowchart is shown of a hardware acceleration scheme for a method of accelerating the processing of DVM requests according to an embodiment of this application;

[0017] Figure 7A flowchart is shown of a synchronization suppression mechanism for a method to accelerate the processing of DVM requests according to an embodiment of this application;

[0018] Figure 8 An application example of a synchronization suppression mechanism for accelerating the processing of DVM requests according to an embodiment of this application is shown;

[0019] Figure 9 A schematic diagram of transmitting SnpDVMOp broadcasts in related technologies is shown;

[0020] Figure 10 A schematic diagram of transmitting SnpDVMOp broadcasts according to an embodiment of this application is shown. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solution of this application, the method for accelerating the processing of DVM requests in this application will be described in detail below with reference to the accompanying drawings.

[0022] Exemplary embodiments will be described more fully below with reference to the accompanying drawings; however, these exemplary embodiments may be embodied in different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will enable those skilled in the art to fully understand the scope of this application.

[0023] Where there is no conflict, the various embodiments of this application and the features thereof may be combined with each other.

[0024] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0025] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms “a” and “the” are also intended to include the plural forms unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated features, integrals, steps, operations, elements, and / or components is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded.

[0026] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0027] DVM requests are widely used in various virtual memory management scenarios in multi-core systems, including critical operations such as context switching, virtual machine switching, page table updates, virtual address translation requests, translation lookaside buffer (TLB) invalidation (shootdown), unified memory address consistency between the graphics processing unit (GPU) and the central processing unit (CPU), page migration, and virtual address cache consistency management.

[0028] To ensure system stability and resource controllability, existing mechanisms typically limit the maximum number of incomplete DVM broadcasts. When the number of sent but not yet completed DVM broadcasts reaches this limit, the system must wait for at least one broadcast to complete before sending a new DVM broadcast. For Sync type DVM requests, to prevent request overlap and ensure their sequential execution, the system usually requires a maximum incomplete count of 1. However, in a multi-core concurrent execution environment, multiple processor cores may simultaneously send requests to the DVM management node, causing requests to accumulate at the management node and preventing timely broadcast processing. This request backlog can block the requesting core or even trigger request timeouts, severely impacting system performance and responsiveness. Furthermore, related technologies lack effective monitoring and acceleration mechanisms for DVM request queuing status.

[0029] To facilitate understanding of the scheme in this application, the Coherent Hub Interface (CHI) architecture will be briefly introduced below.

[0030] Figure 1 This diagram illustrates the various protocol nodes interconnected in the CHI architecture.

[0031] See Figure 1 A complete CHI network consists of three main parts: Request Node (RN), Interconnect (ICN), and Subordinate Node (SN).

[0032] RN generates protocol transactions to ICN, which include read and write operations. A transaction performs a single operation; typically, a transaction either reads from memory or writes to memory.

[0033] ICN is the CHI transport mechanism used for communication between protocol nodes. An ICN can include switch structures connected in ring, mesh, cross, or other topologies. An ICN can include protocol nodes, such as home nodes (HN) and miscellaneous nodes (MN).

[0034] HN is a node located in ICN that receives protocol transactions from RN, performs the required consistency actions, and returns a response.

[0035] MN is a node located in ICN that receives DVM messages from RN, performs the required operations, and returns a response.

[0036] SN is the node that receives requests from HN, performs the required actions, and returns a response.

[0037] RN can be further classified into: Fully Coherent Request Node (RN-F), IO Coherent Request Node with DVM support (RN-D), and IO Coherent Request Node (RN-I).

[0038] RN-F includes a hardware-coherent cache, allowing the generation of all transactions defined by the protocol and supporting all snoop transactions. RN-D does not include a hardware-coherent cache, can accept DVM transactions, and can generate a subset of transactions defined by the protocol. RN-I does not include a hardware-coherent cache, does not accept DVM transactions, can generate a subset of transactions defined by the protocol, and does not require snoop functionality.

[0039] HN can be further classified into: Fully coherent Home Node (HN-F) and Non-coherent Home Node (HN-I).

[0040] HN-F is expected to receive all operation requests except for DVM operations (DVMOp), including points of coherence (PoCs) that manage consistency by snooping the required RN-F, merging snoop responses of transactions, and sending a single response to the requesting node. HN-F is expected to be a point of serialization (PoS) that manages the order of multiple memory requests. HN-F may include directory or snoop filtering to reduce redundant snooping.

[0041] HN-I processes a finite subset of request types defined by the protocol, excluding PoC and unable to handle snoopable requests. Upon receiving a snoopable request, HN-I must respond with a message conforming to the protocol requirements. HN-I is expected to be a PoS that manages the ordering of IO requests for the IO subsystem.

[0042] SN can be further classified into: SN-F and SN-I.

[0043] SN-F is a slave node type for general memory that can handle unseen read, write, and atomic requests, including variations of these requests, as well as Cache Maintenance Operation (CMO) requests.

[0044] SN-I is a slave node type used for peripheral devices or general memory that can handle unspyable read, write, and atomic requests, including variations of these requests, as well as CMO.

[0045] The relevant technologies have defined a DVM management node (DN), which is responsible for propagating local DVM transactions to remote chips and handling DVM operations between the local chip and the remote chip.

[0046] Figure 2 An application scenario of a method for accelerating the processing of DVM requests according to an embodiment of this application is illustrated.

[0047] like Figure 2 As shown, multiple RN-Fs send DVM requests to the DN, and the DN needs to process multiple DVM requests, which may lead to request timeouts. Therefore, an acceleration processing mechanism according to an embodiment of this application is set up within the DN.

[0048] To accelerate the processing of DVM requests, embodiments of this application propose a method for accelerating the processing of DVM requests, so as to effectively improve the efficiency of DVM request processing, reduce system latency, and enhance the throughput of multi-core systems.

[0049] Figure 3 A flowchart of a method for accelerating the processing of DVM requests according to an embodiment of this application is shown.

[0050] like Figure 3 As shown, the method for accelerating the processing of DVM requests according to an embodiment of this application includes the following steps S110 to S130.

[0051] In step S110, the DVM request sent by the first RN is received and stored.

[0052] In step S120, the processing time of the DVM request is monitored.

[0053] In step S130, in response to the processing time of the DVM request exceeding the time threshold, the DVM request is accelerated.

[0054] According to an embodiment of this application, a duration threshold can be determined based on the maximum waiting time for transaction processing and the average transaction processing time of the first RN.

[0055] To accelerate the processing of DVM requests, this application proposes two acceleration schemes: a software acceleration scheme and a hardware acceleration scheme.

[0056] Figure 4 A flowchart illustrating a software acceleration scheme for accelerating the processing of DVM requests according to an embodiment of this application is shown.

[0057] According to embodiments of this application, such as Figure 4 As shown, in response to the processing time of a DVM request exceeding a time threshold, the DVM request is accelerated (i.e., step S130) including the following steps S1301 to S1305.

[0058] In step S1301, in response to the processing time of the DVM request exceeding the time threshold, an interrupt is reported to the system software, and the identifier of the DVM request is stored in the first register of DN.

[0059] According to an embodiment of this application, after receiving a DVM request, the information of the received DVM request can be stored as a record entry in the memory inside the DN, and a unique identifier (entryid) can be assigned to the received DVM request to track the status of the DVM request throughout the entire processing flow. The entryid of the DVM request can be used to index and identify the entry that stores the DVM request.

[0060] According to embodiments of this application, a tracker can count the entries storing DVM requests to determine whether the count value exceeds a duration threshold. The tracker tracks and manages the entire lifecycle of a DVM request, including request initiation, broadcasting, response collection, and final completion. Each tracker corresponds to one DVM request. If the processing time of the DVM request corresponding to a tracker exceeds the duration threshold, an interrupt is reported, and the entryid of the timed-out entry is stored in the first register of the DN. In response to the interrupt, the system software can read the entryid of the timed-out entry from the first register of the DN.

[0061] In step S1302, in response to an interrupt, the system software reads the DVM request information based on the identifier of the DVM request in the first register.

[0062] According to embodiments of this application, the system software can configure the entryid of the timed-out entry and enable entry fetching to store the information of the timed-out entry (i.e., the information of the stored DVM request) in the register of the DN. Subsequently, the system software can obtain information about DVM requests whose processing time exceeds the time threshold by reading the register.

[0063] In step S1303, the system software determines whether to accelerate the processing of the DVM request based on the information of the DVM request.

[0064] The system software can determine whether to accelerate DVM requests that have timed out (i.e., whose processing time exceeds a time threshold) based on various algorithms and / or multiple determination methods, and this application does not limit this. By providing interrupts to the system software, the system software can respond to interrupts to determine whether to accelerate DVM requests, thereby improving the system's flexibility.

[0065] In step S1304, in response to the system software determining to accelerate the processing of the DVM request, the system software stores the identifier of the DVM request in the second register of DN and sets acceleration enable.

[0066] According to an embodiment of this application, if there are multiple timeout entries that need to be accelerated, the entryid of the multiple entries that need to be accelerated can be set in the second register.

[0067] In step S1305, in response to acceleration enable, the DVM request is accelerated.

[0068] By setting registers and enabling acceleration, the system software notifies the DN of the entry ID of the DVM request that needs to be accelerated. The DN responds to the acceleration enable signal by accelerating the DVM request corresponding to the entry ID that needs acceleration.

[0069] According to embodiments of this application, accelerating DVM requests includes increasing the priority of DVM requests. When accelerating timed-out entries, their priority can be set to the highest priority, and other DVM requests can be paused. Once the accelerated processing of timed-out entries is complete, non-timed-out entries can then be processed.

[0070] When a DVM request is not processed within a specified time, a timeout interrupt is reported. Upon receiving the interrupt, the system software reads the detailed information of the timed-out DVM request and determines whether accelerated processing is needed. If acceleration is required, the system software can trigger the acceleration process by configuring relevant registers. The software acceleration scheme for accelerating DVM request processing according to the embodiments of this application is highly flexible, reusable, supports dynamic adjustment, and is easy to debug and optimize.

[0071] According to embodiments of this application, such as Figure 5 As shown, in response to acceleration enable, the accelerated processing of DVM requests (i.e., step S1305) includes the following steps S13051 to S13055.

[0072] In step S13051, the identifier of the DVM request to be accelerated is read from the second register.

[0073] In step S13052, it is determined whether the mode of the DVM request corresponding to the read identifier is a synchronization request.

[0074] In step S13053, in response to the DVM request being a synchronous request, it is determined whether there are any unprocessed asynchronous requests from the same RN.

[0075] In step S13054, in response to the existence of an unprocessed asynchronous request from the same RN, the read identifier is stored in the third register of the DN, and after the asynchronous request from the same RN is completed, the DVM request is accelerated.

[0076] In step S13055, in response to the absence of any unprocessed asynchronous requests from the same RN, the DVM request corresponding to the read identifier is accelerated.

[0077] According to an embodiment of this application, when there are unprocessed non-synchronous (NonSync) requests from the same RN, the entry that stores a DVM request with a synchronous (Sync) mode can be identified as a hazard entry. In order to maintain the order of memory access, the non-synchronous requests need to be completed first, and then the synchronous requests that need to be accelerated are accelerated.

[0078] Figure 6 A flowchart illustrating a hardware acceleration scheme for a method of accelerating the processing of DVM requests according to an embodiment of this application is shown.

[0079] According to embodiments of this application, such as Figure 6 As shown, in response to the processing time of a DVM request exceeding a time threshold, the DVM request is accelerated (i.e., step S130) including the following steps S1311 to S1314.

[0080] In step S1311, in response to the processing time of the DVM request exceeding the time threshold, it is determined whether the mode of the DVM request is a synchronous request.

[0081] In step S1312, in response to the DVM request being a synchronous request, it is determined whether there are any unprocessed asynchronous requests from the same RN.

[0082] In step S1313, in response to the existence of an unprocessed asynchronous request from the same RN, the identifier of the DVM request is stored in the fourth register of the DN, and after the asynchronous request from the same RN is processed, the DVM request is accelerated.

[0083] In step S1314, in response to the absence of any unprocessed asynchronous requests from the same RN, the DVM request is accelerated.

[0084] According to the hardware acceleration scheme of this application embodiment, after configuring a duration threshold, the processing time of each DVM request is monitored. When it is determined that the processing time of a DVM request exceeds the duration threshold, the DVM request can be directly accelerated without the intervention of system software. The hardware acceleration scheme for accelerating DVM request processing according to the method of this application embodiment has high performance, low latency, and is suitable for high-concurrency scenarios. In addition, during acceleration processing, it is also necessary to determine whether the timeout entry is a contention entry. If it is a contention entry, asynchronous requests from the same RN need to be processed first, and then the synchronous requests that need to be accelerated are accelerated.

[0085] The method for accelerating the processing of DVM requests according to embodiments of this application further includes: broadcasting the DVM request to a remote node.

[0086] To optimize the broadcasting behavior of synchronization requests when broadcasting DVM requests to remote nodes, embodiments of this application propose a synchronization suppression mechanism.

[0087] Figure 7 A flowchart of a synchronization suppression mechanism for a method to accelerate the processing of DVM requests according to an embodiment of this application is shown.

[0088] According to embodiments of this application, such as Figure 7 As shown, broadcasting a DVM request to a remote node includes the following steps S1401 to S1404.

[0089] In step S1401, it is determined whether the mode of the DVM request is a synchronous request.

[0090] In step S1402, in response to the DVM request being a synchronization request, it is determined whether the type of the last broadcast to the remote node was synchronization.

[0091] In step S1403, in response to the previous broadcast to the remote node being of type synchronous, the DVM request is not broadcast to the remote node.

[0092] In step S1404, in response to the fact that the type of the last broadcast to the remote node was not synchronous, the DVM request is broadcast to the remote node.

[0093] According to embodiments of this application, a DVM request is a DVM Operation (DVMOP) request. DVMOP requests include both non-synchronous and synchronous types.

[0094] like Figure 8 As shown, in the DN node of chip 0, when the synchronization suppression mechanism is in effect, the DN will not repeatedly initiate synchronization broadcast operations to the c2c module, thereby avoiding DVM broadcast transmission in paths 3, 4, and 5 and speeding up the transaction processing speed of the original request.

[0095] According to an embodiment of this application, before each synchronization broadcast is sent, it is determined whether the type of the previous broadcast was a synchronization type and whether it has already been broadcast to a remote node. If both conditions are met, the synchronization request is no longer broadcast to the remote node, thereby effectively reducing the number of broadcasts and optimizing the synchronization request broadcast.

[0096] This application also proposes a TLPDVM transmission mechanism that sends DVM broadcasts in Transaction Layer Packet (TLP) format to accelerate the processing of DVM broadcasts.

[0097] The method for accelerating the processing of DVM requests according to embodiments of this application further includes: broadcasting the DVM request to other RNs besides the first RN via a single snoop-based DVM operation (Snoop-based DVMOp, SnpDVMOp) transmission.

[0098] Figure 9 A schematic diagram of transmitting SnpDVMOp broadcasts in related technologies is shown. Figure 10 A schematic diagram of transmitting SnpDVMOp broadcasts according to an embodiment of this application is shown.

[0099] See Figure 9 In the traditional CHI protocol, the DVM management node needs to send SnpDVMOp broadcasts to the RN-F and RN-D nodes. These broadcasts are sent in two parts: SNPDVMOP_P1 and SNPDVMOP_P2. Figure 10 The TLPDPVM transport mechanism proposed according to an embodiment of this application is illustrated, such as... Figure 10 As shown, the valid information of the two parts SNPDVMOP_P1 and SNPDVMOP_P2 is merged into a TLP format data packet SNPDVMOP, and the function that originally required two broadcasts is completed in a single SnpDVMOp transmission, thus accelerating the DVM broadcast.

[0100] The method for accelerating the processing of DVM requests according to embodiments of this application optimizes the broadcast of synchronization requests through a synchronization suppression mechanism and accelerates the processing of DVM broadcasts through a TLPDVM transmission mechanism.

[0101] Based on the optimization of synchronization requests, for DVM requests of the synchronization type with a maximum number of incomplete requests of 1, if the current remote node has already initiated a synchronization broadcast, the same synchronization request will not be broadcast again. By reducing the number of broadcasts, the synchronization processing speed is improved, system latency and network bandwidth usage are reduced, and the overall throughput is increased.

[0102] Based on the TLPDVM transmission mechanism, the effective information from the two parts is merged into one packet for transmission, reducing the number of transmissions, improving broadcast efficiency, reducing network latency, accelerating DVM broadcasting, alleviating the pressure on routing nodes, and improving the overall system performance.

[0103] The method for accelerating DVM request processing in this application embodiment effectively solves the problems of request backlog, core blocking, timeout and deadlock caused by broadcast restrictions in multi-core systems by introducing a dual acceleration mechanism of software and hardware, and significantly improves the system's response speed, throughput and address consistency maintenance efficiency.

[0104] The method for accelerating DVM request processing in this application is applicable to multi-core concurrent execution environments. In such environments, multiple processor cores may simultaneously send requests to the DVM management node, causing requests to accumulate at the management node and preventing timely broadcast processing, thus leading to problems such as core blocking, timeouts, and deadlocks. By introducing software and hardware acceleration schemes, the method monitors the currently queued DVM requests and triggers accelerated processing when a request times out, effectively preventing system deadlocks, improving system processing efficiency, reducing the number of broadcasts, lowering communication latency and routing node pressure, and further enhancing the overall system performance and stability.

[0105] According to the software acceleration solution, by monitoring the DVM requests currently in the queue, timely acceleration processing can be implemented after a request times out, effectively preventing node blocking caused by address consistency maintenance delays. By increasing the priority of DVM requests and optimizing the queue scheduling strategy, broadcast latency is significantly reduced, response speed is accelerated, and the queuing time for DVM requests is reduced, thereby improving the overall concurrent processing capacity of the system.

[0106] According to the hardware acceleration scheme, timeout entries can be prioritized, and accelerated processing of timeout transactions can resolve kernel deadlock issues caused by timeouts. Furthermore, the synchronization suppression mechanism can reduce the number of synchronization broadcast triggers, effectively reducing system latency and bandwidth consumption of the consistency network. In the TLPDVM transmission mechanism, the two parts of SnpDVMOp are merged into a single transmission, reducing the number of data packet transmissions, thereby reducing communication latency and improving transmission efficiency.

[0107] Embodiments of this application also provide a DVM management node, which includes a processor and a memory, the memory storing a computer program; when the processor executes the computer program, it implements a method for accelerating the processing of DVM requests according to various embodiments of this application.

[0108] Embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the processor to implement a method for accelerating the processing of DVM requests according to various embodiments of this application.

[0109] Embodiments of this application also provide a computer program product comprising a computer program that, when executed by a processor, causes the processor to implement a method for accelerating the processing of DVM requests according to embodiments of this application.

[0110] It should be understood that the DVM management node, computer-readable storage medium, and computer program product according to the embodiments of this application are all used to implement the methods according to the embodiments of this application. Therefore, detailed descriptions of the above-described method embodiments will not be repeated here.

[0111] Those skilled in the art will understand that all or some of the functional modules / units in the steps, systems, and devices disclosed above can be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0112] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components. For example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0113] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technique for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH) or other disk storage; read-only optical disc (CD-ROM), digital versatile disc (DVD) or other optical disc storage; magnetic cartridges, magnetic tapes, disk storage or other magnetic storage; and any other media that can be used to store desired information and can be accessed by a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0114] This application has disclosed exemplary embodiments, and although specific terminology has been used, it is used and should be interpreted only in a general illustrative sense and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A method for accelerating the processing of distributed virtual memory (DVM) requests, applied to a DVM management node (DN), characterized in that, The method includes: Receive and store the DVM request sent by the first requesting node (RN); Monitor the processing time of the DVM request; If the processing time of the DVM request exceeds a time threshold, the DVM request will be accelerated. Wherein, accelerating the processing of the DVM request in response to the processing time exceeding a time threshold includes: If the processing time of the DVM request exceeds the time threshold, an interrupt is reported to the system software, and the identifier of the DVM request is stored in the first register of the DN. In response to the interrupt, the system software reads the information of the DVM request based on the identifier of the DVM request in the first register; The system software determines whether to accelerate the processing of the DVM request based on the information in the DVM request. In response to the system software determining to accelerate the DVM request, the system software stores the identifier of the DVM request in the second register of the DN and sets acceleration to enabled; In response to the acceleration enable, the DVM request is processed with acceleration.

2. The method according to claim 1, characterized in that, The duration threshold is determined based on the maximum waiting time for transaction processing and the average transaction processing time of the first requesting node (RN).

3. The method according to claim 1, characterized in that, In response to the acceleration enable, accelerating the DVM request includes: Read the identifier of the DVM request to be accelerated from the second register; Determine whether the mode of the DVM request corresponding to the read identifier is a synchronous request; If the DVM request is in the mode of a synchronous request, determine whether there are any unprocessed asynchronous requests from the same RN. In response to the existence of an unprocessed asynchronous request from the same RN, the read identifier is stored in the third register of the DN, and the DVM request is accelerated after the asynchronous request from the same RN has been processed. In response to the absence of any unprocessed asynchronous requests from the same RN, the DVM request corresponding to the read identifier is accelerated.

4. The method according to any one of claims 1 to 3, characterized in that, Accelerating the processing of the DVM request includes: Increase the priority of the DVM request.

5. The method according to claim 1, characterized in that, The method further includes: Broadcast the DVM request to the remote node.

6. The method according to claim 5, characterized in that, Broadcasting the DVM request to a remote node includes: Determine whether the DVM request is a synchronous request; In response to the DVM request being a synchronous request, determine whether the type of the last broadcast to the remote node was synchronous. In response to the previous broadcast to the remote node being of type synchronous, the DVM request is not broadcast to the remote node; In response to the fact that the type of the last broadcast to the remote node was not synchronous, the DVM request is broadcast to the remote node.

7. The method according to claim 1, characterized in that, The DVM request is a DVM operation DVMOp request.

8. The method according to claim 1, characterized in that, The method further includes: The DVM request is broadcast to all RNs except the first requesting RN via a single snoop-based DVM operation SnpDVMOp transmission.

9. A method for accelerating the processing of distributed virtual memory (DVM) requests, applied to a DVM management node (DN), characterized in that, The method includes: Receive and store the DVM request sent by the first requesting node (RN); Monitor the processing time of the DVM request; If the processing time of the DVM request exceeds a time threshold, the DVM request will be accelerated. Wherein, accelerating the processing of the DVM request in response to the processing time exceeding a time threshold includes: Determine whether the DVM request is a synchronous request; If the DVM request is in the mode of a synchronous request, determine whether there are any unprocessed asynchronous requests from the same RN. In response to the existence of an unprocessed asynchronous request from the same RN, the identifier of the DVM request is stored in the fourth register of the DN, and the DVM request is accelerated after the asynchronous request from the same RN is completed. In response to the absence of any unprocessed asynchronous requests from the same RN, the DVM request is accelerated.

10. The method according to claim 9, characterized in that, Accelerating the processing of the DVM request includes: Increase the priority of the DVM request.

11. A distributed virtual memory (DVM) management node (DN), characterized in that, The DN includes a processor and a memory. The memory stores computer programs; When the processor executes the computer program, it implements the method according to any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, causes the processor to implement the method according to any one of claims 1 to 10.

13. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, causes the processor to implement the method according to any one of claims 1 to 10.

Images