Memory management apparatus and memory management method

Abstract

The present invention relates to a memory management apparatus and a memory management method. The memory management method according to one embodiment may comprise steps in which: an I / O (input / output) classifier determines whether I / O requests are latency-sensitive; a queue management module classifies the latency-sensitive I / O requests into a fast-queue, so as to copy a memory to a host memory; the queue management module classifies, into a batch-queue, the latency-insensitive I / O requests; a queue processing module generates a scatter-gather list (SGL) for RDMA if the I / O requests classified into the batch-queue is accumulated and satisfies a predetermined flushing condition; the queue processing module transmits a request for registration to a byte-addressable storage on the basis of the generated SGL for the I / O requests; and the queue processing module generates the SGL for other I / O requests classified into the batch-queue until a response to the request for registration is received.

Description

Memory management device and management method

[0001] The present invention relates to a memory management device and a management method.

[0002] The proliferation of modern data-centric applications, such as data analytics, graph processing, and machine learning, has driven rapid advancements in storage technology. These advancements are forming a new memory hierarchy by introducing a new layer between traditional memory and storage—namely, byte-addressable storage devices. Possessing characteristics such as low access latency, high durability, and large storage capacity, these devices show potential to replace existing block-based storage systems.

[0003] While traditional block-based storage devices require navigating complex block layers and device drivers for data I / O, byte-level access storage devices enable data reading and writing using load and store commands. Although this approach reduces the complexity of the storage stack and simplifies the file system, it simultaneously introduces new performance bottlenecks. In particular, in these systems, data copying shifts the center of the bottleneck from the storage layer to the memory layer, leading to excessive use of CPU resources. Recent studies report that data copying operations can consume more than 60% of total CPU cycles.

[0004] To address this problem, methods to offload memory copying to hardware rather than the CPU are being proposed. On-chip Direct Memory Access (DMA) engines are hardware-based solutions for memory copying that have been widely used to reduce the CPU load on data transfer and improve performance. However, on-chip DMA has limitations, such as reduced efficiency due to initialization overhead at small I / O sizes (e.g., 16KB or less). Additionally, CPU usage efficiency in synchronous I / O operations is relatively lower compared to asynchronous operations. Due to these constraints, on-chip DMA is utilized only in a limited manner for some large-scale I / O operations.

[0005] Recently, Remote Direct Memory Access (RDMA) has been widely adopted in data centers and large-scale storage environments. RDMA provides hardware acceleration for data copying over a network and enables high-efficiency data transfer by minimizing CPU intervention. However, most RDMA technologies focus on data transfer between remote hosts, and research on data movement using RDMA within the same host is relatively lacking.

[0006] A memory management device and a management method are provided that divide the processing of I / O requests into host memory and byte-addressed storage according to latency sensitivity, and when processing in byte-addressed storage, generate a request for registration and generate an SGL for another request without waiting.

[0007] One embodiment of a memory management method may include: a step of determining whether an I / O request is latency-sensitive by an I / O classifier; a step of performing memory copy to host memory by classifying the latency-sensitive I / O request into a Fast-Queue by a queue management module; a step of classifying the latency-insensitive I / O request into a Batch-Queue by the queue management module; a step of generating a Scatter-Gather List (SGL) for RDMA by a queue processing module when the I / O request classified into the Batch-Queue accumulates and satisfies a predetermined flushing condition; a step of transmitting a request for registration to a byte-addressed storage based on the generated SGL for the I / O request by the queue processing module; and a step of generating the SGL for other I / O requests classified into the Batch-Queue by the queue processing module until a response to the request for registration is received.

[0008] In addition, according to one embodiment, the memory management method may further include the step of classifying I / O requests that satisfy predetermined function support conditions among the I / O requests that are not sensitive to delay time into a Write-Queue and performing memory copying to host memory.

[0009] In addition, according to one embodiment, the predetermined function support condition in the memory management method may be characterized as being at least one of the cases where the DDIO function is turned on, where the data preservation of the host memory is not guaranteed, or where a write amplification phenomenon occurs.

[0010] In addition, according to one embodiment, the predetermined flushing condition in the memory management method may be characterized as being at least one of the following: when there is a request for flushing, when the size of the input / output requests accumulated in the batch queue exceeds a predetermined threshold, and when a predetermined time timer is terminated.

[0011] In addition, according to one embodiment, the memory management method may further include a step of determining whether the input / output area of ​​a new input / output request not classified in the batch queue overlaps with the input / output area of ​​an input / output request classified in the batch queue.

[0012] In addition, according to one embodiment, the predetermined flushing condition in the memory management method may be characterized as a case where the input / output areas overlap.

[0013] In addition, according to one embodiment, the memory management method may further include the step of classifying the new input / output request into the batch queue.

