A multi-level cache implementation method and system suitable for non-volatile storage data

Abstract

The application discloses a multi-level cache implementation method and system suitable for nonvolatile storage data, and relates to the technical field of data storage. The method is cooperatively executed based on a first-level cache managed by a hardware management module and a second-level cache managed by a software management module, and comprises the following steps: the hardware management module performs address analysis on a received host command, and queries the state of a corresponding data block in the first-level cache. The state comprises invalid, loading, available, dirty data and unloading. When the data block is in the invalid state, a data loading operation from a nonvolatile memory or the second-level cache to the first-level cache is triggered. When the data block in the dirty data state needs to be replaced from the first-level cache, an operation of migrating the data block to the second-level cache for temporary storage is triggered. Through the software and hardware cooperative division architecture and the dirty data priority cache migration strategy, the application effectively reduces the data access delay, and realizes more stable overall performance.

Description

Technical Field

[0001] This invention relates to the field of data storage technology, and in particular to a method and system for implementing multi-level caching suitable for non-volatile data storage. Background Technology

[0002] Currently, multi-level caching schemes are mainly used to meet the high-speed access requirements of central processing unit (CPU) for near-end volatile storage data. By introducing multi-level caching in the storage hierarchy, the overall access efficiency is improved by utilizing the principle of locality of reference in data access.

[0003] With the rapid development of solid-state storage technology and the evolution of high-speed interconnect protocols such as Compute Express Link, the CPU's demand for accessing non-volatile data in remote storage devices is increasing. However, due to physical limitations, non-volatile storage media have significantly higher read / write latency than dynamic random access memory, which has become a bottleneck restricting the real-time performance of the system.

[0004] To address this challenge, Chinese invention patent CN118331508B discloses a method for managing data consistency between cache and non-volatile NAND flash memory using a centralized data state controller. While this solution introduces a dedicated state for non-volatile memory, its centralized control architecture has inherent limitations. First, all state queries, judgments, and command generation are processed serially by a single logic unit, which can easily become a performance bottleneck in high-concurrency scenarios, affecting real-time response capabilities. Second, its core drawback lies in requiring dirty data to be directly and synchronously written back to the high-latency NAND. This blocking operation inevitably causes periodic spikes and drastic fluctuations in system input / output latency during peak dirty data periods, leading to performance instability. Furthermore, the caching strategy is tightly coupled with hardware management, making independent optimization and iteration difficult.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] To address the problems of high access latency, periodic performance fluctuations, and insufficient architectural flexibility in existing technologies for managing non-volatile storage data, this invention proposes a multi-level caching implementation method and system suitable for non-volatile storage data. Through a hardware-software collaborative architecture and a dirty data-first cache migration strategy, data access latency is effectively reduced, achieving more stable overall performance.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A method for implementing a multi-level cache suitable for non-volatile storage data, wherein a hardware management module manages the first-level cache and a software management module manages the second-level cache, the method comprising:

[0009] The received host command is parsed to obtain the location identifier of the target data block in the first-level cache;

[0010] Based on the location identifier, query the status of the corresponding data block in the first-level cache; the status includes invalid, loading, available, dirty data, and unloading.

[0011] If the data block is invalid, a data load operation from the second-level cache or non-volatile memory to the first-level cache is triggered;

[0012] If a data block in a dirty state needs to be replaced from the first-level cache, an operation is triggered to migrate the data block from the first-level cache to the second-level cache for temporary storage.

[0013] As a preferred embodiment of the present invention, the triggering of the data load operation from the second-level cache or non-volatile memory to the first-level cache includes:

[0014] Allocate a first-level cache destination address for the data loading operation and generate a loading command; the loading command includes at least a command ID, a command type, a source data address, and a first-level cache destination address; the command type is loading.

[0015] Based on the load command, query the second-level cache address mapping table;

[0016] If the data block is hit in the L2 cache, the data is read from the L2 cache and written to the destination address of the L1 cache; otherwise, the data is read from non-volatile memory and written to the destination address of the L1 cache.

[0017] As a preferred embodiment of the present invention, if the data block is in the loading state, subsequent host commands accessing the data block are cached until loading is complete;

