Smart memory module and method of operating the same

Abstract

A smart memory module and a method of operating the smart memory module are provided. The smart memory module includes at least one memory device connected to the at least one channel, a controller configured to control the at least one memory device, and a host interface circuit configured to perform peer-to-peer (P2P) communication with an external device and receive a live migration request from a host device. And the controller is configured to respond to the real-time migration request, and execute migration operation of sending buffer data to target equipment through the P2P communication under the condition that a buffer area is full.

Description

Technical Field

[0001] The inventive concept relates to an intelligent memory module and a method of operating the intelligent memory module. Background Art

[0002] Generally, live migration is a process of moving an important running service program to another environment without interruption to provide high availability and service continuity. Live migration can be used in cases such as database upgrades, hardware transfers, and data center transfers, and can have core features such as providing uninterrupted service and maintaining data consistency. Considering ensuring data consistency, managing transactions, preventing data loss, logging and monitoring, and optimizing performance, live migration requires careful planning and may be mainly used for large databases and critical business systems. Summary of the Invention

[0003] Some aspects of the inventive concept provide a novel intelligent memory module that supports live migration and a method of operating the intelligent memory module.

[0004] According to some aspects of the present disclosure, there is provided an intelligent memory module including: at least one storage device connected to at least one channel; a controller configured to control the at least one storage device; and a host interface circuit configured to perform point-to-point (P2P) communication with an external device and receive a live migration request from a host device. The controller is configured to perform a migration operation of sending buffered data to a target device through the P2P communication in the case where a buffer is full in response to the live migration request.

[0005] According to some aspects of the present disclosure, there is provided a method of operating an intelligent memory module, the method including: performing an initialization operation for live migration from a host device; receiving a live migration request from the host device; and performing a migration operation using a least recently used (LRU) buffer cache in response to the live migration request. In response to the LRU buffer cache being full, the migration operation flushes data stored in the LRU buffer cache to a target device through point-to-point P2P communication.

[0006] According to some aspects of the present disclosure, a method of operating an intelligent memory module is provided. The method includes: receiving a live migration request from a host device; starting a migration loop in response to the live migration request; sending block data corresponding to the migration loop to a destination device through P2P communication; moving a migration window to the destination device according to the sending of the block data, where the migration window separates a migrated area and an area not yet migrated from each other; executing a next migration loop in response to the migration window not being the last migration window; and flushing data stored in a least recently used (LRU) buffer cache to the destination device through the P2P communication in response to the migration window being the last migration window.

[0007] According to some aspects of the present disclosure, a host system is provided. The host system includes: a source server, a source device connected to the source server, a destination server, a destination device connected to the destination server, a network fabric configured to connect the source device and the destination device to each other, and a fabric manager configured to control the network fabric. The source device may be configured to receive a live migration request from the source server and, in response to the live migration request, perform a migration operation on the destination device through P2P communication.

[0008] According to some aspects of the present disclosure, a computing system is provided. The computing system includes at least one memory module, at least one processor configured to control the at least one memory module, a switch connected to the at least one processor through a Compute Express Link (CXL) interface, at least one storage device connected to the switch through the CXL interface, and at least one storage device connected to the switch through the CXL interface. At least one of the at least one storage device and the at least one storage device may be configured to perform a migration operation in response to a live migration request of the at least one processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other aspects, features, and advantages of the inventive concept will be more clearly understood from the following detailed description in conjunction with the accompanying drawings, in which:

[0010] Figure 1 is a diagram showing a host system 1 according to some example embodiments of the inventive concept;

[0011] Figure 2A is a diagram showing an intelligent memory module 100 according to some example embodiments of the inventive concept, and Figure 2B is a diagram showing an intelligent memory module 200 according to some example embodiments of the inventive concept;

[0012] Figure 3 is a diagram illustrating live migration of a generic host system;

[0013] Figure 4 is a diagram illustrating a live migration operation of a host system 1 according to some example embodiments of the inventive concept;

[0014] Figure 5 is a flowchart illustrating a device driver live migration operation of a host system 1 according to some example embodiments of the inventive concept;

[0015] Figure 6 is a flowchart illustrating a device driver live migration operation of a host system 1 according to some example embodiments of the inventive concept;

[0016] Figure 7 is a diagram illustrating an initialization operation of a device driver migration operation of a host system 1 according to some example embodiments of the inventive concept;

[0017] Figure 8 is a diagram illustrating a migration operation of a device driver migration from the perspective of a migration controller in a host system 1 according to some example embodiments of the inventive concept;

[0018] Figure 9 is a diagram illustrating a device driver migration operation from the perspective of a VM IO in a host system 1 according to some example embodiments of the present inventive concept;

[0019] Figure 10 is a diagram illustrating device buffer flushing of a host system 1 according to some example embodiments of the inventive concept;

[0020] Figure 11 is a flowchart illustrating a live migration operation of a smart device according to some example embodiments of the inventive concept;

[0021] Figure 12A , Figure 12B and Figure 12C is an exemplary diagram illustrating a host system according to some exemplary embodiments of the inventive concept;

[0022] Figure 13 is a diagram illustrating inter-system live migration of a host system 3 according to some example embodiments of the inventive concept;

[0023] Figure 14 is a diagram illustrating inter-system live migration of a host system 4 according to some example embodiments of the inventive concept;

[0024] Figure 15 is a diagram illustrating a computing system 1000 according to some example embodiments of the inventive concept; and

[0025] Figure 16 FIG. is a diagram of a data center showing a computing system to which some example embodiments according to the inventive concept are applied. DETAILED DESCRIPTION