[0014] In addition, according to one embodiment, the predetermined flushing condition in the memory management method may be characterized in that, when all of the accumulated input / output requests classified in the batch queue are read requests, the input / output area overlaps but does not satisfy the predetermined flushing condition.

[0015] Additionally, according to one embodiment, the memory management method may be characterized by canceling the transmission of a request for registration to the byte addressing storage in write-mode when there is an empty area in the SGL, and performing send-mode.

[0016] In addition, according to one embodiment, the memory management method may be characterized by performing a virtual registration for the transmission mode to maintain the order between the batch queues before performing the transmission mode.

[0017] One embodiment of a memory management device may include an I / O classifier that determines whether an I / O request is latency-sensitive, a queue management module that classifies the latency-sensitive I / O request into a Fast-Queue to perform memory copying to host memory, and classifies the latency-insensitive I / O request into a Batch-Queue, and a queue processing module that generates a Scatter-Gather List (SGL) for RDMA when the I / O requests classified into the Batch-Queue accumulate and satisfy a predetermined flushing condition, and transmits a request for registration to a byte-addressed storage based on the generated SGL for the I / O request by the queue processing module, and generates the SGL for other I / O requests classified into the Batch-Queue until a response to the request for registration is received.

[0018] In addition, according to one embodiment, the queue management module of the memory management device may be characterized by classifying I / O requests that satisfy predetermined function support conditions among the I / O requests that are not sensitive to delay time into a Write-Queue and performing memory copying to the host memory.

[0019] In addition, according to one embodiment, the predetermined function support condition of the queue management module in the memory management device may be characterized as being at least one of the cases where the DDIO function is turned on, where the data retention of the host memory is not guaranteed, or where a write amplification phenomenon occurs.

[0020] In addition, according to one embodiment, the predetermined flushing condition of the queue processing module in the memory management device may be characterized as being at least one of the following: when there is a request for flushing, when the size of the input / output requests accumulated in the batch queue exceeds a predetermined threshold, and when a predetermined time timer has expired.

[0021] In addition, according to one embodiment, the queue management module in the memory management device may be characterized by determining whether the input / output area of ​​a new input / output request not classified in the batch queue overlaps with the input / output area of ​​an input / output request classified in the batch queue.

[0022] In addition, according to one embodiment, the predetermined flushing condition of the queue processing module in the memory management device may be characterized as a case where the input / output area overlaps.

[0023] In addition, according to one embodiment, the queue management module in the memory management device may be characterized by classifying the new input / output request into the batch queue.

[0024] In addition, according to one embodiment, the predetermined flushing condition of the queue processing module in the memory management device may be characterized in that, when all of the accumulated input / output requests classified in the batch queue are read requests, the input / output area overlaps but does not satisfy the predetermined flushing condition.

[0025] Additionally, according to one embodiment, the queue processing module in the memory management device may be characterized by canceling the transmission of a request for registration to the byte addressing storage in write mode when there is an empty area in the SGL, and performing send mode.

[0026] In addition, according to one embodiment, the queue processing module in the memory management device may be characterized by performing a virtual registration for the transmission mode to maintain the order between the batch queues before performing the transmission mode.

[0027] FIG. 1 is a block diagram of a terminal to which a memory management device according to one embodiment may be applied.

[0028] FIG. 2 is a block diagram of a memory management device according to one embodiment.

[0029] FIG. 3 is a detailed block diagram of a processor of a memory management device according to one embodiment.

[0030] FIG. 4 is a detailed block diagram of a memory of a memory management device according to one embodiment.

[0031] FIG. 5 is a conceptual diagram of a queue classification operation of a memory management device according to one embodiment.

[0032] FIG. 6 is a conceptual diagram of the registration and transmission operations of a memory management device according to one embodiment.

[0033] Figure 7 is a conceptual diagram of a conventional byte-addressed storage management method.

[0034] FIG. 8 is a conceptual diagram of a byte addressing storage management method of a memory management device according to one embodiment.

[0035] FIG. 9 is a conceptual diagram of the write-mode operation of batching of a memory management device according to one embodiment.

[0036] FIG. 10 is a conceptual diagram of the conditions under which the send-mode of batching of a memory management device is operated according to one embodiment.

[0037] FIG. 11 is a conceptual diagram of a send-mode virtual registration operation during batching of a memory management device according to one embodiment.

[0038] FIG. 12 is a flowchart of a memory management method using a hash-based distributed page table according to one embodiment.

[0039] The advantages and features of the present invention and the methods for achieving them will become clear by referring to the embodiments described below in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below but may be implemented in various different forms. These embodiments are provided merely to ensure that the disclosure of the present invention is complete and to fully inform those skilled in the art of the scope of the invention, and the present invention is defined only by the scope of the claims.