[0018] After successful loading, the status of the data block is updated to available or dirty data, and all cached host commands are processed.

[0019] As a preferred embodiment of the present invention, the state update follows the following transition rules:

[0020] The initial state of all data blocks is set to invalid;

[0021] When accessing a data block that is in an invalid state, change the state of that data block to loading.

[0022] Once a data block is successfully loaded, if the host command that triggered the loading is a read command, the data block's state is changed to available; if the host command that triggered the loading is a write command, the data block's state is changed to dirty data.

[0023] When accessing a data block that is in an available state, if the host command that triggered the access is a read command, the state of the data block will remain available; if the host command that triggered the access is a write command, the state of the data block will be changed to dirty data.

[0024] When a data block in a dirty data state is selected as the replacement object, the state of that data block is changed to unloading.

[0025] Once a data block in the unloading state is successfully migrated from the first-level cache to the second-level cache, its state is changed to invalid; if it is accessed again before the migration is complete, its state is changed to dirty data.

[0026] As a preferred embodiment of the present invention, the operation of triggering the migration of the data block from the first-level cache to the second-level cache for temporary storage includes:

[0027] Generate a migration command; the migration command includes at least a command ID, a command type, the first-level cache source address where the data to be migrated is located, and the data length; the command type is migration.

[0028] Based on the migration command, allocate the destination address for the second-level cache;

[0029] The data to be migrated is moved from the source address of the first-level cache to the destination address of the second-level cache, and the status of the data block is updated to invalid after successful migration.

[0030] As a preferred embodiment of the present invention, a migration abort and rollback mechanism is also included:

[0031] If a data block in the unloading state is accessed again before the migration is complete, the migration process will be aborted.

[0032] Roll back some data that has been migrated to the second-level cache to the first-level cache, and update the status of the data block to dirty data.

[0033] A multi-level cache implementation system suitable for non-volatile storage data includes:

[0034] The hardware management module is used to parse host commands, query the status of data blocks in the first-level cache, and trigger data loading or data migration operations based on the status.

[0035] The software management module is used to respond to triggers from the hardware management module and perform data loading or data migration operations.

[0036] The first-level cache is managed by the hardware management module;

[0037] The second-level cache is managed by the software management module.

[0038] In a preferred embodiment of the present invention, the capacity of the second-level cache is greater than that of the first-level cache;

[0039] The hardware management module has an embedded state machine, which is used to realize the state transition and maintenance of data blocks;

[0040] The hardware management module and the software management module interact with each other through a dedicated communication interface to exchange commands and status information in order to collaboratively achieve multi-level cache management.

[0041] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program implementing a multi-level cache implementation method suitable for non-volatile storage data.

[0042] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a multi-level cache implementation method suitable for non-volatile storage data.

[0043] Compared with existing technologies, the beneficial effects of this invention are as follows: By querying the data block status in real time and triggering operations through the hardware management module, extremely low latency and deterministic response are ensured for accessing hot data in the first-level cache. Simultaneously, the software management module executes specific data loading and migration operations, allowing the management strategy of the second-level cache to be flexibly configured, optimized, and iterated independently of the hardware. This hardware-software collaborative and decoupled design enables the system to meet real-time requirements while flexibly adapting to complex application load changes, achieving a balance between performance and flexibility. By innovatively triggering the migration and temporary storage of data in the second-level cache when data in a dirty state needs to be replaced, the blocking input or output operation of directly writing back to high-latency non-volatile storage devices in traditional solutions is transformed into rapid data transfer within volatile memory. This fundamentally smooths the write-back load of the system, effectively eliminating periodic spikes in input or output latency, and achieving stable and predictable performance output. In addition, this architecture reduces blocking access to non-volatile storage devices, thereby improving the overall system throughput and high-concurrency processing capabilities, while also helping to reduce write amplification and wear of storage media and extend their lifespan.

[0044] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein:

[0046] Figure 1 This is a flowchart of a multi-level cache implementation method for non-volatile storage data proposed in this invention;

[0047] Figure 2 This invention provides a modular structure diagram of a multi-level cache implementation system suitable for non-volatile storage data. Detailed Implementation

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention are within the scope of protection of the present invention.

