Heterogeneous memory management systems, methods, and media

Abstract

The application provides a heterogeneous memory management system, method and medium, the system comprises an acceleration layer and a persistent layer; the acceleration layer comprises a first physical memory and a second physical memory, the persistent layer comprises a third physical memory, the first physical memory, the second physical memory and the third physical memory are heterogeneous memories; the system allocates a unified page table for a target file in the persistent layer, and the unified page table is used to establish a mapping relationship between a file logical address and the heterogeneous memories; the system distinguishes hot data and cold data according to the access frequency of file data, and periodically stores the hot data to the acceleration layer, and expels the cold data from the acceleration layer to merge to the persistent layer. The application can manage the heterogeneous memories as unified first-class resources through the collaborative design of the file system and the virtual memory, reduce unnecessary data copying and migration, and realize the overall optimization of performance, capacity and persistence.

Description

Technical Field

[0001] This application relates to the field of storage technology, and in particular to a heterogeneous memory management system, method and medium. Background Technology

[0002] With the rapid development of data-intensive applications such as artificial intelligence, machine learning, and big data analytics, the demand for memory capacity, bandwidth, and access efficiency continues to grow. Traditional memory systems based on DRAM (Dynamic Random Access Memory) are gradually becoming bottlenecks in terms of capacity scalability and cost, making it difficult to support the ever-expanding scale of data. To alleviate this problem, computing platforms have begun to introduce various new memory and interconnect technologies, forming a heterogeneous memory system composed of DRAM, new scalable memory, and persistent memory.

[0003] In this heterogeneous memory environment, different memory media exhibit significant differences in access latency, bandwidth, persistence, and durability. Existing research indicates that managing various memory resources separately can easily lead to low resource utilization and limited system performance. Therefore, how to manage heterogeneous memory in a unified manner is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] This application provides a heterogeneous memory management system, method, and medium to solve the technical problem of how to uniformly manage heterogeneous memory.

[0005] The first aspect of this application provides a heterogeneous memory management system, the system including an acceleration layer and a persistent layer; the acceleration layer is composed of a first physical memory and a second physical memory, the persistent layer is composed of a third physical memory, and the first physical memory, the second physical memory and the third physical memory are heterogeneous memory;

[0006] The system allocates a unified page table for the target file in the persistent layer. The unified page table is used to establish the mapping relationship between the file's logical address and the heterogeneous memory.

[0007] The system distinguishes between hot and cold data based on the access frequency of file data, and periodically stores hot data in the acceleration layer and evicts cold data from the acceleration layer to merge it into the persistent layer.

[0008] In one implementation of the first aspect, the unified page table includes multiple page table entries, each page table entry corresponds to a virtual page of a fixed size, and the multiple virtual pages correspond one-to-one with physical pages located in the first physical memory, the second physical memory, and / or physical page frames located in the third physical memory.

[0009] In one implementation of the first aspect, each physical page frame located in the acceleration layer has a corresponding shadow page, and the shadow page is located in the persistence layer;

[0010] The system periodically refreshes the dirty data marked in the physical page frame located in the acceleration layer to the corresponding shadow page, and locks the refreshed physical page frame during the refresh process.

[0011] In one implementation of the first aspect, the system further includes a general-purpose buffer;

[0012] The system is also configured to redirect new write requests to the general buffer when the dirty data is flushed to the shadow page; and to merge the accumulated data in the general buffer into the persistent layer in the next refresh cycle.

[0013] In one implementation of the first aspect, the system is further configured to assign a file identifier to the target file, the file identifier corresponding one-to-one with the unified page table.

[0014] In one implementation of the first aspect, the system further includes a file system interface; the file system interface is used to provide an interface to an application so that the application can access the heterogeneous memory management system through the file system interface.

[0015] In one implementation of the first aspect, the acceleration layer employs a pre-allocated memory pool with large page granularity and allocates and reclaims the first physical memory and / or the second physical memory through a bitmap management mechanism.

[0016] A second aspect of this application provides a heterogeneous memory management method, which is applied to a heterogeneous memory management system, the system including an acceleration layer and a persistent layer; the acceleration layer is composed of a first physical memory and a second physical memory, the persistent layer is composed of a third physical memory, and the first physical memory, the second physical memory and the third physical memory are heterogeneous memory;

[0017] Based on the allocation request, a unified page table is allocated for the target file in the persistent layer. The unified page table is used to establish the mapping relationship between the file's logical address and the heterogeneous memory.

[0018] Based on the write request, calculate the virtual page number corresponding to the write offset in the logical address of the file, and query whether there is a mapping relationship between the virtual page number and the heterogeneous memory through the unified page table;