[0040] The terms used in this specification will be briefly explained, and the invention will be described in detail.

[0041] The terms used in this invention have been selected based on currently widely used general terms, taking into account their functions within the invention; however, these terms may vary depending on the intent of those skilled in the art, case law, the emergence of new technologies, etc. Additionally, in specific cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in detail in the relevant description of the invention. Therefore, the terms used in this invention should be defined not merely by their names, but based on their meanings and the overall content of the invention.

[0042] Throughout the specification, when a part is described as "comprising" a certain component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. Furthermore, terms such as "part," "module," and "unit" used in the specification refer to a unit that processes at least one function or operation and may be implemented as software, hardware components such as FPGAs or ASICs, or a combination of software and hardware. However, the terms "part," "module," and "unit" are not limited to software or hardware. "Part," "module," and "unit" may be configured to reside in an addressable storage medium or configured to run one or more processors. Accordingly, as an example, terms such as "part," "module," and "unit" include components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0043] Below, embodiments of the present invention are described in detail with reference to the attached drawings so that those skilled in the art can easily implement the invention. Additionally, parts of the drawings that are irrelevant to the description are omitted to clearly explain the invention.

[0044] Terms including ordinal numbers, such as "first," "second," etc., may be used to describe various components, but the components are not limited by the terms. The terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component. The term "and / or" includes a combination of multiple related items or any one of the multiple related items.

[0045] Hereinafter, an embodiment of a memory management device (100) and a management method will be described with reference to the attached drawings.

[0046] Hereinafter, an embodiment of a memory management device (100) will be described with reference to FIGS. 1 to 10.

[0047] FIG. 1 is a block diagram of a terminal to which a memory management device (100) according to one embodiment can be applied.

[0048] The memory management device (100) can classify queues by analyzing continuously input I / O requests (input / output requests) and determining whether to process them in the host memory (410) or the byte-addressable storage (450) depending on whether the request is a delay-sensitive input / output request. Additionally, the memory management device (100) can perform memory copying to the host memory (410) so that among the input / output requests classified into Fast-Queue, Write-Queue, and Batch-Queue, the Fast-Queue and Write-Queue requests are processed in the host memory (410). Additionally, the memory management device (100) can generate a Scatter-Gather List (SGL) for Remote Direct Memory Access (RDMA) and transmit a request for registration to the byte addressing storage (450) when a predetermined flushing condition is satisfied so that an I / O request classified into a batch queue can be processed by the byte addressing storage (450) through batching. In this case, the memory management device (100) can prepare for data transmission by generating an SGL for other I / O requests classified into the batch queue before receiving a response, without waiting until a response is received from the byte addressing storage (450).

[0049] The memory management device (100) can be applied to a mobile terminal (101), a computing terminal (102), a workstation (103), and a server (104), and can also be applied to any device with an OS capable of running byte-addressed storage (450).

[0050] Hereinafter, the configuration included in the memory management device (100) will be described with reference to FIGS. 2 to 10.

[0051] FIG. 2 is a block diagram of a memory management device (100) according to one embodiment, FIG. 3 is a detailed block diagram of a processor (200) of a memory management device (100) according to one embodiment, and FIG. 4 is a detailed block diagram of a memory (400) of a memory management device (100) according to one embodiment.

[0052] The memory management device (100) may include a processor (200), an input / output interface (300), and a memory (400).

[0053] The input / output interface (300) can transmit queues and SGLs to the host memory (410) and byte-addressed storage (450) so that operations for input / output requests in the host memory (410) and byte-addressed storage (450) can be performed according to the queues classified by the processor (200). The input / output interface (300) can perform RDMA functions and may include an RDMA NIC (Network Interface Controller) configured to perform this. The input / output interface (300) can support reading or writing memory areas of a remote host through the Verbs API.

[0054] Here, SGL I / O for an SGL can reduce memory copy overhead and improve data transfer performance by allowing data to be stored or read across multiple non-contiguous memory buffers instead of being copied to a single contiguous memory buffer. The RDMA Verbs API provides functions that accept an SGL as a parameter, such as rdma_post_recvv(), which can be submitted to the hardware as a single job request. The RDMA NIC can perform memory copy operations for each memory buffer of the SGL.

[0055] The input / output interface (300) can implement a workflow for moving data between the host memory (410) and the byte-level access storage device using RDMA.

[0056] The memory (400) may include host memory (410) and byte addressable storage (450).

[0057] The host memory (410) can process input / output requests classified into fast queue and light queue among input / output requests as main memory. The host memory (410) may be implemented independently of the processor (200) or may be implemented included in the processor (200).

[0058] The host memory (410) may include, for example, a central processing unit (CPU), a graphics processing unit (GPU), a microcontroller unit (MCU), an application processor (AP), an electronic control unit (ECU), and / or at least one electronic device capable of performing various calculations and control processing. These devices may be implemented, for example, by using one or more semiconductor chips, circuits, or related components alone or in combination.