[0049] like Figure 1 As shown, this is an embodiment of the present invention. This embodiment provides a multi-level cache implementation method suitable for non-volatile storage data. The first-level cache is managed by a hardware management module, and the second-level cache is managed by a software module. The method includes:

[0050] The received host command is resolved by address parsing to obtain the location identifier of the target data block in the first-level cache.

[0051] The first-level cache is located in volatile memory, and its storage space is divided into S groups, each containing B data blocks. Each data block can store a fixed length of data and is entirely managed in real time by hardware logic. In a preferred embodiment, the first-level cache is located in DRAM, and each data block can store 4KB of data.

[0052] The process of address resolution for received host commands includes:

[0053] It receives read and write commands from the host and caches them in an internal host command queue. This queue ensures sequential processing and pending capabilities for the commands.

[0054] The target address in the host command is parsed, and the corresponding group address and block label in the first-level cache are obtained through the preset group-association mapping relationship.

[0055] Based on the location identifier, query the status of the corresponding data block in the first-level cache. The status includes invalid, loading, available, dirty data, and unloading.

[0056] Invalid indicates that the data block currently does not store valid data. Loading indicates that the data block is being loaded from non-volatile storage or the second-level cache into the first-level cache. Available indicates that the data block has been loaded with valid data, is consistent with the underlying storage data, and can be read directly. Dirty indicates that the data in the data block has been modified by the host and is inconsistent with the underlying storage data. Unloading indicates that the data block is being migrated from the first-level cache to the second-level cache.

[0057] If the data block is invalid, a data load operation from the second-level cache or non-volatile memory to the first-level cache is triggered.

[0058] Specifically, when the target data block is found to be invalid, the host command that triggered this access is first cached in the host command queue, and then the data loading operation is triggered.

[0059] Triggering a data load operation from the second-level cache or non-volatile memory to the first-level cache includes:

[0060] Allocate a first-level cache destination address for the load operation and generate a load command. The load command includes at least a command ID, command type, source data address, and first-level cache destination address, with the command type being "load".

[0061] Specifically, the load command uses a standardized two-word format: DW0 contains a 16-bit command ID and a 16-bit command type, DW1 contains a 32-bit L1 cache destination address, and DW2 contains a 32-bit source data address.

[0062] Based on the load command, query the second-level cache address mapping table.

[0063] If the data block is hit in the L2 cache, the data is read directly from the L2 cache and written to the destination address of the L1 cache; otherwise, the data is read from non-volatile memory and written to the destination address of the L1 cache.

[0064] Specifically, the data read is written to the first-level cache destination address specified in the load command using the DMA engine.

[0065] If a data block is in the loading state, subsequent host commands that access that data block are cached until loading is successful.

[0066] Specifically, from the time a data block is set to the loading state until loading is complete, all newly arriving access commands for the same data block are cached in the host command queue, waiting for loading to complete.

[0067] After the data loading is complete, loading status information is generated.

[0068] Specifically, the loading status information includes the corresponding command ID, command type, and status type, using a standardized two-word format: DW0 contains a 16-bit command ID and a 16-bit command type; the high 16 bits of DW1 represent the status type, while the low 16 bits are reserved. For example, 0x00 indicates success, and 0x01 indicates failure.

[0069] If the status type in the loading status information is success, the status of the data block is updated to available or dirty data, and all cached host commands are processed based on the updated status.

[0070] If the status type in the loading status information is failure, the data loading operation will be retried. Optionally, the maximum number of attempts can be set.

[0071] The state transitions involved in the above process follow the following rules:

[0072] The initial state of all data blocks is set to invalid.

[0073] When accessing a data block that is in an invalid state, change the state of that data block to loading.

[0074] Once a data block is successfully loaded, if the host command that triggered the loading is a read command, the data block's state is changed to available; if the host command that triggered the loading is a write command, the data block's state is changed to dirty data.

[0075] When accessing a data block that is in an available state, if the host command that triggered the access is a read command, the data block will remain in an available state after the access is completed; if the host command that triggered the access is a write command, the data block will be converted to a dirty state after the access is completed.