[0026] Hereinafter, example embodiments of the inventive concept will be described clearly and specifically so that those skilled in the art can easily implement the example embodiments with reference to the accompanying drawings.

[0027] A typical data center supports live migration, which transfers memory and storage contents to different hosts in anticipation of system errors to ensure high availability of the system. However, this process is complex and repetitive because it is replicated through host software, resulting in a huge overhead.

[0028] In contrast, a host system according to some example embodiments of the present invention can support device-to-device communication via a point-to-point connection. Accordingly, the host system of the present invention can support offloading of live migration by copying from a storage device to a remote memory via a NIC (Network Interface Card), thereby performing fast live migration. Offloading the live migration operation can minimize (e.g., reduce or shrink) the amount of system resource usage and significantly improve the processing speed. In addition, offloading dirty block management during live migration can improve the operation process. Here, a dirty block refers to a block that needs to be synchronized from a source virtual machine to a destination virtual machine to ensure memory consistency between the source virtual machine and the destination virtual machine.

[0029] An intelligent memory module, a host system having the intelligent memory module, and an operation method according to some example embodiments of the present invention can minimize (e.g., reduce or shrink) host overhead by offloading live migration between devices that support point-to-point (P2P) communication (such as CML (Compute Express Link)) to the devices.

[0030] A host system according to some example embodiments of the present invention can be implemented with a hypervisor and virtual machines that support live migration. The hypervisor and virtual machines are technologies for efficiently using hardware resources and capable of running multiple operating systems on a single physical server. The hypervisor is software or firmware that manages and controls hardware virtualization, mainly allocating hardware resources such as a CPU (Central Processing Unit), memory, storage devices, networks, etc. to virtual machines. In addition, a virtual machine runs an operating system independently. A bare-metal hypervisor runs directly on the hardware without an operating system of a host system, such as VMWARE MICROSOFT etc. A Hosted Hypervisor runs on top of and in parallel with a host operating system, such as ORACLE VMWARE etc.

[0031] A virtual machine is a virtual environment that runs on top of a hypervisor. Just like running its own operating system and applications, multiple virtual machines can run independently on a single physical server. This environment can improve the efficiency of server computing resources. Virtual machines can host various operating systems. For example, running a virtual machine on an operating system and vice versa.

[0032] In summary, a hypervisor is software or firmware that manages hardware virtualization, and a virtual machine is a virtual environment that runs on the hypervisor and can run various operating systems and applications. This virtualization technology can improve resource utilization and management efficiency, and simplify system management and maintenance.

[0033] In addition, the host system according to some example embodiments of the present invention can perform device-driven migration via a P2P protocol to reduce the overhead of host software (such as a hypervisor). Since device-to-device transmission can be performed through the P2P protocol, it can also apply live migration to memory I / O (load / store) and storage device I / O (read / write). The host system can support transmission optimization through an internal buffer.

[0034] Figure 1 is a diagram showing a host system 1 according to some example embodiments of the inventive concept. Referring to Figure 1 , the host system 1 may include a source server 11, a destination server 12, a source device 13, a destination device 14, a network architecture 15, and an architecture manager 16.

[0035] The source device 13 and the destination device 14 may be implemented to be directly connected to the source server 11 and the destination server 12 to support live migration. Here, the direct connection can apply a hardware acceleration technology similar to single Root I / O virtualization (SR-IOV) to a virtual machine (VM). The hypervisor of the host device may request migration-related operations on the device. However, the I / O occurring in the VM may not be monitored and verified. In this case, for live migration operations between hypervisors, a connection can be performed through an architecture switch (such as CXL version 3) to achieve P2P transmission between devices.

[0036] The network architecture 15 can be implemented as a network architecture with high performance, availability, and scalability. The network architecture 15 can include architecture switches (core switches, edge switches, etc.), routers, gateways, load balancers, firewalls, etc. The network architecture 15 can implement a direct connection between the source device 13 and the destination device 14.

[0037] The architecture manager 16 can be implemented to control the network architecture 15 by using an attaching / detaching method of device connection for P2P transmission. The architecture manager 16 can centrally manage the configuration of network devices (switches, routers, firewalls, etc.) and components (virtual machines, storage devices, etc.), enabling network administrators to effectively change and update network configurations. The architecture manager 16 can monitor the network status in real time and collect performance data, enabling network problems to be quickly detected and resolved. In addition, network efficiency can be improved by analyzing traffic patterns and log data. The architecture manager 16 can manage and monitor network security policies to identify security events and take countermeasures. The architecture manager 16 can generate notifications about network events and faults and provide the notifications to the manager to enable a quick response in case of a failure. The architecture manager 16 can provide a function for automating and coordinating network tasks, simplifying network management and operations and improving efficiency. The architecture manager 16 can play an important role in improving network reliability, availability, security, and the performance of efficiently managing and maintaining complex network infrastructure.

[0038] The host system 1 according to the inventive concept can perform device driver live migration by using the P2P communication function to divert the migration operation.

[0039] Both the source device 13 and the destination device 14 according to the inventive concept can be implemented as intelligent memory modules that support P2P communication between devices. Here, the intelligent memory module can be implemented as a storage device or a storage component.

[0040] Figure 2A FIG. is a diagram showing an intelligent memory module 100 according to some example embodiments of the inventive concept. Refer to Figure 2A , the intelligent memory module 100 can include at least one volatile storage device 110 (DRAM) connected to at least one channel Dch, a memory controller 120, and a host interface circuit 130.