[0059] The byte addressable storage (450) can process input / output requests classified in the fast queue. When the byte addressable storage (450) performs file input / output (I / O) which is an input / output request, memory copying may be used.

[0060] The byte-addressed storage (450) may include permanent memory, CXL-SSD and / or at least one electronic device capable of processing input / output requests in byte units. These devices may be implemented, for example, by using one or more semiconductor chips, circuits, or related components alone or in combination.

[0061] The memory (400) may include at least one of a main memory and an auxiliary memory. The main memory may be implemented using a semiconductor storage medium such as ROM and / or RAM, for example, and the auxiliary memory may be implemented based on a device capable of storing data permanently or semi-permanently, such as a flash memory device (Solid State Drive (SSD), etc.), an SD (Secure Digital) card, a hard disk drive (HDD), a compact disc, a DVD, or a laser disc.

[0062] The processor (200) can classify input / output requests into a fast queue, a writing queue, and a batch queue, and transmit the SGL, queue, and input / output requests to host memory (410) or byte-addressed storage (450) through the input / output interface (300).

[0063] The processor (200) may include, for example, a central processing unit (CPU), a graphics processing unit (GPU), a microcontroller unit (MCU), an application processor (AP), an electronic control unit (ECU), and / or at least one electronic device capable of performing various calculations and control processing. These devices may be implemented, for example, by using one or more semiconductor chips, circuits, or related components alone or in combination.

[0064] The processor (200) may include an I / O classifier (210), a queue management module (220), and a queue processing module (230).

[0065] Hereinafter, the operation of the I / O classifier (210), queue management module (220), and queue processing module (230) will be explained with reference to FIG. 5.

[0066] FIG. 5 is a conceptual diagram of a queue classification operation of a memory management device (100) according to one embodiment.

[0067] The I / O classifier (210) receives input / output requests in chronological order and can transmit the input / output requests to the queue management module (220) based on information such as the type of input / output request (read or write), the requirements of the application (L-app or B-app), and whether specific hardware functions are supported. The I / O classifier (210) can determine whether the input / output request is sensitive to latency. For example, the I / O classifier (210) can classify latency-sensitive applications (L-app) and bandwidth-intensive applications (B-app), and determine that L-app is latency-sensitive and B-app is not latency-sensitive. Additionally, the I / O classifier (210) can determine among the latency-insensitive input / output requests that satisfy predetermined function support conditions. Here, the predetermined function support conditions refer to cases where the DDIO function is turned on and data preservation of the host memory (410) is not guaranteed or write amplification occurs, and specific details regarding this will be explained in the queue management module (220).

[0068] The queue management module (220) can classify the queues to place input / output requests based on the sensitivity to delay time for input / output requests determined by the I / O classifier (210) and predetermined function support conditions.

[0069] Specifically, the queue management module (220) can classify input / output requests into a Fast-Queue (FQ), a Batch-Queue (BQ), and a Write-Queue (WQ).

[0070] The queue management module (220) can classify I / O requests from latency-sensitive applications (L-apps) into a fast queue and route them to copy memory so that I / O requests are processed immediately in host memory (410) without batching. This allows latency-sensitive applications to avoid additional delays caused by batching.

[0071] The queue management module (220) can classify I / O requests from applications (B-apps) that are not sensitive to latency and where CPU efficiency or processing performance is important into batch queues. This is to enable bandwidth-intensive applications to achieve higher CPU efficiency through batching.

[0072] The queue management module (220) can classify write requests into a write queue based on whether specific hardware functions are supported among requests that can be delivered to the batch queue. That is, the queue management module (220) can classify I / O requests that satisfy predetermined function support conditions among I / O requests that are not sensitive to latency into a write queue (Write-Queue). Here, the predetermined function support conditions may be at least one of the cases where the DDIO function is turned on, where the data durability of the host memory (410) is not guaranteed, or where write amplification occurs. For example, if the DDIO function is turned on, in the case of a write request, the data is stored in the CPU LLC rather than in the permanent memory or storage device, so data durability may be compromised. If a function such as eADR is provided, the durability of LLC data can also be guaranteed, but in the case of Intel's permanent memory, when a write request is delivered through the LLC, write amplification occurs, resulting in performance degradation. Therefore, for write requests that do not go to the FQ, if DDIO is turned on and LLC data preservation is not guaranteed or write amplification occurs, they can be classified into the write queue. The queue management module (220) can perform memory copying to process input / output requests for the write queue in the host memory (410).

[0073] The queue processing module (230) can generate an SGL and perform RDMA to transmit operations to be processed in the host memory (410) and byte addressing storage (450) according to the queues classified by the queue management module (220) for input / output requests.