[0076] When a data block in a dirty data state is selected as the replacement object, the state of that data block is changed to unloading.

[0077] Once a data block in the unloading state has completed its migration to the second-level cache, its state is changed to invalid; if it is accessed again before the migration is complete, the migration is aborted and the data block's state is changed to dirty data.

[0078] If a data block in a dirty state needs to be replaced from the first-level cache, an operation is triggered to migrate the data block from the first-level cache to the second-level cache for temporary storage.

[0079] Specifically, when the first-level cache space is full, or when a data block marked as dirty data needs to be replaced according to a replacement algorithm (such as LRU), the fundamental difference between this invention and traditional caching schemes that force data to be written back to high-latency non-volatile memory is that this invention marks the data block status as being unloaded and triggers a migration operation to the second-level cache. This "dirty data-first cache migration" strategy is one of the core advantages of this invention, transforming unpredictable, slow persistent input or output into deterministic, high-speed data movement within DRAM.

[0080] The operation that triggers the migration of the data block from the first-level cache to the second-level cache for temporary storage includes:

[0081] Generate a migration command. The migration command must include at least the command ID, command type, the first-level cache source address where the data to be migrated is located, and the data length. The command type is migration.

[0082] Specifically, the migration command uses a standardized two-word format: DW0 contains a 16-bit command ID and a 16-bit command type, DW1 contains a 32-bit L1 cache source address, and DW2 contains a 32-bit data length.

[0083] Based on the migration command, allocate the destination address for the second-level cache.

[0084] Specifically, the LRU algorithm is used to allocate the temporary storage area of ​​the second-level cache.

[0085] The data to be migrated is moved from the source address of the first-level cache to the destination address of the second-level cache, and the status of the data block is updated to invalid after successful migration.

[0086] Specifically, the DMA engine rapidly migrates data from the source address of the first-level cache to the destination address of the second-level cache. This operation is completed entirely within the volatile memory, with latency typically in the microseconds or even nanoseconds range, far lower than writing to non-volatile memory.

[0087] After the migration is completed, migration status information is generated. The migration status information includes at least the corresponding command ID, command type, and status type, and the specific format is the same as that of the loading status information.

[0088] If the migration status information indicates a successful migration, the corresponding data block status is updated to invalid, and the original first-level cache space can be reallocated. If the status indicates a failed migration, the data block status remains unloaded, and the migration operation is triggered again. Optionally, a maximum number of attempts can be set.

[0089] If a data block in the unloading state is accessed again before the migration is complete, the migration process is aborted. To ensure data consistency, a rollback mechanism is initiated: some data that has been migrated to the second-level cache is rolled back to the first-level cache, and the data block's state is updated to dirty data. This mechanism ensures that even under concurrent access, the host can always access the latest data version.

[0090] This invention employs the aforementioned dirty data-first caching migration strategy to redirect the replacement path of data in a dirty state from high-latency persistent input or output to low-latency volatile storage. When this data is accessed again, it can be quickly loaded directly from the second-level cache, completely avoiding the performance bottleneck of accessing non-volatile memory. This fundamentally smooths the system's write-back load and eliminates the performance jitter caused by centralized write-back in traditional solutions.

[0091] For data blocks in an available state, execute the host command directly and respond. For data blocks in a dirty state that do not need to be replaced from the first-level cache, keep the data block's state unchanged, execute the host command directly and respond.

[0092] This invention also provides a multi-level caching system suitable for non-volatile storage data, used to implement any of the above method embodiments. The system employs a hardware-software co-architecture, efficiently managing two levels of cache to adapt to the data access characteristics of non-volatile storage devices.

[0093] like Figure 2 As shown, another embodiment of the present invention provides a multi-level cache implementation system suitable for non-volatile storage data. The system includes a hardware management module, a software management module, a first-level cache, and a second-level cache. The components are interconnected and interact with each other through a system bus, a memory bus, and a dedicated communication interface.

[0094] The hardware management module is used to parse host commands, query the status of the corresponding data block in the first-level cache, and trigger data loading or data migration operations based on the status.