[0041] The at least one volatile storage device 110 can be implemented as a static random access memory (SRAM), a dynamic RAM (DRAM), or a synchronous RAM (SDRAM).

[0042] The memory controller 120 may be implemented to control at least one volatile storage device 110. The memory controller 120 may include normal input / output (IO) control logic 121, migration control logic 122, a migrated least recently used (LRU) buffer cache 123, and an LRU buffer control policy 124.

[0043] The normal input / output control logic 121 may be implemented to process VM load / store instructions (64B memory IO) requested through the host interface circuit 130. That is, the IO processing of the storage device (DRAM) may be performed through the normal input / output control logic 121. The migration control logic 122 may be implemented to control the migration operations requested by the hypervisor. The migrated LRU buffer cache 123 may be implemented to store data according to the LRU buffer policy so as to minimize (e.g., reduce or mitigate) the frequent bus occupancy that occurs when the storage requests requested by the VM during the migration operation are directly transmitted to the destination device. The LRU buffer control policy 124 may be implemented to control the migration of the LRU buffer cache 123 to handle LRU and similar LRU-based buffering policies. In some example embodiments, there may be a migrated LRU buffer cache 123 that can buffer and store the normal IO of the user according to the LRU buffer control policy. The LRU buffer control policy 124 may be implemented in a manner of hardware, software, or firmware.

[0044] The host interface circuit 130 may be connected to the hypervisors of the host device and the destination device and may thus be implemented to perform communication. In some example embodiments, the host interface circuit 130 may be implemented as a P2P interface, such as a CXL interface.

[0045] Figure 2B is a diagram showing an intelligent memory module 200 according to some example embodiments of the inventive concept. Refer to Figure 2B , the intelligent memory module 200 may include at least one non-volatile storage device 210 (NVM) connected to at least one channel Dch, a storage controller 220, and a host interface circuit 230.

[0046] The at least one non-volatile storage device 210 may be implemented as NAND flash, NOR flash, phase change RAM (PRAM), magnetoresistive RAM (MRAM), resistive RAM (ReRAM), ferroelectric RAM (FRAM), etc.

[0047] The storage controller 220 may include normal input / output (IO) control logic 221, migration control logic 222, a migrated LRU buffer cache 223, and an LRU buffer control policy 224.

[0048] The normal input / output control logic 221 can be implemented to handle read / write (storage device I / O) requests of the VMs requested through the host interface circuit 230. That is, I / O processing of the non-volatile memory device (NVM) can be performed through the normal input / output control logic 221. The migration control logic 222 can be implemented to control the migration operations requested by the hypervisor. The migration LRU buffer cache 223 can be implemented to store data according to the LRU buffer policy to minimize (e.g., reduce or shrink) the frequent bus occupancy that occurs when storage requests requested by the VMs during the migration operation are directly transmitted to the destination device. The LRU buffer control policy 224 can be implemented to control the migration of the LRU buffer cache 223 to handle LRU and similar LRU-based buffering policies.

[0049] The host interface circuit 230 can be connected to the hypervisors of the host device and the destination device and can thus be implemented to perform communication. In some example embodiments, the host interface circuit 230 can be implemented as a P2P interface, such as a CXL interface.

[0050] Figure 3 is a diagram showing live migration of a general host system. Refer to Figure 3 , the device DEV may have two dirty tables based on the double buffering concept. The host can find the dirty blocks through the frozen dirty table and can perform copying (S1). However, the host may not know the information updated by the client VM. Therefore, a dirty update request (S3) can be made in response to a request from the client VM (S2). Such update information can be recorded in the active dirty table (S4). That is, in this case, such a process can be repeatedly executed until the active dirty table is 0 or below a certain threshold. In an I / O-centric workload environment, the migration may not terminate. At the same time, the migration agent operation may consume CPU resources.

[0051] Figure 4 is a diagram showing the live migration operation of the host system 1 according to some example embodiments of the inventive concept. Refer to Figure 4 , the smart device (or Figure 2A and Figure 2B the smart memory module in) may have a migration window for managing live migration. Here, the migration window can be a boundary line that separates the migrated area and the non-migrated area from each other. Here, the migrated area is an area managed in a dirty state during the update, while the non-migrated area is an area where there are no data consistency issues even during the update. The migration window can be a baseline for changing the method of processing I / O operations when an input / output operation (IO) occurs in the VM.

[0052] Generally, the areas outside the migration window are not yet complete, and thus operations can be performed by applying the host's IO operations to the local device without any changes. In the areas within the migration window, the original data has already been transferred to the destination, and thus a notification can be sent to the remote device. In this case, in the case of simple bypass, due to frequent communication between devices, bus and device overhead may occur. In the case of bypassing to the remote device without recording on the local device, it may be necessary to incur overhead from the remote device during a read operation. Therefore, the following operations may be required. An LRU-type buffer that manages all write operations through cache write operations can be used. By buffering frequently accessed write operations through such an LRU buffer cache, the bus overhead can be minimized (e.g., reduced or shrunk).

[0053] Regardless of such buffering operations, when the buffer is full, the same update can be performed on the local device. During a read operation, an operation that minimizes (e.g., reduces or shrinks) the waiting time can be performed by operating the local device.

[0054] Figure 5 is a flowchart showing the device driver real-time migration operation of the host system 1 according to some example embodiments of the inventive concept. Refer to Figures 1 to 5 , the device driver real-time migration operation can be performed as follows.