[0074] The queue processing module (230) can immediately process I / O requests classified as Fast Queue and Light Queue in the host memory (410). The queue processing module (230) can always prioritize processing I / O requests classified as Fast Queue to ensure low latency of the L-app. That is, the queue processing module (230) immediately processes requests delivered to the FQ and WQ using the CPU memory copy method. However, the queue processing module (230) always prioritizes processing FQ requests because FQ requests have a higher priority.

[0075] The queue processing module (230) can perform RDMA through batching for input / output requests classified into a batch queue. That is, the queue processing module (230) can process all requests delivered to the BQ using an off-chip DMA engine. The purpose of the BQ is to gather small input / output requests and combine them into one large input / output request. To this end, batching is performed within the BQ. That is, multiple input / output requests are gathered to a certain level and then combined into a single request to be sent down.

[0076] The queue processing module (230) manages asynchronous I / O requests classified as batch queues, and each request can return control to the file system layer even before the batch job is completed. The queue processing module (230) can flush the batch job if a predetermined flushing condition is satisfied.

[0077] Here, the predetermined flushing condition means satisfying at least one of the following: when there is a request for flushing (e.g., a fsync call), when the size of I / O requests accumulated in the batch queue exceeds a predetermined threshold (when the size of accumulated I / O requests exceeds a predetermined threshold), and when a predetermined time timer expires (when the batch timer expires).

[0078] Additionally, the predetermined flushing condition may be a condition where the input / output area overlaps when the queue management model determines whether the input / output area of ​​a new input / output request not classified in the batch queue overlaps with the input / output area of ​​an input / output request classified in the batch queue. In this case, the queue processing module (230) may classify the new input / output request into the batch queue. However, even in this case, the queue processing module (230) may determine that the predetermined flushing condition is not satisfied even if the input / output area overlaps, if all of the accumulated input / output requests classified in the batch queue are read requests.

[0079] Specifically, RDMA has an internal RDMA Queue and guarantees that requests are processed in the order they are delivered to it. However, when multiple I / O requests are combined and processed as a single batch request, the order of different I / O requests within the batch is not guaranteed. Therefore, if I / O areas overlap within a batch, the final result may differ depending on the execution order. To prevent this, the queue management module (220) determines whether the I / O areas of a newly received I / O request overlap with those of requests already in the BQ. If they overlap, the queue processing module (230) combines the requests currently in the BQ into a single request to perform flushing, and starts batching anew starting from the newly received I / O request. One exception is that if all requests within a batch are read requests, the queue processing module (230) does not flush even if the I / O request areas overlap.

[0080] Hereinafter, with reference to FIGS. 6 to 10, the operation of the queue processing module (230) processing input / output requests classified into fast queue, light queue, and batching queue through the host memory (410) and byte addressing storage (450) will be described.

[0081] The queue processing module (230) moves data using memcpy and RDMA-based DMA engines and minimizes contention between cores by allocating RDMA resources (e.g., RDMA QP, memory area) per core. Additionally, the queue processing module (230) prioritizes L-apps over B-apps through the following two techniques. Specifically, the queue processing module (230) can limit the memory bandwidth usage of B-apps by 1) adjusting the priority of CPU scheduling and 2) resetting the batch timer.

[0082] The queue processing module (230) can perform memory bandwidth throttling on I / O requests classified into the fast queue. Specifically, the FQ selects memcpy or off-chip DMA depending on the I / O size. Since memcpy consistently achieves lower latency than off-chip DMA for I / O sizes of 32KB or less, requests of this size or smaller are processed using memcpy. FQ requests are processed before BQ by 1) a scheduling technique that increases the CPU priority of L-app requests, and 2) a technique that limits memory bandwidth usage of B-apps by initializing the batch timer of BQ (timeout-mode). Here, timeout-mode means that batch flushing is performed only upon the expiration of the timer. Technique 1) is a well-established method that allows L-app requests to secure more CPU time. However, this method alone may not be sufficient to control memory bandwidth consumption of BQ requests using off-chip DMA. Accordingly, the queue processing module (230) tracks the memory bandwidth used by all FQ requests, which is managed by globally updating the core-specific I / O counter. If the total bandwidth of the FQ is lower than the target value, the BQ is switched to timeout mode and flushing occurs only upon the expiration of the batch timer. Additionally, the timer is reset at each timeout to delay the BQ flushing. That is, the queue processing module (230) calculates the memory bandwidth by recording the throughput of FQ requests used within the system per unit time and allows more memory bandwidth to be used by the FQ requests by continuously delaying the flushing of the BQ as needed.