[0019] If the mapping relationship does not exist, hot and cold data are distinguished according to the access frequency of file data, so that hot data is stored in the acceleration layer or cold data is stored in the persistent layer.

[0020] In one implementation of the second aspect, the method further includes:

[0021] The file identifier of the target file is determined based on the read request, and the corresponding unified page table is located according to the file identifier;

[0022] The physical page frame corresponding to the target file data is found through the unified page table. If the physical page frame is located in the acceleration layer, the target file data is returned directly from the acceleration layer. If the physical page frame address is located in the persistent layer, it is read directly through memory mapping.

[0023] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the functions of the system as described in any one of the first aspects or the methods as described in any one of the second aspects.

[0024] As described above, this application provides a heterogeneous memory management system, method, and medium, which have the following beneficial effects:

[0025] (1) This application eliminates the forced copy path in traditional heterogeneous memory systems by using a unified page table and direct memory access, which significantly reduces data copy and migration overhead, reduces access latency and improves throughput performance.

[0026] (2) This application realizes the unified management of heterogeneous memory, so that different memory media can be used as the main data storage location, which significantly improves the efficiency of memory resource utilization.

[0027] (3) This application can optimize performance, capacity and persistence at the same time through shadow pages and asynchronous refresh, decoupling performance optimization and persistence guarantee, so that the system can be stably expanded under high concurrency and big data scale.

[0028] (4) This application has good scalability for new memory devices. The unified page table abstraction can transparently integrate new memory devices, avoiding the need to redesign the storage and management mechanism for each type of hardware.

[0029] (5) This application provides a file system interface that provides near-memory-level access performance while maintaining the interface semantics. Applications can benefit from the performance advantages of heterogeneous memory without modification, and it has good practicality and promotion value. Attached Figure Description

[0030] Figure 1 The diagram shown is an architectural schematic of the heterogeneous memory management system provided in an embodiment of this application.

[0031] Figure 2 The diagram shown is a schematic representation of the architecture of the unified page table provided in an embodiment of this application.

[0032] Figure 3The diagram shows a data flow diagram of a heterogeneous memory management system provided in an embodiment of this application.

[0033] Figure 4 The diagram shown is an application illustration of the heterogeneous memory management system provided in the embodiments of this application.

[0034] Figure 5 The diagram shown is a flowchart of a heterogeneous memory management method in one embodiment of this application. Detailed Implementation

[0035] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be noted that, unless otherwise specified, the following embodiments and features in the embodiments can be combined with each other.

[0036] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0037] Furthermore, the use of terms such as "first" and "second" in this application is for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of the various embodiments can be combined with each other, but only on the basis of being achievable by those skilled in the art. If the combination of technical solutions is contradictory or impossible to implement, such a combination of technical solutions should be considered non-existent and not within the scope of protection claimed in this application.

[0038] Before providing a further detailed description of this application, the nouns and terms used in the embodiments of this application are explained, and the nouns and terms used in the embodiments of this application shall be interpreted as follows:

[0039] DRAM: Dynamic Random Access Memory, a type of high-speed volatile memory that requires periodic refresh to maintain data and stores information in capacitive charge, used as the main memory of a computer.

[0040] CXL.mem: Compute Express Link Memory Protocol, a high-bandwidth, low-latency interconnect protocol based on PCIe that allows the CPU to efficiently access the memory of external devices (such as accelerators and memory pools) with memory semantics.

[0041] PMEM: Persistent Memory, a byte-addressable storage medium that combines memory-level access speed with data persistence.

[0042] PCIe: Peripheral Component Interconnect Express, is a high-speed bus standard for connecting peripheral components. It uses high-speed serial point-to-point differential signal transmission and communicates via data packets to connect high-speed peripherals such as graphics cards, SSDs, and network cards.

[0043] SSD: Solid State Drive, a block storage device that uses non-volatile semiconductor memory such as flash memory and has no moving mechanical parts.

[0044] ext4-DAX: Direct Access for the Fourth Extended Filesystem, a Linux file system that supports DAX mode, allowing applications to directly access PMEM via memory load / store instructions, bypassing the page cache.

[0045] DAX: Direct Access, allows applications to directly access data on persistent memory devices through the CPU's memory load / store instructions, completely bypassing the operating system's page cache and I / O stack, thereby achieving extremely low-latency persistent data access.