[0055] The client virtual machine can issue a write request corresponding to the real-time migration operation and can send the write request to the intelligent migration device ( Figure 2A and Figure 2B the intelligent memory module in). The intelligent migration device can receive the write request and can check the migration window (S20). When the migration window indicates a completed area, it can be determined whether the LRU buffer cache is full (S30). When the LRU buffer cache is full, the data that has not been accessed for the longest time (e.g., the least updated data) can be sent to the target device (S35). On the contrary, when the LRU buffer cache is not full, the LRU buffer cache can be updated to include the data corresponding to the write request (S40). In operation S20, the migration window can indicate an incomplete area, or the data can be written to the source device after operation S40 (S50). After that, the client virtual machine can receive a response message from the intelligent migration device indicating that the write operation corresponding to the write request has been completed (S60).

[0056] Figure 6 is a flowchart showing the device driver real-time migration operation of the host system 1 according to some example embodiments of the inventive concept. Refer to Figures 1 to 6, the device driver live migration operation can be performed as follows.

[0057] The host device (source server) can perform a live migration software operation (S110). Initialization operations related to live migration can be performed (S120). The intelligent device can activate the live migration function according to the initialization operation request related to live migration (S120). For example, the intelligent device (or intelligent memory module) can perform buffer / copy window initialization operations (S121).

[0058] After that, the host device can send the destination device address to the intelligent device (S130). The intelligent device can receive the destination device address and can initialize the connection related to the destination device (S131).

[0059] After that, the host device can issue a live migration request and send a live migration request to the intelligent device (S140). The intelligent device can receive the intelligent migration request and can start the migration loop (S141). After that, the migration loop operation can be performed (S142). The migration loop operation can be performed as follows. The intelligent device can read the Nth block of data corresponding to the current loop and can send the read block data to the destination device through P2P communication (S143). After sending the block data, the migration window can be moved or extended (S144). After that, it can be determined whether the migration window is the last (S145). When the migration window is not the last migration window, operation S143 can be performed to execute the next loop.

[0060] The host device can perform migration operations other than device replication (S150). After that, the host device can stop the virtual machine related to live migration (S160). In addition, when the migration window is the last in operation S145, operation S160 can be performed. After that, the intelligent device can flush the device buffer (S161). After that, the host device can copy the last context of the host virtual machine (S170).

[0061] Figure 7 is a diagram showing the initialization operation of the device driver migration operation of the host system 1 according to some example embodiments of the inventive concept. Refer to Figure 7 , the host device can request the connection configuration and initialization operation of the target device through the architecture manager 16 (see Figure 1 ). The intelligent device can initialize the logic required for live migration based on the information received from the host device (see Figure 6 S120 and S130 in). For example, the intelligent device can check the migration window and the LRU buffer cache. Figure 6 S121 and S131 in).

[0062] Figure 8 FIG. is a diagram illustrating a migration operation of device driver migration from the perspective of a migration controller in a host system 1 according to some example embodiments of the inventive concept. Refer to Figure 8 , the migration operation may be performed as follows. The migration control logic of the intelligent device may copy the actually stored data from the source device to the destination device while extending the migration window. The migration may be completed at the time point when the migration area reaches 100%.