[0083] In the present invention, data transfer between the host memory (410) and the byte unit access device takes place within the same host, so the transfer of rkey and remote_key is unnecessary. Data transfer preparation can begin immediately after the registration task request (WR) is completed. In this process, if data is attempted to be transferred before memory registration is completed, the RDMA write may fail; therefore, data is transferred after registration is completed. That is, as illustrated in FIG. 8, the queue processing module (230) performs I / O requests classified in the batch queue in a two-stage workflow. The queue processing module (230) 1) prepares all task requests, such as SGL generation required for data transfer and completion signals, in the preparation stage, and 2) in the transfer stage, when memory registration is completed, executes the prepared task requests and starts data transfer. This solves the problem of having to perform the registration procedure and wait until the registration WR processing is completed in the byte addressing storage (450) when performing with conventional on-chip DMA as illustrated in FIG. 7. Specifically, conventional on-chip DMAs would perform busy waiting or put threads in processing to sleep, both of which can cause performance degradation. That is, to eliminate such overhead, the queue processing module (230) of the present invention proceeds with the step of creating an SGL for I / O on the storage device side in the interrupt context and submitting an RDMA write for data transfer to the SQ when an interrupt indicating the completion of registration WR processing is performed. The CPU can perform the next request task until the interrupt arrives, which helps improve performance.

[0084] The queue processing module (230) performs an RDMA workflow for moving data between host memory (410) and byte-addressed storage (450) (e.g., non-volatile memory). FIG. 6 illustrates an example of a read operation transferring data from a page in src (byte-addressed storage (450)) to a page in dst (host memory (410)). The memory management unit (100) creates RDMA queue pairs (QPs), assuming that the operating system has pre-pinned the pages in host memory (410) so that they are not paged out, and each QP consists of a send queue (SQ) and a receive queue (RQ), which are assigned to the src and dst devices, respectively. For simplification, the completion queue (CQ) is omitted in FIG. 6.

[0085] Specifically, as illustrated in FIG. 6, the memory management device (100) divides the process into Phase 1, which first prepares all necessary WRs in advance and then submits a Registration WR, and Phase 2, which submits the prepared WRs directly to the SQ / RQ to move data and perform an I / O termination notification. Operations 1 through 6 in FIG. 6 represent the sequence of Phase 1, where steps 1 through 5 are steps for preparing necessary WRs, and in step 6 (post registration WR), registration submission to the RDMA SQ is performed. Step 1 is to prepare a reception WR for a completion notification (corresponding to step 5), Step 2 is to map a scatter-gather list (SGL) to a memory area (MR) for registration and data transmission, Step 3 is a registration WR for memory registration, Step 4 is to transmit a transmission WR for data transmission, and Step 5 is to transmit a transmission WR to notify of the completion of the operation. Step 6 is to post the registration WR to the transmission queue.

[0086] 6. Once the registration process is complete, in Phase 2 (operations 7 through 11), WRs for data transmission and WRs to signal I / O completion are submitted to the respective SQ and RQ. Here, RDMA writes can be used for data transmission (Step 9), and RDMA sends can be used to signal I / O completion (Step 10). In other words, once memory registration is complete, Phase 2 begins in the interrupt context. Specifically, Step 7 is a WR for signaling completion from dst, Step 8 is a WR for data transmission from src, and Step 9 involves data transmission from src to dst via one or more RDMA writes, depending on the I / O size. Subsequently, in Step 10, the operation completion is signaled via an RDMA send. Since RDMA guarantees the order of job requests within the queue, when the receive queue of dst receives an RDMA send, the RDMA write is considered complete in Step 11. In the memory management device (100) of the present invention, an RDMA-based DMA that follows this workflow is called "off-chip DMA". Similarly, in the case of write operations, data can be moved from the host memory (410) to the storage device through the same process.

[0087] The queue processing module (230) processes requests for queues (FQ, WQ, BQ) managed by the I / O classifier (210) and the queue management module (220), and moves data using RDMA-based DMA and memcpy.

[0088] The queue processing module (230) creates an SGL by combining multiple I / O requests for I / O requests classified into a batch queue. This SGL is mapped to a memory region (MR) for RDMA registration, which is write-mode. The queue processing module (230) performs write-mode when all SGL elements are aligned to page boundaries as shown in FIG. 10 and there is no empty region between the first and last addresses.

[0089] However, in realistic applications, the size of I / O requests varies, and misalignment is common, especially when they are smaller than 4KB. In this case, as illustrated in FIG. 11, a gap occurs within the SGL, making it impossible to map the SGL to a memory area. To resolve this, the queue processing module (230) switches the operation to send-mode. In send-mode, memory registration is not required, but an RDMA recv setting corresponding to the peer-side is required.