[0046] UPT stands for Unified Page Table, a memory management mechanism that extends the traditional virtual memory page table to establish a direct mapping between logical addresses of files (i.e., offsets within the file) and physical addresses in heterogeneous memory pools. Through the unified page table, the system treats file data as a continuous stream of bytes that can be directly mapped to the process's address space.

[0047] SplitFS: Split Filesystem, a user-space file system that optimizes PMEM performance by separating data and metadata operations.

[0048] Strata: Strata File System, a hierarchical file system, is a high-performance cross-media file system designed for heterogeneous storage (DRAM, PMEM, SSD), running in user space and utilizing a log structure.

[0049] CtFS: Crash-consistent Transparent File System, a kernel file system that utilizes PMEM byte-addressable features and achieves high-efficiency crash consistency through lightweight shadow paging.

[0050] FLACFS: Flash and Consistency File System, a lightweight atomic crash-consistent file system designed for flash and PMEM that uses novel atomic update primitives to ensure crash consistency.

[0051] MMU: Memory Management Unit, a hardware unit in the CPU responsible for translating virtual addresses into physical addresses and implementing memory protection and access control.

[0052] inode: an index node, a data structure in a file system used to describe the metadata (permissions, size, data block location, etc.) of a file or directory.

[0053] PGD: Page Global Directory. In Linux multi-level page tables, it is a directory entry that points to the top-level page table (P4D or PUD) and is used to store the address of the top-level page table of a process.

[0054] P4D: Page 4th-Level Directory, a fourth-level page directory in the five-level page table, located between PGD and PUD.

[0055] PUD: Page Upper Directory, a third-level page directory in the fourth or fifth level page table, between P4D (or PGD) and PMD.

[0056] PTE: Page Table Entry. The lowest level entry in the page table, containing the mapping from virtual pages to physical page frames and permission bits (such as exist, writable, dirty).

[0057] PMD: Page Middle Directory. The Page Middle Directory is a second-level page directory located between PUD and PTE in the fourth or fifth level page table.

[0058] NVPMD: Non-Volatile Page Middle Directory, a page middle directory entry designed specifically for non-volatile memory such as PMEM, which may contain persistence-related metadata.

[0059] NVPTE: Non-Volatile Page Table Entry. A page table entry designed specifically for mapping non-volatile memory regions such as PMEM. It may contain special flags such as persistence and write order control.

[0060] Data Block: A data block is the smallest logical allocation unit (e.g., 4KB) used in a file system to store the actual contents of a file.

[0061] I / O path: Input / output path, the complete software and hardware stack through which data travels in a computer system from an application to a storage device (or vice versa), including system calls, file systems, drivers, controllers, etc.

[0062] Unified View of File Data: This refers to using a single, consistent interface to access and manage file data scattered across different locations and storage systems.

[0063] With the collaborative deployment of DRAM, CXL.mem, and persistent memory (PMEM) on the same computing node, the system gradually forms a heterogeneous memory architecture composed of multiple memory media. For heterogeneous memory management, a representative approach employs a hierarchical memory management method, using DRAM as high-performance main memory and CXL.mem as a capacity expansion layer, dynamically adjusting data placement between different layers through a hot-cold data migration strategy. In this model, since CXL.mem lacks persistence, the system typically relies on the PMEM file system or a traditional SSD file system to ensure data reliability. However, this approach creates a strict boundary between the volatile memory layer (DRAM / CXL.mem) and the persistent storage layer; data must pass through DRAM before persistence, leading to forced data copying and write amplification issues. Furthermore, it fails to utilize PMEM as a directly accessible first-class memory layer.

[0064] Another type of research focuses on PMEM DAX file systems that bypass DRAM, leveraging PMEM's byte-level addressing capabilities to shorten I / O paths and reduce software stack overhead. Typical systems include ext4-DAX, SplitFS, and Strata. These systems bypass page caching and traditional block I / O, transforming file access into memory access. They argue that when using PMEM as the persistent layer medium, employing a simple DRAM caching strategy will result in a high cache miss rate under random access loads, leading to frequent and costly cross-layer data migrations, further exacerbating bandwidth contention and performance degradation. Therefore, it is better to use PMEM as the sole medium for access.

[0065] Furthermore, CtFS eliminates the traditional inode and index structure by using a hardware MMU for file address translation. This type of DAX file system is based on the prior assumption that "PMEM" performance is sufficiently superior (which has not actually been achieved), thus completely abandoning the use of DRAM. Meanwhile, existing research indicates that even in DAX file systems, virtual memory management still requires copying data to the application address space, triggering data migration from PMEM to DRAM. This process is located on the I / O critical path and can cause a performance loss of over 50%.