[0095] Specifically, the hardware management module is the core control hub of the system. It is usually implemented in the form of dedicated hardware circuits (such as FPGA / ASIC) and includes a command processing unit, an address resolution unit, a status management unit, and a coordination interface unit. These units work together to complete low-latency management of the first-level cache.

[0096] The command processing unit, connected to the host interface, is used to receive host read and write commands, perform validity checks and preliminary decoding, and write valid commands into the internal host command queue for caching and scheduling; after the host command is executed, it is responsible for returning response data or completion status to the host.

[0097] The address resolution unit is used to resolve the target address of a host command to obtain the corresponding group address and block label. This unit retrieves the target address of the command to be processed from the command processing unit and, according to a preset address mapping rule, resolves the system physical address into the corresponding group address and block label in the first-level cache. In a preferred embodiment, the preset address mapping rule adopts a group-associative mapping method.

[0098] The State Management Unit, the core decision-making unit of the hardware management module, maintains a tag state memory corresponding to the first-level cache structure. This memory stores the tag and current state of each cached data block, including invalid, loading, available, dirty, and unloading states. This unit receives the group address and block tag from the address resolution unit, queries the current state of the target data block, and, based on embedded state transition rules, host command type, and a preset replacement algorithm, makes real-time decisions and updates the next state of the data block. Specifically, the decision logic is as follows: if the data block state is available, the command processing unit is instructed to directly execute the host command; for write operations on available data blocks, the data block state is updated to dirty before execution. If the data block state is invalid, the data block state is updated to loading, and the coordination interface unit is notified to initiate a loading request. If a data block in a dirty state needs to be replaced, the data block state is updated to unloading, and the coordination interface unit is notified to initiate a migration request. If a data block in a dirty state does not need to be replaced, the command processing unit is instructed to directly execute the host command. In addition, this unit receives operation status feedback from the software management module forwarded by the coordination interface unit, and performs final status confirmation and subsequent action triggering accordingly: if the loading status is successful, the corresponding data block status is updated to available or dirty data, and the processing of the corresponding waiting commands in the host command queue is triggered; if the migration status is successful, the corresponding data block status is updated to invalid.

[0099] The coordination interface unit acts as a communication proxy between the hardware management module and the software management module. Based on instructions from the status management unit, this unit generates formatted load or migration commands and sends them to the software management module via a dedicated communication interface. Simultaneously, this unit is responsible for receiving response status information from the software management module through the dedicated communication interface and forwarding it to the status management unit for processing.

[0100] The software management module is used to respond to triggers from the hardware management module and perform data loading or data migration operations.

[0101] Specifically, the software management module runs on the system's main processor and typically exists in the form of a driver, firmware, or system service. Its main functions include: receiving and parsing load or migration commands sent by the hardware management module; maintaining the address mapping table of the L2 cache and managing the allocation and reclamation of L2 cache storage space; executing operations based on the command type. For load commands, it queries the L2 cache address mapping table; if a L2 cache hit is found, it reads the data from the L2 cache; otherwise, it reads the data from non-volatile memory and writes the data to the L1 cache destination address specified by the hardware management module using methods such as DMA. For migration commands, it reads data from a data block in a dirty state from the specified L1 cache source address and writes it to the allocated L2 cache destination address. After the operation is completed, it generates corresponding load or migration status information and returns it to the hardware management module through a dedicated communication interface. All management strategies for the L2 cache, such as replacement algorithms, data prefetching, and final persistent scheduling to non-volatile memory, are flexibly configured and executed by the software management module.

[0102] The first-level cache is located in high-speed volatile memory. Its storage space is organized into a set-associative structure, divided into S sets, each containing B fixed-size data blocks. The first-level cache is directly accessed and controlled by the hardware management module through hardware logic to provide nanosecond-level access latency.

[0103] The second-level cache, also located in high-speed volatile memory, has a significantly larger total capacity than the first-level cache. Managed by a software management module through system memory read / write operations, the second-level cache serves as a large-capacity backup buffer for the first-level cache. It is specifically used to temporarily store data in dirty data blocks replaced from the first-level cache, as well as pre-fetched data, thus forming a data migration chain within the volatile memory and avoiding direct access to slow, non-volatile memory.