[0090] The RDMA implementation of the queue processing module (230) limits the SGL array size for each RDMA send, and if the batch size (SGL size) is within the limit, the send-mode can transmit data through a single RDMA send. This is equivalent to the write-mode using a separate RDMA send to signal I / O completion. However, if the SGL size exceeds the limit, the send-mode requires an additional RDMA send-recv pair. With this in mind, the queue processing module (230) sets a batch threshold to ensure that the SGL size remains within the limit. Finally, the queue processing module (230) determines the choice between the write-mode and the send-mode based on whether there is a gap within the SGL. If the I / O size is individually large and exceeds the batch threshold, the queue processing module (230) immediately processes it using the write-mode. This is because in such cases, the SGL is continuous and has no gaps.

[0091] The dual context workflow used in Write-mode illustrated in FIG. 8 enables pipelining execution between batches. That is, while one batch is waiting for registration to be completed, the next batch can start preparing. In this way, the queue processing module (230) can operate so that all batches overlap the waiting time between preparation and execution.

[0092] In other words, the limitations of the RDMA send method compared to the RDMA write method are that the array size of the SGL that can be transmitted by a single RDMA send is limited to 30 (which may vary depending on the hardware), the size of the data that can be transmitted at once is limited (for example, if one array points to one page, 30 pages * 4KB = 120KB), and the process of putting the corresponding RDMA recv into the RQ for each RDMA send is required. Therefore, by setting a threshold for the batch size considering the maximum array size of the SGL, it becomes possible to process each batch through a single RDMA send / recv submission. The queue processing module (230) checks the status of the SGL for each batch processing and determines the Write-mode and Send-mode to move the data. If a large I / O request exceeding the batch threshold is received, the large I / O is generally processed immediately through the Write-mode because it is a continuous SGL.

[0093] If there is an empty area in the SGL, the queue processing module (230) can cancel the transmission of a request for registration to the byte addressing storage (450) in write-mode, perform send-mode, and perform virtual registration for the send-mode to maintain the order between batch queues before performing the send-mode.

[0094] Since Write-mode and send-mode can be mixed, the queue processing module (230) performs a virtual registration operation in send-mode to maintain order between batches. This virtual registration is implemented by posting a dummy RDMA write to the dst-side RDMA SQ, which ensures that send-mode data transfer begins after the virtual registration is completed, as illustrated in FIG. 11. Unlike a standard RDMA write, this virtual registration does not transfer data and does not require memory registration, thus minimizing CPU overhead. That is, if the next batch is transferred to Send-mode while the Write-mode registration step is being performed, a virtual registration WR (containing empty information) is submitted to the SQ so that the Send-mode data transfer proceeds after the previously performed Write-mode registration is completed and the RDMA write is executed.

[0095] Hereinafter, an embodiment of a memory management method will be described with reference to FIG. 12.

[0096] FIG. 12 is a flowchart of a memory management method using a hash-based distributed page table according to one embodiment.

[0097] First, the I / O classifier (210) can determine whether the I / O request is latency-sensitive (S100).

[0098] Afterwards, the queue management module (220) can classify latency-sensitive I / O requests into a Fast-Queue and perform memory copying to the host memory (410) (S200), and classify latency-insensitive I / O requests into a Batch-Queue (S300).

[0099] The queue processing module (230) can generate a Scatter-Gather List (SGL) for RDMA (S400) when input / output requests classified into batch queues accumulate and satisfy a predetermined flushing condition. The queue processing module (230) can transmit a request for registration to a byte addressing storage (450) based on the generated SGL for the input / output requests (S500).

[0100] Finally, the queue processing module (230) can generate SGLs (S600) for other input / output requests classified in the batch queue until it receives a response to the request for registration.

[0101] Those skilled in the art related to the embodiments of the present invention will understand that they may be implemented in modified forms without departing from the essential characteristics of the description. Therefore, the disclosed methods should be considered in an illustrative rather than a restrictive sense. The scope of the invention is defined by the claims, not by the detailed description of the invention, and all variations within the scope of the claims should be interpreted as being included within the scope of the invention.

[0102] A memory management device and management method according to an embodiment of the present invention relate to a memory management technology that improves I / O processing efficiency between a host and byte-addressed storage, and can be applied to various storage-based industrial fields such as data centers, cloud servers, and high-performance computing (HPC) systems. In particular, the effects of reducing CPU utilization and shortening latency through RDMA and batch transfer have great potential for industrial application in large-scale data processing and real-time application services.

[0103]

[0104] [Explanation of the symbol]

[0105] 100: Memory Management Unit 200: Processor

[0106] 210: I / O Classifier 220: Queue Management Module

[0107] 230: Queue processing module 300: I / O interface

[0108] 400: Memory 410: Host Memory

[0109] 450: Byte-addressed storage

Claims