[0066] FLACFS advocates for the integration of DRAM and PMEM, directly incorporating DRAM cache into virtual memory management through heterogeneous page tables. While such systems effectively reduce access latency in DRAM-PMEM scenarios, their design typically assumes DRAM as a mandatory cache layer, requiring data to first enter DRAM before it can be accessed or modified. This approach ignores PMEM's byte-level addressing capabilities and fails to flexibly utilize the new scalable CXL.mem memory layer, resulting in wasted DRAM capacity, improper placement of hot data, and performance limitations that prevent scaling with data volume, hindering expansion to more complex multi-layered heterogeneous memory architectures.

[0067] Furthermore, existing systems typically optimize only between two memory layers (DRAM+PMEM or DRAM+CXL.mem), lacking a unified address space and data placement mechanism for managing three heterogeneous memory layers. This makes it difficult to transparently integrate new memory devices, limiting system scalability. Moreover, in existing designs, the data write path often bears both performance and persistence responsibilities, and refresh operations can easily block foreground I / O, increasing lock contention and synchronization overhead, making it difficult to maintain stable performance under high concurrency and mixed loads.

[0068] In summary, existing technologies face the following common problems in heterogeneous memory environments: First, they lack a unified address and management abstraction across DRAM, CXL.mem, and PMEM; second, they are not sufficiently decoupled from data placement and migration strategies, access characteristics, and persistence requirements; and third, they do not fully utilize the hardware characteristics of PMEM and new memory devices.

[0069] To at least address the aforementioned technical issues, this application provides a heterogeneous memory management system, method, and medium. Through the collaborative design of file systems and virtual memory, multiple memory resources are managed collaboratively as a unified first-class resource to reduce unnecessary data copying and migration overhead, and to achieve overall optimization in terms of performance, capacity, and persistence.

[0070] Figure 1 The diagram shown is an architectural schematic of a heterogeneous memory management system provided in an embodiment of this application. Figure 1 As shown, the system includes an acceleration layer and a persistence layer; the acceleration layer consists of a first physical memory and a second physical memory, and the persistence layer consists of a third physical memory, wherein the first physical memory, the second physical memory, and the third physical memory are heterogeneous memory.

[0071] In some embodiments, the heterogeneous memory management system provided in this application distinguishes between hot and cold data based on the access frequency of file data, and periodically stores hot data in the acceleration layer and evicts cold data from the acceleration layer to merge it into the persistent layer.

[0072] In some embodiments, the first physical memory is DRAM, the second physical memory is CXL.mem, and the third physical memory is PMEM. The acceleration layer, composed of DRAM and CXL.mem, is used to carry hot data, while the persistent layer is entirely built on PMEM and is used to store cold data and persistent metadata. In still other embodiments, DRAM carries hot data, and CXL.mem carries temperature data.

[0073] Furthermore, data can be categorized into hot and cold data based on its access frequency; data accessed frequently is classified as hot data, and data accessed infrequently is classified as cold data. In some embodiments, for more refined memory management, data can also be categorized into cold, warm, and hot data based on its access frequency. That is, data accessed frequently is classified as hot data, data accessed relatively frequently is classified as warm data, and data accessed infrequently is classified as cold data.

[0074] Unlike existing cached architectures, the heterogeneous memory management system provided in this application embodiment allows data to be placed directly at any level as "main memory location" rather than as a cache copy, fundamentally eliminating the necessary path between levels.

[0075] In some embodiments, the heterogeneous memory management system provided in this application allocates a unified page table for the target file in the persistent layer. The unified page table is used to establish a mapping relationship between the file's logical address and the heterogeneous memory. Furthermore, the system also allocates a file identifier for the target file, and the file identifier corresponds one-to-one with the unified page table.

[0076] In some embodiments, the unified page table includes multiple page table entries, each corresponding to a virtual page of a fixed size. These virtual pages correspond one-to-one with physical pages located in the first physical memory, the second physical memory, and / or physical page frames in the third physical memory. That is, through the mapping relationship in the PTE, each virtual page is mapped to a physical page frame of the same size in physical memory. When the CPU accesses a virtual address, the system queries the unified page table to find the corresponding page table entry, thereby obtaining the physical page frame number mapped to the corresponding virtual page, thus converting the virtual address to a physical address and completing the memory access.