[0104] The hardware management module and the software management module interact through a dedicated communication interface. This interface is used to transmit formatted commands and status information and is the key to achieving hardware and software collaboration.

[0105] Taking a read request cache miss as an example, the system workflow is as follows:

[0106] The host issues a read command, which is received by the command processing unit and stored in the host command queue. The address resolution unit parses the command address to obtain the group address and block tag. The status management unit queries the tag status memory, finds that the target block status is invalid, updates its status to loading, and instructs the coordination interface unit to initiate a load request. The coordination interface unit generates a load command and sends it to the software management module. The software management module parses the command and queries the second-level cache address mapping table; if a match is found, data is read from the second-level cache; otherwise, data is read from non-volatile memory. Subsequently, the software management module writes the data to the first-level cache destination address specified in the load command via DMA, generates load status information, and returns it. The coordination interface unit receives and parses this status information and forwards it to the status management unit. If the load status information indicates successful loading, the status management unit updates the target data block status to available and triggers the processing of original read commands waiting for this data block in the host command queue. Finally, the data is read from the first-level cache, returned to the host by the command processing unit, and the access is completed.

[0107] This embodiment also provides a computer device applicable to a multi-level cache implementation method for non-volatile storage data, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement all or part of the steps of the method described in the above embodiments of the present invention.

[0108] This embodiment also provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, it performs the method in any optional implementation of the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0109] The storage medium proposed in this embodiment and the data storage method proposed in the above embodiments belong to the same inventive concept. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0110] In summary, this invention proposes a multi-level caching implementation method and system suitable for non-volatile storage data. Through a collaborative hardware and software architecture, refined state control, critical path latency optimization, and efficient interaction mechanisms, a complete and efficient multi-level cache management scheme is constructed to reduce access latency, improve system throughput and resource utilization, and achieve more stable performance. Specifically, at the architectural level, the first-level cache is directly controlled by a dedicated hardware management module, achieving real-time, low-latency access and state maintenance through hardware circuitry. The second-level cache is dynamically managed by a software management module running on the main processor, supporting flexible policy configuration and large-capacity data temporary storage. This design combines the high performance of hardware with the strong scalability of software, achieving an effective balance between performance and flexibility. At the management logic level, by defining a state machine containing five states—invalid, loading, available, dirty data, and unloading—and clear transition rules, the entire lifecycle of data blocks is fully covered, providing clear operational guidelines for the hardware. Embedded consistency guarantee logic ensures data correctness and execution order when concurrent access and cache operations are intertwined. In critical path optimization, the loading mechanism is triggered only when a data block is invalid, avoiding invalid prefetching and improving cache resource utilization efficiency. Crucially, for data blocks to be replaced, an innovative strategy of prioritizing migration to the second-level cache is adopted. This transforms the high-latency operation that originally required writing to non-volatile storage into a data transfer process within volatile memory. Subsequent access to this data can be directly loaded from the second-level cache quickly, avoiding direct access to slow storage media, achieving latency masking and access acceleration. At the collaborative interaction level, the hardware management module and software management module collaborate efficiently and reliably through a dedicated communication interface based on a predefined interaction protocol. This mechanism ensures that hardware trigger requests and software execution feedback are transmitted accurately and with low overhead, guaranteeing smooth execution of cross-level operations and the reliability of the overall process. The synergistic effect of these mechanisms allows most data access to be completed within volatile memory, significantly reducing direct access to high-latency non-volatile storage. The second-level cache, acting as a dirty data buffer and persistent relay area, absorbs the replacement pressure from the first-level cache. It performs delayed merging and intelligent scheduling of the final persistent write operations, thereby avoiding the performance jitter caused by concentrated write-backs in traditional caches. While ensuring the basic performance minimum, it effectively improves the overall input / output processing capacity and resource utilization efficiency through flexible policy adaptation at the software layer.

[0111] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all 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.

Claims