1. A step of determining whether an I / O request is latency-sensitive by an I / O classifier; A step of classifying the delay-sensitive I / O requests into a Fast-Queue by a queue management module and performing memory copying to host memory; A step of classifying I / O requests that are not sensitive to delay time into a Batch Queue by the above-mentioned queue management module; A step of generating a Scatter-Gather List (SGL) for RDMA when I / O requests classified into the batch queue by the queue processing module accumulate and satisfy a predetermined flushing condition; A step of transmitting a request for registration in a byte addressing storage based on the generated SGL for the input / output request by the above queue processing module; and A step of generating the SGL for other input / output requests classified in the batch queue by the above queue processing module until a response to the request for registration is received; A memory management method including 2. In Paragraph 1, Among the above-mentioned in-delay time insensitive I / O requests, those satisfying predetermined function support conditions are classified into a Write-Queue and memory copying is performed in the host memory; A memory management method characterized by further including 3. In Paragraph 2, The above-determined function support conditions are, A memory management method characterized by at least one of the following cases: when the DDIO function is turned on, when data preservation of the host memory is not guaranteed, or when a write amplification phenomenon occurs.

4. In Paragraph 1, The above-determined flushing conditions are, A memory management method characterized by having at least one of the following cases: when there is a request for flushing, when the size of the input / output requests accumulated in the batch queue exceeds a predetermined threshold, and when a predetermined time timer has expired.

5. In Paragraph 1, A step of determining whether the input / output area of ​​a new input / output request not classified in the batch queue overlaps with the input / output area of ​​an input / output request classified in the batch queue; A memory management method characterized by further including 6. In Paragraph 5, The above-determined flushing conditions are, A memory management method characterized by the fact that the above input / output areas overlap.

7. In Paragraph 6, A step of classifying the above new input / output request into the above batch queue; A memory management method characterized by further including 8. In Paragraph 6, The above-determined flushing conditions are, A memory management method characterized by not satisfying the predetermined flushing condition even if the input / output areas overlap, when all input / output requests accumulated and classified in the batch queue are read requests.

9. In Paragraph 1, A memory management method characterized by canceling the transmission of a request for registration to the byte addressing storage in write-mode when there is an empty area in the above SGL, and performing send-mode.

10. In Paragraph 9, A memory management method characterized by performing a virtual registration for the transmission mode to maintain the order between the batch queues before performing the transmission mode.

11. I / O classifier for determining latency sensitivity for I / O requests; A queue management module that classifies the above-mentioned latency-sensitive I / O requests into a Fast-Queue to perform memory copying to host memory, and classifies the above-mentioned latency-insensitive I / O requests into a Batch-Queue; and A queue processing module that generates a Scatter-Gather List (SGL) for RDMA when I / O requests classified into the batch queue accumulate and satisfy a predetermined flushing condition, transmits a request for registration in a byte-addressed storage based on the generated SGL for the I / O requests by the queue processing module, and generates the SGL for other I / O requests classified into the batch queue until a response to the request for registration is received; A memory management device including 12. In Paragraph 11, The above queue management module is, A memory management device characterized by classifying I / O requests that satisfy predetermined function support conditions among the above-mentioned insensitive delay requests into a Write-Queue and performing memory copying to host memory.

13. In Paragraph 12, The predetermined function support conditions of the above-mentioned queue management module are, A memory management device characterized by at least one of the following cases: when the DDIO function is turned on, when data preservation of the host memory is not guaranteed, or when a write amplification phenomenon occurs.

14. In Paragraph 11, The predetermined flushing condition of the above-mentioned queue processing module is, A memory management device characterized by having at least one of the following cases: when there is a request for flushing, when the size of input / output requests accumulated in the batch queue exceeds a predetermined threshold, and when a predetermined time timer has expired.

15. In Paragraph 11, The above queue management module is, A memory management device characterized by determining whether the input / output area of ​​a new input / output request not classified in the batch queue overlaps with the input / output area of ​​an input / output request classified in the batch queue.

16. In Paragraph 15, The predetermined flushing condition of the above-mentioned queue processing module is, A memory management device characterized by the case where the above input / output areas overlap.

17. In Paragraph 16, The above queue management module is, A memory management device characterized by classifying the above new input / output request into the above batch queue.

18. In Paragraph 16, The predetermined flushing condition of the above-mentioned queue processing module is, A memory management device characterized by not satisfying the predetermined flushing condition even if the input / output areas overlap, when all input / output requests accumulated and classified in the batch queue are read requests.

19. In Paragraph 1, The above queue processing module is, A memory management device characterized by canceling the transmission of a request for registration to the byte addressing storage in write-mode and performing send-mode when there is an empty area in the above SGL.

20. In Paragraph 19, The above queue processing module is, A memory management device characterized by performing a virtual registration for the transmission mode to maintain the order between the batch queues before performing the transmission mode.

Images