[0063] Figure 9 FIG. is a diagram illustrating a device driver migration operation from the perspective of VM IO in a host system 1 according to some example embodiments of the inventive concept. Refer to Figure 9 , during live migration, the following operations may be performed on the IO generated in the VM (see Figure 5 S10 to S60 in Figure 6 and S142 in

[0064] Figure 10 FIG. is a diagram illustrating buffer flushing of a host system 1 according to some example embodiments of the inventive concept. Refer to Figure 10 , after the migration is completed, a flushing process operation may be performed on the LRU buffer cache generated in the VM during live migration (see Figure 6 S161 in

[0065] Figure 11 FIG. is a flowchart illustrating a live migration operation of an intelligent device according to some example embodiments of the inventive concept. Refer to Figures 1 to 11 , the intelligent device (or intelligent memory module) may perform a live migration operation as follows. The intelligent device may perform an initialization operation of live migration (S210). For example, the intelligent device may set and check the buffer / migration window. After that, the intelligent device may receive a live migration request from the host device (S220). The intelligent device may perform a live migration operation (S230). After that, the intelligent device may perform buffer flushing (S240).

[0066] In some example embodiments, a write request may be received from a host device. In response to the write request, a migration window may be checked. When the migration window indicates a migration area, it may be determined whether the LRU buffer cache is full. When the LRU buffer cache is not full, the LRU buffer cache may be updated to include data corresponding to the write request. In some example embodiments, when the LRU buffer cache is full, the earliest data (or cold data) among a plurality of data stored in the LRU buffer cache may be sent to a target device, and then the LRU buffer cache may be updated to include data corresponding to the write request. In some example embodiments, after the migration window indicates an area that has not been migrated or the LRU buffer cache has been updated, the data corresponding to the write request may be written to a source device. In some example embodiments, after the data is written to the source device, information about the completion of the write request may be output to the host device.

[0067] A host system according to the inventive concept may be implemented as various types of memory / storage devices.

[0068] Figure 12A is an example diagram showing a host system 2 according to some example embodiments of the inventive concept. Refer to Figure 12A , the host system 2 may include a processor (CPU / RC) 21, at least one memory module (DDR) 22, and an accelerator 23. The processor 21 and the accelerator 23 may perform communication through interfaces such as CXLio and CXLcache. Figure 12B is a diagram showing a host system 2a according to some example embodiments of the inventive concept. Refer to Figure 12B , the host system 2a may include a processor 21a, at least one memory module 22a, an accelerator 23a, and at least one high bandwidth memory (HBM) 24. The processor 21a and the accelerator 23a may perform communication through interfaces such as CXLio, CXLmem, and CXLcache. Figure 12C is a diagram showing a host system 2b according to some example embodiments of the inventive concept. Refer to Figure 12C , the host system 2b may include a processor 21b, at least one memory module 22b, a memory expander 25, at least one memory module (DDR) 26, and at least one non-volatile storage device (SCM) 27. The processor 21b and the memory expander 23b may perform communication through interfaces such as CXLio and CXLmem. As Figure 12A , Figure 12B and Figure 12C shown, the current target may be a storage-based NVMe device involved in a live migration operation. As Figure 12AAs shown, the current target can be classified as a Type 1 Device. As Figure 12B shown, when using an accelerator, the current target can be set as a Type 2 Device.

[0069] According to the inventive concept, inter-system live migration can be extended through the CXL architecture 35 to handle live migration operations. Figure 13 is a diagram showing inter-system live migration of the host system 3 according to some example embodiments of the inventive concept. Refer to Figure 13 , the host system 3 may include a CXL architecture 35 and an architecture manager (FM) 36 that connect a first host system, a second host system, and a GFD to each other. The host system 3 may perform live migration between the first host system and the second host system. As Figure 13 shown, a live migration operation from the first virtual machine (VM1) 31-1 of the first host device 31 to the first virtual machine (VM1) 32-1 of the second host device 32 may be performed.

[0070] The inventive concept may be applicable to a multi-head device (MHD). Figure 14 is a diagram showing inter-system live migration of the host system 4 according to some example embodiments of the inventive concept. Refer to Figure 14 , the host system 4 may include a CXL architecture 45 and an architecture manager 46 that connect a first host system, a second host system, and MHDs 43 and 44 to each other. As Figure 14 shown, a live migration operation from the first virtual machine (VM1) 41-1 of the first host device 41 to the first virtual machine (VM1) 42-1 of the second host device 42 may be performed. NVMe and PCIe devices may provide multiple physical endpoints respectively through SR-IOV related functions. One MHD may support multiple physical endpoints. Using this technology, live migration can be supported in the same way. This technology can be used in VM-based clouds and data centers using CXL. A non-stop system can be established within the data center. After establishment, currently only live migration through a shared storage pool can be supported. However, when using the inventive concept, not only NVMe devices but also a large-capacity DRAM can be provided through a virtualized environment. When the inventive concept is used for a hypervisor that manages a virtualized environment, a virtualized environment capable of minimizing (e.g., reducing or shrinking) the CPU resources consumed by the host for live migration can be provided.

[0071] Figure 15 is a diagram showing the computing system 1000 according to some example embodiments of the inventive concept. Refer to Figure 15, the computing system 1000 may include a first CPU 1110, a second CPU 1120, a GPU 1130, an NPU 1140, a CXL switch SW_CXL, a CXL storage device 1210 and a CXL storage device 1220, a PCIe device 1310, and an accelerator (CXL device) 1320.

[0072] The first CPU 1110, the second CPU 1120, the GPU 1130, the NPU 1140, the CXL storage device 1210, the CXL storage device 1220, the PCIe device 1310, and the accelerator (CXL device) 1320 may be commonly connected to the CXL switch SW_CXL and may communicate with each other through the CXL switch SW_CXL. In some example embodiments, the first CPU 1110, the second CPU 1120, the GPU 1130, and the NPU 1140 may each be a host as described in Figures 1 to 14 the reference, and the first CPU 1110, the second CPU 1120, the GPU 1130, and the NPU 1140 may be directly connected to a single storage device, respectively. At least a portion of the area of the CXL storage device 1220 may be allocated as a dedicated area of the CXL storage device 1210 by one or more of the first CPU 1110, the second CPU 1120, the GPU 1130, and the NPU 1140. That is, the CXL storage device 1210 and the CXL storage device 1220 may be used as the storage space STR of the computing system 1000. In addition, the CXL storage device 1210 and the CXL storage device 1220 may be implemented to perform device driver live migration in response to a live migration request from a host device, as described in Figures 1 to 14 that.

[0073] In some example embodiments, the CXL switch SW_CXL may be connected to a PCIe device 1310 or an accelerator 1320 configured to support various functions, and the PCIe device 1310 or the accelerator 1320 may communicate with each of the first CPU 1110, the second CPU 1120, the GPU 1130, and the NPU 1140 through the CXL switch SW_CXL, or may access the storage space STR including the CXL storage device 1210 and the CXL storage device 1220. In some example embodiments, the CXL switch SW_CXL may be connected to an external network or architecture and may be configured to communicate with an external server through the external network or architecture.

[0074] Figure 16 is a diagram showing a data center of a computing system to which some example embodiments according to the inventive concept are applied. Refer to Figure 16, the data center 2000 can be a facility that collects various types of data and provides services, and can also be referred to as a data storage center. The data center 2000 can be a system for operating a search engine and a database, and can be a computing system used in companies such as banks or government agencies. The data center 2000 can include application servers 2110 to 21m0 and storage servers 2210 to 22n0. In some example embodiments, the number of application servers and the number of storage servers can be selected in various ways, and the number of application servers and the number of storage servers can be different from each other. Hereinafter, the configuration of the first storage server 2210 will be mainly described. The application servers 2110 to 21m0 and the storage servers 2210 to 22n0 can have a similar structure, and the application servers 2110 to 21m0 and the storage servers 2210 to 22n0 can communicate with each other through the network NT.

[0075] The first storage server 2210 can include a processor 2211, a memory 2212, a switch 2213, a storage device 2215, a CXL memory 2214, and a network interface card (NIC) 2216. The processor 2211 can control the overall operation of the first storage server 2210, and can access the memory 2212 to execute commands loaded into the memory 2212 or process data. The memory 2212 can be a double data rate synchronous DRAM (DDR SDRAM), a high bandwidth memory (HBM), a hybrid memory cube (HMC), a dual in-line memory module (DIMM), an Optane DIMM, or a non-volatile DIMM (NVDIMM). The processor 2211 and the memory 2212 can be directly connected to each other, and the number of the processor 2211 and the memory 2212 included in one storage server 2210 can be selected in various ways.

[0076] In some example embodiments, the processor 2211 and the memory 2212 can provide a processor-memory pair. In some example embodiments, the number of the processor 2211 and the number of the memory 2212 can be different. The processor 2211 can include a single-core processor or a multi-core processor. The above description of the storage server 2210 also applies to each of the application servers 2110 to 21m0.

[0077] Switch 2213 can be configured to adjust or route communications between various components included in the first storage server 2210. In some example embodiments, switch 2213 can be a switch implemented based on the CXL protocol. CXL memory 2214 can be connected to switch 2213. In some example embodiments, CXL memory 2214 can be used as a memory expander for processor 2211. Alternatively, CXL memory 2214 can be allocated as dedicated memory or buffer memory for storage device 2215. Storage device 2215 can include a CXL interface circuit CXL_IF, a controller CTRL, and a NAND flash NAND. Storage device 2215 can store data according to a request from processor 2211 or output the stored data. In some example embodiments, storage device 2215 can be a CXL storage device. In some example embodiments, storage device 2215 can allocate at least a portion of the area of CXL memory 2214 as a dedicated area and can use the dedicated area as buffer memory (i.e., mapped data is stored in CXL memory 2214).

[0078] In some example embodiments, application servers 2110 to 21m0 may not include storage device 2215. Storage server 2210 can include at least one storage device 2215. In some example embodiments, the number of storage devices 2215 included in storage server 2210 can be selected in various ways.

[0079] Network interface card (NIC) 2216 can be connected to CXL switch SW_CXL. NIC 2216 can communicate with other storage servers 2220 to 22n0 or other application servers 2110 to 21m0 through network NT. In some example embodiments, NIC 2216 can include a network interface card, a network adapter, etc. NIC 2216 can be connected to network NT through a wired interface, a wireless interface, a Bluetooth interface, an optical interface, etc. NIC 2216 can include internal memory, a digital signal processor (DSP), a host bus interface, etc., and can be connected to processor 2211 or switch 2213 through the host bus interface. In some example embodiments, NIC 2216 can be integrated with at least one of processor 2211, switch 2213, and storage device 2215.

[0080] In some example embodiments, the network NT may be implemented using Fibre Channel (FC) or Ethernet. In this case, the FC may be a medium for relatively high-speed data transmission, and an optical switch that provides high performance and high availability may be used. Depending on the access method of the network NT, the storage server may be provided as a file storage device, a block storage device, or an object storage device. In some example embodiments, the network NT may be a dedicated storage network such as a Storage Area Network (SAN). For example, the SAN may be an FC-SAN that uses an FC network and is implemented according to the FC Protocol (FCP). As another example, the SAN may be an IP-SAN that uses a TCP / IP network and is implemented according to the SCSI over TCP / IP or Internet SCSI (iSCSI) protocol. In some example embodiments, the network NT may be a general network such as a TCP / IP network. For example, the network NT may be implemented according to protocols such as Fibre Channel over Ethernet (FCoE), Network Attached Storage (NAS), NVMe over fabrics (NVMe-oF), etc.

[0081] In some example embodiments, at least one of the application servers 2110 to 21m0 can store data stored by a user or client request in one of the storage servers 2210 to 22n0 via the network NT. At least one of the application servers 2110 to 21m0 can obtain data read by a user or client request from one of the storage servers 2210 to 22n0 via the network NT. For example, at least one of the application servers 2110 to 21m0 can be implemented as a web server or a database management system (DBMS). In some example embodiments, at least one of the application servers 2110 to 21m0 can access a memory, a CXL memory, or a storage device included in another application server via the network NT, or can access a memory, a CXL memory, or a storage device included in the storage servers 2210 to 22n0 via the network NT. Accordingly, at least one of the application servers 2110 to 21m0 can perform various operations on data stored in other application servers or storage servers. For example, at least one of the application servers 2110 to 21m0 can execute an instruction for moving or copying data between other application servers or storage servers. In this case, the data can be moved from the storage device of the storage server to the memory or CXL memory of the application server through the memory or CXL memory of the storage server, or can be directly moved from the storage device of the storage server to the memory or CXL memory of the application server. The data moved through the network can be encrypted data for security or privacy reasons.

[0082] In some example embodiments, regarding the storage device included in at least one of the application servers 2110 to 21m0 and the storage servers 2210 to 22n0, the CXL memory included in at least one of the application servers 2110 to 21m0 and the storage servers 2210 to 22n0 can be allocated as a dedicated area, and the storage device can use the allocated dedicated area as a buffer memory, that is, can store mapping data. For example, regarding the storage device 2215 included in the storage server 2210, the CXL memory included in another storage server (e.g., 22n0) can be allocated, and the storage device 2215 can access the CXL memory included in another storage server (e.g., 22n0) through the switch 2213 and the NIC 2216. In this case, the mapping data of the storage device 2215 of the first storage server 2210 can be stored in the CXL memory of another storage server 22n0. That is, according to the inventive concept, the storage device and the CXL memory of the data center can be connected to each other and implemented in various ways.

[0083] In addition, terms such as first, second, third, etc. may be used herein to describe components according to the inventive concept. These terms are only used to distinguish the corresponding components from other components, but do not limit the inventive concept. For example, terms such as first, second, third, etc. do not imply order or any form of numerical meaning. Components of exemplary embodiments according to the inventive concept have been referred to using the above blocks. These blocks may be implemented as various hardware devices, such as integrated circuits (ICs), application-specific ICs (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), firmware running on hardware devices, software (such as applications), or combinations of hardware devices and software. In addition, the blocks may include circuits having semiconductor devices in an IC or circuits registered as intellectual property (IP).

[0084] The above-described device can be implemented as a hardware component, a software component, and / or a combination of a hardware component and a software component. As described herein, any electronic device and / or a part thereof according to any example embodiment may include one or more instances of a processing circuit such as the following, may be included in one or more instances of a processing circuit such as the following, and / or may be implemented by one or more instances of a processing circuit such as the following: hardware including logic circuits; a hardware / software combination such as a processor that executes software; or any combination thereof. For example, the devices and components according to example embodiments may be implemented using one or more general-purpose or special-purpose computers, such as a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. For example, the processing circuit may more specifically include, but is not limited to, a central processing unit (CPU), an arithmetic logic unit (ALU), a graphics processing unit (GPU), an application processor (AP), a digital signal processor (DSP), a microcomputer, a field programmable gate array (FPGA), a programmable logic unit, a microprocessor, an application specific integrated circuit (ASIC), a neural network processing unit (NPU), an electronic control unit (ECU), an image signal processor (ISP), etc. In some example embodiments, the processing circuit may include a non-transitory computer-readable storage device (e.g., a memory) that stores an instruction program, such as a DRAM device, and a processor (e.g., a CPU) configured to execute the instruction program to implement the functions and / or methods performed by some or all of any device, system, module, unit, controller, circuit, architecture, and / or a part thereof according to an example embodiment and / or any part thereof. The processing device may include an operating system (OS) and one or more software applications executed on the operating system. In addition, the processing device may also access, store, manipulate, process, and generate data in response to the execution of software. For ease of understanding, in some cases, the processing device is described as being used as a single processing element, but those skilled in the art may recognize that the processing device may include multiple processing elements or multiple types of processing elements. For example, the processing device may include multiple processors, or one processor and one controller. In addition, other processing configurations, such as parallel processors, may also be employed.

[0085] Software may include a computer program, code, instructions, or one or more combinations thereof, and may configure a processing device to operate as required, or may independently or jointly direct the processing device. The software and / or data may be contained in any type of machine, component, physical device, virtual device, computer storage medium, or device for interpretation by, or to provide instructions or data to, the processing device. The software may also be distributed over computer systems via a network and may be stored or executed in a distributed manner. The software and data may be stored on one or more computer-readable recording media.

[0086] In the art according to the prior art, an agent of a host system performing live migration may directly access a device and operate by reading data. However, in this case, if a write operation is processed by an application in a VM during a live migration operation, the live migration agent may not check the operation and may thus require a data structure (such as a dirty map) supported by the device. The agent may directly execute the migration using the host's CPU until the dirty map becomes empty. When creating an interface and an application environment such as CXL 3.0, a single device may operate in the same manner as an intelligent device. Thus, a migration operation that needs to be directly processed by the host CPU may be diverted to the device, thereby minimizing (e.g., reducing or alleviating) unnecessary operations and data structures for communication between the host and the device.

[0087] Generally, in a virtualization-based cloud, live migration technology may be widely used, in which a virtual machine instance is moved to another physical server at runtime to ensure system stability and uniform distribution of performance. In a system according to the related art, during live migration, it may be difficult to move data between systems with respect to independent storage devices and equivalent storage devices, and thus, during live migration, only a pool of storage devices and a pool of memories separated by a network may be used to change connection information. This method may be difficult to support high performance. In addition, data may be directly sent to the host through vendor commands using SR-IOV or similar technologies, but the host overhead may be high. The live migration method according to the related art may require managing the dirty state of the device for the dirty map of live migration. The migration manager of the host may need to read the dirty map and directly copy the dirty pages.

[0088] According to some example embodiments of the inventive concept, a live migration method may divert a migration operation to a device that performs migration using a P2P communication function, and may be implemented as a P2P-based live migration technology between a storage device on a high-speed system bus and an intelligent memory module that supports the storage device. The intelligent memory module may include a memory controller, and may internally include a normal IO control logic, a migration control controller, a migration LRU buffer cache, and an LRU buffer control policy. The storage device may be connected to the system through a host interface logic, and may perform P2P communication with the same type of storage device through the host system. The device may include a RAM and a flash memory chip, and may be used as a storage device or a storage apparatus.

[0089] The migration controller may support the following operations. The migration controller may perform migration through 1 read operation using a migration window. When an IO occurs in a migration area, the migration controller may buffer it inside the device through the LRU buffer cache, and may process the migration operation of cold data (the earliest data) to the target device when the buffer is full.

[0090] An intelligent memory module, a host system including the intelligent memory module, and a method of operating the intelligent memory module according to some example embodiments of the inventive concept may support device-to-device communication through a peer-to-peer (P2P) connection.

[0091] An intelligent memory module, a host system including the intelligent memory module, and a method of operating the intelligent memory module according to some example embodiments of the inventive concept may support diversion of live migration to enable replication to a remote memory through a network interface card (NIC), thereby performing fast live migration.

[0092] An intelligent memory module, a host system including the intelligent memory module, and a method of operating the intelligent memory module according to some example embodiments of the inventive concept may minimize (e.g., reduce or scale down) the amount of system resources used, and may significantly increase the relevant processing speed by diverting live migration operations. For example, according to some example embodiments, the processing power, speed, accuracy, lifespan, and / or power efficiency of a host system based on the above method may be improved. Accordingly, the improved device and method overcome the drawbacks of conventional devices and methods for managing data, particularly those related to live migration, etc., while reducing resource consumption (e.g., processing power, power), increasing data accuracy, and improving resource allocation (e.g., latency). For example, according to some example embodiments, by supporting P2P connection, the host system may perform fewer operations, reduce power consumption, and increase lifespan, while providing more consistent data access. In addition, by providing the functions disclosed herein, communication and reliability in the device are improved.

[0093] An intelligent memory module, a host system including the intelligent memory module, and a method of operating the intelligent memory module according to some example embodiments of the inventive concept may divert dirty block management that occurs during a live migration operation, thereby improving the process of the live migration operation.

[0094] Although example embodiments have been shown and described above, it will be apparent to those skilled in the art that modifications and variations can be made without departing from the scope of the inventive concept defined by the appended claims.

Claims

1. A smart memory module, the smart memory module comprising: at least one storage device connected to at least one channel; a controller configured to control the at least one storage device; and a host interface circuit configured to perform P2P communication with an external device and receive a live migration request from a host device, wherein the P2P communication is point-to-point communication, The controller is configured to, in response to the live migration request, perform a migration operation of sending buffered data to a target device through the P2P communication if the buffer is full.

2. The smart memory module according to claim 1, wherein: The controller comprises: migration control logic configured to control the migration operation; and An LRU buffer cache is configured to store data related to the migration operation, the LRU buffer cache being a least recently used buffer cache.

3. The smart memory module according to claim 2, wherein: The migration control logic is configured to check a migration window that separates the migrated regions and the not-yet-migrated regions from each other.

4. The smart memory module according to claim 3, wherein: The migrated region is a region that is managed in a dirty state during an update, and The unmigrated area is an area that has no problem in data consistency even after the update.

5. The smart memory module according to claim 3, wherein: The LRU buffer cache is buffered in response to input / output occurring in the migrated region.

6. The smart memory module according to claim 3, wherein: The LRU buffer cache is configured to send the oldest data to the target device if the buffer is full.

7. The smart memory module according to claim 1, wherein: The host device is configured to request connection configuration and initialization operations of the target device through the fabric manager, and The initialization operation for the live migration is performed according to a request of the host device.

8. The smart memory module according to claim 1, wherein: The controller is configured to perform a flush operation on an LRU buffer cache generated in the virtual machine after the migration operation is completed.

9. The smart memory module according to claim 8, wherein: The flushing operation is performed after the virtual machine is stopped.

10. The smart memory module of claim 1, wherein: The memory device includes a volatile memory device or a nonvolatile memory device, and The P2P communication includes a CXL interface, which is a Computer Express Link interface.

11. A method of operating a smart memory module, the method comprising: performing initialization operations for live migration from a host device; receiving a live migration request from the host device; as well as In response to the live migration request, performing a migration operation using an LRU buffer cache, the LRU buffer cache being a least recently used buffer cache, In response to the LRU buffer cache being full, the migration operation flushes the data stored in the LRU buffer cache to the target device through P2P communication, where the P2P communication is point-to-point communication.

12. The method according to claim 11, wherein: Executing the migration operation includes: receiving a write request from the host device; checking a migration window in response to the write request; In response to the migration window indicating a migrated region, determining whether the LRU buffer cache is full; and In response to the LRU buffer cache being not full, the LRU buffer cache is updated to include data corresponding to the write request.

13. The method according to claim 12, wherein: Executing the migration operation further includes: In response to the LRU buffer cache being full, sending the oldest data among the data stored in the LRU buffer cache to the target device; and After the oldest data is sent to the target device, the LRU buffer cache is updated to include the data corresponding to the write request.

14. The method according to claim 13, wherein: Executing the migration operation further includes: The data corresponding to the write request is written to a source device after the migration window indicates that a region has not been migrated or the LRU buffer cache is updated.

15. The method according to claim 14, further comprising: After the data is written to the source device, information on completion of the write request is output to the host device.

16. A method of operating a smart memory module, the method comprising: receiving a live migration request from a host device; In response to the live migration request, starting a migration cycle; Sending the block data corresponding to the migration cycle to the destination device through P2P communication, wherein the P2P communication is point-to-point communication; moving a migration window to the destination device according to the sending of the block data, the migration window separating a migrated area and a not-yet-migrated area from each other; In response to the migration window not being the last migration window, executing a next migration cycle; as well as In response to the migration window being the last migration window, data stored in an LRU buffer cache, ie, a least recently used buffer cache, is flushed to the destination device through the P2P communication.

17. The method according to claim 16, further comprising: receiving an initialization request for live migration from the host device; as well as In response to the initialization request, a live migration function is activated for the LRU buffer cache and the migration window.

18. The method according to claim 16, further comprising: receiving an address of the destination device from the host device; as well as In response to the address of the destination device, a P2P connection associated with the destination device is initialized, the P2P connection being a point-to-point connection.

19. The method according to claim 16, wherein: In response to occurrence of a write request to the migrated area, data corresponding to the write request is sent to the LRU buffer cache.

20. The method according to claim 16, wherein: The flushing is performed after the virtual machine of the host device is stopped.

Images