[0077] This application integrates the traditionally separate file system index structure and virtual memory page table structure by introducing a unified page table. For example... Figure 2 As shown, UPT uses pages as the basic management unit. Through a multi-level persistent page table structure, it directly maps the logical address space of a file to physical page frames in DRAM, CXL.mem, or PMEM. This establishes a direct mapping between the file's logical address (i.e., the offset within the file) and the physical address in the heterogeneous memory pool. Through UPT, the system treats file data as a continuous stream of bytes that can be directly mapped to the process's address space, allowing file data to be accessed directly with memory access semantics. This eliminates the indirect path of "store first, then cache" in traditional cache levels and avoids the forced migration of data via DRAM. When an application accesses a file, the memory access request issued by the CPU (corresponding to the file's logical address) will complete a multi-level lookup through this unified page table (e.g., ...). Figure 2 The process involves PGD → P4D → PUD → PMD → PTE, until the corresponding physical page frame number of the virtual page is obtained based on the PTE, and then the virtual address is translated into a physical address to complete the memory access. If the target address falls in a non-DRAM memory region, the CPU can directly read and write persistent data with memory access instructions, without going through the traditional page cache and complex I / O software stack, thus providing data persistence while achieving access performance close to DRAM.

[0078] Furthermore, the page table structure of UPT is persistently stored in the persistent layer to ensure that the address mapping relationship remains valid after the system crashes, thereby achieving crash consistency.

[0079] Furthermore, the acceleration layer employs a pre-allocated memory pool with large page granularity (e.g., 2MB) and uses an efficient bitmap management mechanism to allocate and reclaim the first or second physical memory. That is, during system initialization, the acceleration layer requests and reserves a large contiguous physical memory region as a dedicated memory pool. This memory pool is divided into 2MB units, with each large page serving as an allocation unit, and managed through a compact bitmap data structure: each bit in the bitmap corresponds to a large page, with "0" representing free and "1" representing allocated. When allocating the first or second physical memory, the system simply scans the bitmap quickly and marks consecutive free bits to directly return the starting physical address of the corresponding large page; when releasing, the corresponding bit is cleared. This approach not only significantly reduces the number of page table entries and TLB miss rate but also achieves high-speed memory allocation and reclamation by avoiding frequent kernel-mode switching and lock contention, making it particularly suitable for high-performance computing, databases, and large-scale caching scenarios that require large amounts of contiguous memory.

[0080] Furthermore, after establishing the mapping relationship between file logical addresses and heterogeneous memory through a unified page table, to achieve a balance between performance and persistence, the heterogeneous memory management system provided in this application also introduces a shadow page mechanism. In some embodiments, each physical page frame located in the acceleration layer has a corresponding shadow page, and the shadow page is located in the persistence layer. That is, each physical page frame located in the first physical memory or the second physical memory corresponds to a persistent shadow page located in the persistence layer.

[0081] Furthermore, in some embodiments, the system periodically flushes dirty data marked in physical page frames located in the acceleration layer to the corresponding shadow pages, and locks the flushed physical page frames during the flushing process. That is, when the original physical page frame in the acceleration layer contains non-persistent modifications (marked as "dirty") due to being written to, the system asynchronously flushes this dirty data to the corresponding shadow page in the persistence layer through a background periodic flushing thread. This asynchronous flushing mechanism ensures data persistence, allowing application modifications to be recovered after a system crash. Simultaneously, the original physical page frame typically remains resident to continue providing low-latency access, while the persistent shadow page serves as a reliable backup of the data, achieving a balance between performance and reliability. Therefore, the heterogeneous memory management system provided in this application embodiment manages memory using dual pointers and hierarchical flags. Foreground I / O operations prioritize accessing the corresponding physical page frames, ensuring data placement is uniformly determined by a hot / cold policy. The asynchronous flushing mechanism avoids triggering data migration with every memory access, preventing performance penalties associated with cache misses and on-demand migration.

[0082] Furthermore, in order to solve the data consistency problem caused by concurrent writes during refresh, the heterogeneous memory management system provided in this application embodiment also includes a general buffer; the system is also used to redirect new write requests to the general buffer when the dirty data is refreshed to the shadow page; and the accumulated data in the general buffer is merged into the persistent layer in the next refresh cycle.

[0083] like Figure 3 As shown, when a refresh cycle begins, dirty data in the acceleration layer is flushed to shadow pages in the persistence layer. At this time, a general buffer is activated, and the flushed physical page frames are locked to prevent direct modification. New write requests from the application are redirected to the general buffer, thus preventing the foreground process from being blocked. Once the dirty data in the acceleration layer has been flushed, the data in the general buffer is written back to the acceleration layer and merged into the persistence layer in the next refresh cycle. Therefore, this application decouples the foreground write path from the background persistence process through a general buffer, transforming potentially blocking operations into non-blocking operations while avoiding complex real-time consistency maintenance.

[0084] In some embodiments, the heterogeneous memory management system provided in this application further includes a file system interface; the file system interface is used to provide an interface to applications so that the applications can access the heterogeneous memory management system through the file system interface. For example, this application includes a POSIX file system interface, which provides near-memory-level access performance while maintaining POSIX semantics. Applications can benefit from the performance advantages of heterogeneous memory without modification, and it has good practicality and promotional value.

[0085] For example, the heterogeneous memory management system provided in this application provides unified optimization for POSIX file operations. User applications call standard POSIX read / write / mmap interfaces, and the system intercepts requests without modifying the user program, directly completing address translation through UPT, providing interface semantics consistent with traditional file systems, and returning results after the operation is completed. For example, the open() operation installs a complete UPT during the initialization phase; the read() / write() operations complete address translation with a single page table traversal, directly accessing the target memory medium and bypassing the cache level; the append() operation prioritizes low-latency writing to CXL.mem and achieves high-throughput persistence through background batch migration; mmap() directly reuses the persistent UPT, avoiding page table construction and page fault exceptions; and the enhanced flush() and close() protocols eliminate race conditions between foreground I / O and background flush, ensuring system stability and reliability.

[0086] like Figure 4 As shown, the application writes data to the heterogeneous memory management system along the I / O path through the file system interface (Unified View of File Data). The system categorizes data into hot, warm, and cold data based on access frequency, storing hot data in the DRAM device within the acceleration layer, warm data in the CXL device within the acceleration layer, and cold data in the Pmem device. Furthermore, for data in DRAM or CXL.mem, a persistent shadow copy is created in the persistent layer. In addition, the acceleration layer includes a G-PBuffer (General Purpose Buffer). When the system performs a background flush thread, new write requests are transparently redirected to the G-PBuffer without blocking the foreground process. This decouples the foreground write path from the background persistence process, transforming potentially blocking operations into non-blocking operations and avoiding complex real-time consistency maintenance.

[0087] In some embodiments, this application takes a heterogeneous memory system with user applications conforming to the POSIX file interface and underlying storage including DRAM, CXL.mem and PMEM as an example to describe in detail the workflow of the Unified Page-table-based Layered EXecution system (hereinafter referred to as UPLEX).

[0088] (1) System initialization and mounting:

[0089] When the operating system starts, UPLEX is loaded along with the operating system kernel or a trusted execution environment;

[0090] UPLEX initializes persistent memory PMEM and creates a persistent area on PMEM for storing UPT and related metadata;

[0091] Initialize the DRAM and CXL.mem acceleration layer memory pools to store hot data and buffered data, respectively;

[0092] Initialize the global metadata structure file_table to record the status of all open files in the system;

[0093] Initialize the background asynchronous refresh thread and the general buffer;

[0094] Mount the UPLEX file system to the specified directory (e.g., / mnt / uplexfs) using the mount command.

[0095] Once mounted, UPLEX begins handling file access requests within that directory.

[0096] (2) Initial file creation and UPT construction:

[0097] User applications call the POSIX open() interface to create new files in the mounted directory;

[0098] UPLEX captures the open() request and assigns a unique file identifier to the target file;

[0099] Allocate and initialize a UPT structure for this file on PMEM;

[0100] In UPT, a mapping space is established from the logical address of the file to the physical page frame, but shadow pages are not allocated initially;

[0101] Record the root pointer of UPT and file metadata into file_table;

[0102] When the open() call returns, the file creation is complete.

[0103] (3) File writing and shadow page creation

[0104] The user application calls the write() interface on an already opened file;

[0105] UPLEX calculates the corresponding virtual page number based on the write offset;

[0106] Check if the virtual page number already has a physical page mapping in the UPT;

[0107] If no mapping exists, physical pages are allocated according to the data placement strategy:

[0108] Hot data is prioritized for allocation to DRAM physical page frames;

[0109] Secondary heat data is allocated to physical page frames in CXL.mem;

[0110] Cold data is directly allocated to PMEM physical page frames;

[0111] If DRAM or CXL.mem is allocated, a corresponding persistent shadow page is simultaneously created in PMEM;

[0112] Update the UPT page table entries to record the physical address and its memory level;

[0113] User data is written directly to the acceleration layer physical page frame or PMEM page;

[0114] Set the dirty flag for page table entries;

[0115] The write() operation completes and returns.

[0116] (4) File reading process:

[0117] The user application calls the read() interface to request to read file data;

[0118] UPLEX locates the corresponding UPT based on the file descriptor;

[0119] Use UPT to find the physical page frame address corresponding to the target offset;

[0120] If the page is located in DRAM or CXL.mem, the data is returned directly from the acceleration layer;

[0121] If the page is located in PMEM, it is read directly through memory mapping.

[0122] The entire process does not involve traditional page caching and does not trigger cache miss handling.

[0123] The read() operation completes and returns the data.

[0124] (5) Background refresh and general buffer coordination workflow:

[0125] A background refresh thread periodically scans the file_table to obtain snapshots of currently dirty files;

[0126] For each file to be refreshed, call gp_buffer_activate to activate the corresponding general buffer;

[0127] Lock the physical page frame associated with the file to prevent direct modification;

[0128] Dirty data in the physical page frame is asynchronously copied to the PMEM shadow page;

[0129] During the refresh process, new write requests from the foreground are redirected to the general buffer;

[0130] After the refresh is complete, release the physical page frame lock;

[0131] Data accumulated in the general buffer awaits the next round of flushing and is written to PMEM in a unified manner.

[0132] This mechanism prevents foreground I / O from being blocked by refresh operations.

[0133] (6) Example of append operation:

[0134] The user application calls append() or executes write() at the end of the file;

[0135] UPLEX allocates a new physical page frame from the global CXL.mem memory pool;

[0136] The appended data will be written directly to CXL.mem;

[0137] Immediately update the logical file size (logical EOF) in DRAM;

[0138] Do not immediately expand the physical file space on PMEM;

[0139] The background refresh thread allocates PMEM space in batches and migrates data at appropriate times;

[0140] The append operation is complete, ensuring POSIX file size semantics.

[0141] (7) File closing and consistency handling:

[0142] The user calls the close() interface;

[0143] UPLEX checks if the file is currently being refreshed;

[0144] If the page is being refreshed, set the is_close flag and delay resource release;

[0145] If not refreshed, the dirty pages will be refreshed synchronously and the physical page frames will be released;

[0146] Clean up process-private mappings, but retain persistent UPT and PMEM data;

[0147] The close() operation is complete.

[0148] (8) Example of system recovery after a crash:

[0149] After an abnormal system restart, the UPLEX module is reloaded;

[0150] Scan and load all persistent UPTs from PMEM;

[0151] Rebuild the file status in file_table;

[0152] Verify the consistency between the physical page frame and the PMEM shadow page;

[0153] Perform rollback or replay on data that has not been refreshed;

[0154] The file system recovery is complete, and the data remains consistent with the crash findings.

[0155] This application also provides a heterogeneous memory management method, which is applied to the above-mentioned heterogeneous memory management system. Figure 5 The diagram shown is a flowchart illustrating a heterogeneous memory management method provided in an embodiment of this application. Figure 5 As shown, the heterogeneous memory management method provided in this application includes steps S1 to S3.

[0156] S1. Based on the allocation request, allocate a unified page table for the target file in the persistent layer. The unified page table is used to establish the mapping relationship between the file's logical address and the heterogeneous memory.

[0157] S2. Calculate the virtual page number corresponding to the write offset in the file logical address based on the write request, and query whether there is a mapping relationship between the virtual page number and the heterogeneous memory through the unified page table.

[0158] S3. If the mapping relationship does not exist, then hot and cold data are distinguished according to the access frequency of file data, so that hot data is stored in the acceleration layer or cold data is stored in the persistent layer.

[0159] In some embodiments, the method further includes: determining the file identifier of the target file based on the read request, and locating the corresponding unified page table according to the file identifier; searching for the physical page frame corresponding to the target file data through the unified page table; if the physical page frame is located in the acceleration layer, then directly returning the target file data from the acceleration layer; if the physical page frame address is located in the persistent layer, then directly reading it through memory mapping.

[0160] It should be noted that the principle of the heterogeneous memory management method provided in the embodiments of this application can be referred to the content in the above embodiments, and will not be repeated here.

[0161] It should be noted that the scope of protection of the heterogeneous memory management method provided in this application is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting or replacing steps in the prior art based on the principles of this application is included within the scope of protection of this application.

[0162] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0163] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of this application, depending on actual needs. For example, the functional modules / units in the various embodiments of this application may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit. Those skilled in the art should further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0164] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0165] This application embodiment may also provide a computer program product comprising one or more computer instructions. When the computer instructions are loaded and executed on a computing device, all or part of the processes or functions described in this application embodiment are generated. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.