1. A method for implementing a multi-level cache suitable for non-volatile data storage, characterized in that, The method comprises: a hardware management module managing the first-level cache, and a software management module managing the second-level cache. The received host command is parsed to obtain the location identifier of the target data block in the first-level cache; Based on the location identifier, query the status of the corresponding data block in the first-level cache; the status includes invalid, loading, available, dirty data, and unloading; dirty data indicates that the data in the data block has been modified by the host and is inconsistent with the underlying storage data. If the data block is invalid, a data load operation from the second-level cache or non-volatile memory to the first-level cache is triggered; If a data block in a dirty state needs to be replaced from the first-level cache, an operation is triggered to migrate the data block from the first-level cache to the second-level cache for temporary storage. The operation of triggering the migration of the data block from the first-level cache to the second-level cache for temporary storage includes: Generate a migration command; the migration command includes at least a command ID, a command type, the first-level cache source address where the data to be migrated is located, and the data length; the command type is migration. Based on the migration command, allocate the destination address for the second-level cache; The data to be migrated is moved from the source address of the first-level cache to the destination address of the second-level cache, and the status of the data block is updated to invalid after successful migration.

2. The method for implementing a multi-level cache suitable for non-volatile storage data according to claim 1, characterized in that, The triggering of a data load operation from the second-level cache or non-volatile memory to the first-level cache includes: Allocate a first-level cache destination address for the data loading operation and generate a loading command; the loading command includes at least a command ID, a command type, a source data address, and a first-level cache destination address; the command type is loading. Based on the load command, query the second-level cache address mapping table; If the data block is hit in the L2 cache, the data is read from the L2 cache and written to the destination address of the L1 cache; otherwise, the data is read from non-volatile memory and written to the destination address of the L1 cache.

3. The method for implementing a multi-level cache suitable for non-volatile storage data according to claim 2, characterized in that, If the data block is in the loading state, subsequent host commands that access the data block are cached until loading is complete; After successful loading, the status of the data block is updated to available or dirty data, and all cached host commands are processed.

4. The method for implementing a multi-level cache suitable for non-volatile data storage according to claim 3, characterized in that, The state update follows the following transition rules: The initial state of all data blocks is set to invalid; When accessing a data block that is in an invalid state, change the state of the data block to loading. Once a data block is successfully loaded, if the host command that triggered the loading is a read command, the data block's state is changed to available; if the host command that triggered the loading is a write command, the data block's state is changed to dirty data. When accessing a data block that is in an available state, if the host command that triggered the access is a read command, the state of the data block will remain available; if the host command that triggered the access is a write command, the state of the data block will be changed to dirty data. When a data block in a dirty data state is selected as the replacement object, the state of that data block is changed to unloading. Once a data block in the unloading state is successfully migrated from the first-level cache to the second-level cache, the state of the data block is changed to invalid. If the data block is accessed again before the migration is complete, its state is changed to dirty data.

5. The method for implementing a multi-level cache suitable for non-volatile data storage according to claim 1, characterized in that, It also includes migration abort and rollback mechanisms: If a data block in the unloading state is accessed again before the migration is complete, the migration process will be aborted. Roll back some data that has been migrated to the second-level cache to the first-level cache, and update the status of the data block to dirty data.

6. A multi-level cache implementation system suitable for non-volatile storage data, used to execute the multi-level cache implementation method for non-volatile storage data as described in any one of claims 1 to 5, characterized in that, include: The hardware management module is used to parse host commands, query the status of data blocks in the first-level cache, and trigger data loading or data migration operations based on the status. The software management module is used to respond to triggers from the hardware management module and perform data loading or data migration operations. The first-level cache is managed by the hardware management module; The second-level cache is managed by the software management module.

7. A multi-level cache implementation system suitable for non-volatile storage data according to claim 6, characterized in that, The capacity of the second-level cache is larger than that of the first-level cache; The hardware management module has an embedded state machine, which is used to realize the state transition and maintenance of data blocks; The hardware management module and the software management module interact with each other through a dedicated communication interface to exchange commands and status information in order to collaboratively achieve multi-level cache management.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the multi-level cache implementation method for non-volatile storage data as described in any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the multi-level cache implementation method for non-volatile storage data as described in any one of claims 1 to 5.

Images