[0166] When the computer program product is executed by a computer, the computer performs the method described in the foregoing method embodiments. The computer program product can be a software installation package; when the foregoing method is required, the computer program product can be downloaded and executed on the computer.

[0167] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0168] In summary, the heterogeneous memory management system, method, and medium provided in this application can eliminate the forced copy path in traditional heterogeneous memory systems, significantly reduce data copying and migration overhead, lower access latency, and improve throughput performance. Secondly, this application achieves unified management of heterogeneous memory, enabling different memory media to serve as primary data storage locations, significantly improving memory resource utilization efficiency. Thirdly, this application optimizes performance, capacity, and persistence simultaneously through shadow pages and asynchronous refresh, decoupling performance optimization from persistence guarantees, enabling the system to scale stably under high concurrency and large data volumes.

[0169] Finally, this application offers excellent scalability for novel memory devices. The unified page table abstraction enables transparent integration of these devices, avoiding the need to redesign storage and management mechanisms for each type of hardware. Furthermore, this application provides a file system interface that offers near-memory-level access performance while maintaining interface semantics. Applications can benefit from the performance advantages of heterogeneous memory without modification, demonstrating strong practicality and promotional value.

[0170] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0171] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A heterogeneous memory management system, characterized in that, The system includes an acceleration layer and a persistence layer; the acceleration layer consists of a first physical memory and a second physical memory, and the persistence layer consists of a third physical memory, wherein the first physical memory, the second physical memory, and the third physical memory are heterogeneous memory; The system allocates a unified page table for the target file in the persistent layer. The unified page table is used to establish the mapping relationship between the file's logical address and the heterogeneous memory. The system distinguishes between hot and cold data based on the access frequency of file data, and periodically stores hot data in the acceleration layer and evicts cold data from the acceleration layer to merge it into the persistent layer.

2. The heterogeneous memory management system according to claim 1, characterized in that, The unified page table includes multiple page table entries, each of which corresponds to a virtual page of a fixed size. The multiple virtual pages correspond one-to-one with physical pages located in the first physical memory, the second physical memory, and / or physical page frames located in the third physical memory.

3. The heterogeneous memory management system according to claim 2, characterized in that, Each physical page frame located in the acceleration layer has a corresponding shadow page, and the shadow page is located in the persistent layer; The system periodically refreshes the dirty data marked in the physical page frame located in the acceleration layer to the corresponding shadow page, and locks the refreshed physical page frame during the refresh process.

4. The heterogeneous memory management system according to claim 3, characterized in that, The system also includes a general buffer; The system is also configured to redirect new write requests to the general buffer when the dirty data is flushed to the shadow page; and The accumulated data in the general buffer is merged into the persistent layer in the next refresh cycle.

5. The heterogeneous memory management system according to claim 1, characterized in that, The system is also used to assign file identifiers to target files, and the file identifiers correspond one-to-one with the unified page table.

6. The heterogeneous memory management system according to claim 1, characterized in that, The system also includes a file system interface; the file system interface is used to provide an interface to applications so that the applications can access the heterogeneous memory management system through the file system interface.

7. The heterogeneous memory management system according to claim 1, characterized in that, The acceleration layer employs a pre-allocated memory pool with large page granularity and allocates and reclaims the first physical memory and / or the second physical memory through a bitmap management mechanism.

8. A heterogeneous memory management method, characterized in that, The method is applied to a heterogeneous memory management system, which includes an acceleration layer and a persistence layer; the acceleration layer consists of a first physical memory and a second physical memory, and the persistence layer consists of a third physical memory, wherein the first physical memory, the second physical memory, and the third physical memory are heterogeneous memory; Based on the allocation request, a unified page table is allocated for the target file in the persistent layer. The unified page table is used to establish the mapping relationship between the file's logical address and the heterogeneous memory. Based on the write request, calculate the virtual page number corresponding to the write offset in the logical address of the file, and query whether there is a mapping relationship between the virtual page number and the heterogeneous memory through the unified page table; If the mapping relationship does not exist, hot and cold data are distinguished according to the access frequency of file data, so that hot data is stored in the acceleration layer or cold data is stored in the persistent layer.

9. The heterogeneous memory management method according to claim 8, characterized in that, The method further includes: The file identifier of the target file is determined based on the read request, and the corresponding unified page table is located according to the file identifier; The physical page frame corresponding to the target file data is found through the unified page table. If the physical page frame is located in the acceleration layer, the target file data is returned directly from the acceleration layer. If the physical page frame address is located in the persistent layer, it is read directly through memory mapping.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the terminal, it implements the functions of the heterogeneous memory management system as described in any one of claims 1 to 7 or the heterogeneous memory management method as described in any one of claims 8 to 9.

Images