Memory management method and memory controller

Abstract

The invention provides a memory management method and a memory controller, and aims to solve the problem of storage mismatch caused by dynamic change of a data access mode. The method comprises the following steps: acquiring target data stored in a target entity page in a plurality of entity pages; determining a data attribute of the target data and an offset attribute of the target entity page; and if the data attribute of the target data is not matched with the offset attribute of the target entity page, selecting a matched entity page of which the offset attribute is matched with the data attribute from the plurality of entity pages, and moving the target data from the target entity page to the matched entity page. Through the technical scheme of the invention, the memory controller can actively and periodically identify and correct the attribute mismatch between the stored data and the physical position thereof, and the continuous dynamic optimization of the data layout is realized, so that the data reliability and the overall performance of the storage device in the long-term use process are improved.

Description

Technical Field

[0001] This disclosure relates to the field of memory technology, and specifically to a memory management method and memory controller for storing and managing hot and cold data. Background Technology

[0002] Flash memory, as a non-volatile storage medium, is widely used in storage devices of various electronic devices due to its high storage density, low power consumption, and fast read speed. Flash memory adjusts its threshold voltage (Vth) by changing the charge of the floating gates in the memory cells, thus representing different data states. However, with the accumulation of program / erase (P / E) cycles and the extension of data retention time, the physical structure of the memory cells deteriorates, causing a shift in the threshold voltage distribution.

[0003] Specifically, critical voltage offset manifests in two main trends: one is a decrease in critical voltage due to charge loss, also known as left offset, which weakens the data retention capability of memory cells; the other is an increase in critical voltage due to charge trapping, also known as right offset, which increases the risk of program disturbance. If left-off offset pages store cold data, it accelerates the rate of data loss; if right-off offset pages store hot data, frequent access increases the residual electrons in the right-off offset pages, exacerbating data disorder. To address data read errors caused by critical voltage offset, existing memory controllers typically rely on error correction codes (ECC) for passive correction, but this increases read latency and system power consumption. Summary of the Invention

[0004] In view of this, existing technologies lack a mechanism for effectively managing dynamic changes in data attributes, which may lead to attribute mismatches between stored data and its physical storage location, thereby affecting the long-term reliability and performance of the storage device. This disclosure provides a memory management method and a memory controller. This solution can proactively identify and correct mismatched data stored in the memory module, continuously optimize the data layout through dynamic data migration, thereby solving the performance degradation and data loss risks caused by changes in data access patterns, improving the overall reliability of the storage device and extending its effective lifespan.

[0005] This disclosure provides one or more embodiments of a memory management method applied to a memory controller for controlling a storage device configured with a memory module. The method includes: acquiring target data stored in a target entity page among a plurality of entity pages; determining data attributes of the target data and offset attributes of the target entity page; if the data attributes and offset attributes of the target data do not match, selecting a matching entity page from the plurality of entity pages whose offset attributes match the data attributes; and moving the target data from the target entity page to the matching entity page.

[0006] This disclosure provides a memory controller in one or more embodiments for controlling a storage device configured with a memory module, the memory module including a plurality of physical pages. The memory controller includes: a memory interface control circuit electrically connected to the memory module; and a processor electrically connected to the memory interface control circuit, wherein the processor is configured to: acquire target data stored in a target physical page among the plurality of physical pages; determine data attributes of the target data and offset attributes of the target physical page; if the data attributes of the target data do not match the offset attributes, select a matching physical page from the plurality of physical pages whose offset attributes match the data attributes; and move the target data from the target physical page to the matching physical page.

[0007] Based on the above, the technical solution of this disclosure establishes a closed-loop, continuous data layout health monitoring mechanism by actively acquiring target data already stored in the target entity page and determining whether its data attributes match the offset attributes of the target entity page. Compared to existing technologies that only place data once during data writing, this disclosure can dynamically and periodically review the existing data within the storage system, ensuring that the rationality of the data layout is maintained throughout the entire lifecycle of the storage device. When a mismatch is identified, the target data is moved to a matching entity page with matching attributes, thus actively correcting the mismatch and avoiding the risk of data loss reintroduced due to changes in data attributes. Attached Figure Description

[0008] Figure 1 This is a block diagram of a host system and storage device according to embodiments of the present disclosure;

[0009] Figure 2 This is a flowchart illustrating a memory management method according to embodiments of the present disclosure;

[0010] Figure 3 This is a dynamic heat table and a schematic diagram of the heat table according to an embodiment of the present disclosure;

[0011] Figure 4 This is a schematic diagram of the critical voltage distribution of a single-level memory cell (SLC) according to an embodiment of the present disclosure;

[0012] Figure 5 This is a schematic diagram of the critical voltage distribution of a multi-level memory cell (MLC) according to embodiments of the present disclosure;

[0013] Figure 6 This is a schematic diagram of the critical voltage offset shown according to an embodiment of the present disclosure;

[0014] Figure 7 This is a flowchart illustrating a mismatch state identification method according to an embodiment of the present disclosure;

[0015] Figure 8 This is a flowchart illustrating a relocation decision-making method based on mismatch level according to an embodiment of this disclosure;

[0016] Figure 9 This is a timing diagram of the mismatch data identification and relocation decision-making process according to an embodiment of this disclosure;

[0017] Figure 10 This is a schematic diagram of an offset entity page list according to an embodiment of the present disclosure. Detailed Implementation

[0018] Reference will now be made in detail to exemplary embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. Wherever possible, the same component reference numerals are used in the drawings and description to denote the same or similar parts.

[0019] Figure 1 This is a block diagram illustrating a host system and storage device according to an embodiment of the present disclosure.

[0020] Please refer to Figure 1The host system 10 is, for example, a personal computer, a laptop computer, or a server. The host system 10 includes a processor 110 (also called a second processor), host memory 120 (also called host RAM), and a data transfer interface circuit 130. In this embodiment, the processor 110 is coupled (also called electrically connected) to the host memory 120 and the data transfer interface circuit 130. In another embodiment, the processor 110, host memory 120, and data transfer interface circuit 130 are electrically connected to each other via a system bus. In this embodiment, the processor 110, host memory 120, and data transfer interface circuit 130 may be located on the motherboard of the host system 10.

[0021] The storage device 20 includes a memory controller 210, a memory module 220 (also known as a rewritable non-volatile memory module), and a connection interface circuit 230. The memory controller 210 includes a processor 211 (also known as a first processor), a data management circuit 212, a memory interface control circuit 213, and a buffer memory 214.

[0022] In this embodiment, the host system 10 is electrically connected to the storage device 20 via a data transmission interface circuit 130 and a connection interface circuit 230 to perform data access operations. For example, the host system 10 can store data to or read data from the storage device 20 via the data transmission interface circuit 130.

[0023] In this embodiment, the number of data transmission interface circuits 130 can be one or more. Through the data transmission interface circuits 130, the motherboard can be electrically connected to the storage device 20 via wired or wireless means. The storage device 20 can be, for example, a USB flash drive, memory card, solid-state drive (SSD), or wireless storage device. The wireless storage device can be, for example, a Near Field Communication (NFC) storage device, a WiFi storage device, a Bluetooth storage device, or a Bluetooth Low Energy storage device (e.g., iBeacon), or other storage devices based on various wireless communication technologies. Furthermore, the motherboard can also be electrically connected via the system bus to various I / O devices such as a Global Positioning System (GPS) module, network interface card, wireless transmission device, keyboard, screen, and speaker.

[0024] In this embodiment, the data transmission interface circuit 130 and the connection interface circuit 230 are interface circuits compatible with the Peripheral Component Interconnect Express (PCI Express) standard. Furthermore, data transmission between the data transmission interface circuit 130 and the connection interface circuit 230 utilizes the Non-Volatile Memory Express (NVMe) communication protocol.

[0025] In another embodiment, the connection interface circuit 230 may be packaged in a chip with the memory controller 210, or the connection interface circuit 230 may be disposed outside a chip containing the memory controller 210.

[0026] In this embodiment, the host memory 120 is used to temporarily store instructions or data executed by the processor 110. In this embodiment, the host memory 120 may be Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), etc. However, it should be understood that this disclosure is not limited to this, and the host memory 120 may also be other suitable memories.

[0027] The memory controller 210 executes multiple logic gates or control instructions implemented in hardware or firmware, and performs corresponding data writing, data reading, and data erasure operations in the memory module 220 according to the instructions of the host system 10. In particular, the memory controller 210 implements a memory management method provided in this disclosure to actively identify and correct attribute mismatches between the data stored in the memory module 220 and its physical storage location, thereby achieving continuous dynamic optimization of the data layout.

[0028] More specifically, the processor 211 in the memory controller 210 is hardware with computing capabilities, used to control the overall operation of the memory controller 210. Specifically, the processor 211 is configured to execute the memory management method provided in this disclosure to obtain target data stored in a target entity page among multiple entity pages; then, the processor 211 determines the data attributes of the target data and the offset attributes of the target entity page; if the processor 211 determines that the data attributes of the target data do not match the offset attributes of the target entity page, it selects a matching entity page from the multiple entity pages whose offset attributes match the data attributes, and moves the target data from the target entity page to the matching entity page.

[0029] It is worth mentioning that, in this embodiment, the processor 110 and the processor 211 are, for example, a central processing unit (CPU), a microprocessor, or other programmable processing units (microprocessor), digital signal processor (DSP), programmable controller, application specific integrated circuits (ASIC), programmable logic device (PLD), or other similar circuit components, and this disclosure is not limited thereto.

[0030] In this embodiment, as described above, the memory controller 210 further includes a data management circuit 212 and a memory interface control circuit 213. It should be noted that the operations performed by each component of the memory controller 210 can also be considered as operations performed by the memory controller 210 itself.

[0031] The data management circuit 212 is electrically connected to the processor 211, the memory interface control circuit 213, and the connection interface circuit 230. The data management circuit 212 receives instructions from the processor 211 to perform data transmission. For example, it reads data from the host system 10 (e.g., host memory 120) via the connection interface circuit 230 and writes the read data into the memory module 220 via the memory interface control circuit 213. Alternatively, it performs a read operation according to a read instruction from the host system 10, reading data from one or more physical units of the memory module 220 via the memory interface control circuit 213 and writing the read data into the host system 10 via the connection interface circuit 230.

[0032] In another embodiment, the data management circuit 212 may also be integrated into the processor 211. The memory interface control circuit 213 is used to receive instructions from the processor 211 and, in conjunction with the data management circuit 212, to perform physical operations such as writing (also known as programming), reading, or erasing on the memory module 220.

[0033] Furthermore, data to be written to memory module 220 is converted into a format acceptable to memory module 220 via memory interface control circuit 213. Specifically, if processor 211 needs to access memory module 220, processor 211 transmits a corresponding instruction sequence to memory interface control circuit 213 to instruct memory interface control circuit 213 to perform the corresponding operation. For example, these instruction sequences may include write instruction sequences indicating the writing of data, read instruction sequences indicating the reading of data, erase instruction sequences indicating the erasure of data, and corresponding instruction sequences for indicating various memory operations. These instruction sequences may include one or more signals, or data on the bus. These signals or data may include instruction codes or program codes. For example, a read instruction sequence may include information such as the read identification code, memory address, and physical address.

[0034] Furthermore, the memory controller 210 establishes a logical-to-physical address mapping table and a physical-to-logical address mapping table to record the mapping relationship between the logical addresses of logical units (e.g., logical blocks, logical pages) and the physical addresses (physical addresses) of physical units (e.g., physical erase units / physical blocks, physical pages) configured for the memory module 220. In other words, the memory controller 210 can use the logical-to-physical address mapping table (also called the logical-to-physical mapping table) to find the physical unit mapped to a logical unit (e.g., find the physical page mapped to a logical page; find the physical address mapped to a logical address), and the memory controller 210 can use the physical-to-logical address mapping table (also called the physical-to-logical mapping table) to find the logical unit mapped to a physical unit (e.g., find the logical page mapped to a physical page; find the logical address mapped to a physical address).

[0035] It should be noted that the "physical address" mentioned in this disclosure is not limited to the absolute physical address on the memory chip. In practical applications, the memory controller 210 typically performs a bad block management mechanism. Therefore, the physical address in this embodiment can refer to a physical resource address that is visible to the controller logic after bad block mapping. The processor 211 builds an offset physical address list based on these managed valid addresses, thereby ensuring that data is not moved to a damaged physical area.

[0036] Buffer memory 214 is electrically connected to processor 211 and is used to temporarily store data and instructions from host system 10, data from memory module 220, and various system data for managing storage device 20. In embodiments of this disclosure, the core purpose of buffer memory 214 is to serve as the data and status management center for the memory management method of this invention. Specifically, processor 211 establishes and maintains multiple key data structures in buffer memory 214 to support the identification and correction process of mismatched data.

[0037] These data structures include: a dynamic heat table (e.g., Figure 3 T31 in the table is used to record the access count value corresponding to the logical address; a heat table (e.g., Figure 3 T32 in the table is used to record logical addresses with preset data attributes; an offset entity page list (e.g., Figure 10The BPL (Browser Page Address) is used to record the physical address of entity pages with left or right offset attributes; and a logical-to-entity address mapping table (L2P Table).

[0038] In another embodiment, to ensure data consistency after power failure, the aforementioned critical data structures stored in the volatile buffer memory 214 are persisted at specific times. Specifically, before the storage device 20 executes the shutdown procedure or enters a low-power state, the processor 211 writes the latest state of the dynamic heat table, heat table, offset entity page list, and logical-to-entity address mapping table from the buffer memory 214 to one or more reserved system areas of the non-volatile memory module 220. Accordingly, during the next power-on initialization of the storage device 20, the processor 211 first reloads these data structures from the reserved area of ​​the memory module 220 into the buffer memory 214 to restore the system's management state before power failure, thereby ensuring that the mismatch correction mechanism can continue to operate based on the latest and consistent data.

[0039] In some embodiments, for more granular management, the buffer memory 214 may store a list of offset entity pages, which records information about entity pages with left offset attributes (critical voltage tends to decrease) and right offset attributes (critical voltage tends to increase). Simultaneously, the buffer memory 214 may also store a list of offset entity blocks. When the number of multiple offset entity pages with the same offset attribute located in a certain entity block reaches an offset quantity threshold, the entity block and its offset attribute are recorded in this list. Furthermore, the buffer memory 214 may temporarily store soft information read from entity pages and intermediate data during the voltage offset identification process, such as logical likelihood ratio (LLR) values.

[0040] The memory module 220 is electrically connected to the memory controller 210 (specifically, the memory interface control circuit 213) and is used to store user data sent by the host system 10. The memory module 220 includes multiple physical blocks, each physical block consisting of multiple physical pages, and each physical page containing multiple storage cells. Each storage cell has an initial critical voltage value. As usage time increases, the critical voltage of the storage cell may shift left or right, causing the corresponding physical page to exhibit different offset attributes due to physical wear, such as left-off or right-off offset attributes. It should be noted that this disclosure is not limited to the specific capacity of the memory module 220 or the specific number of physical pages. The method of this disclosure continuously monitors and manages the data stored in these physical pages through the processor 211, ensuring that the data attributes always match the offset attributes of their respective physical pages, thereby improving the long-term reliability of the storage device 20. The offset attributes of the physical pages used to store the target data can be obtained through recorded data such as an offset physical page list.

[0041] To improve management efficiency, some technical solutions propose matching stored data based on the offset attributes of entity pages. For example, frequently accessed "hot data" is stored in entity pages that are prone to left offset, leveraging their frequent updates to combat data retention risks; while sparsely accessed "cold data" is stored in entity pages that are prone to right offset, avoiding the risk of programming interference.

[0042] However, the hot / cold attributes of data are not static but dynamically evolve over time and with changing application scenarios. Hot data, correctly placed during writing, may become cold data after a period of time due to decreased access frequency. This causes its current data attributes to no longer match the physical attributes of its corresponding left-offset page, resulting in a "mismatch." The reverse is also true. Current technologies generally lack effective mechanisms for monitoring and managing these dynamic changes in data attributes, leading to potential attribute mismatches between stored data and its physical storage location. This mismatch significantly diminishes the effectiveness of initial data placement optimizations and reintroduces the risk of data loss, thus impacting the long-term reliability and performance of the storage device. The following utilizes... Figure 2 The accompanying drawings will be used to illustrate in detail the memory management method provided in this disclosure, which can solve the problem of attribute mismatch.

[0043] Figure 2 This is a flowchart illustrating a memory management method according to embodiments of the present disclosure.

[0044] Reference Figure 2 In step S210, processor 211 acquires the target data stored in the target entity page among multiple entity pages. This step aims to collect the basic information required for mismatch judgment. Specifically, in one embodiment, since the correction process is a background scanning task, processor 211 does not target any specific user data, but systematically checks the stored data in memory module 220. In this embodiment, processor 211 can traverse the logical-to-entity address mapping table stored in buffer memory 214 and select valid mapping entries one by one as the target for inspection.

[0045] Next, in step S220, processor 211 determines the data attributes of the target data and the offset attributes of the target entity page. In one embodiment, processor 211 determines the data attributes by querying a dynamic heat table or a static heat table.

[0046] After determining the offset attribute of the target entity page, the process enters the judgment and decision stage. In step S230, the processor 211 determines whether the data attribute of the target data does not match the offset attribute of the target entity page. If the determination is that they do not match, the processor 211 selects a matching entity page from multiple entity pages whose offset attribute matches the data attribute of the target data.

[0047] In this embodiment, "mismatch" is a prerequisite for initiating subsequent risk assessment and relocation decisions. To ensure the accuracy of the judgment, the processor 211 defines what constitutes a "match" based on explicit technical rules. Specifically, the data attributes of the target data mainly include two types: hot data attributes and cold data attributes. The processor 211 determines the match by: the offset attribute matching the hot data attribute is a left offset attribute; while the offset attribute matching the cold data attribute is a right offset attribute.

[0048] For example, when processor 211 determines in step S220 that the data attribute of a target data is a "hot data attribute" and the offset attribute of its current target entity page is a "left offset attribute," processor 211 will determine that the two are a match. The technical principle behind this matching is that frequent read and write operations on hot data can periodically refresh the state of the storage unit, thereby effectively combating the problem of decreased data retention capability caused by charge loss in the left offset page. Similarly, when a target data is determined to be a "cold data attribute" and its target entity page is a "right offset attribute," it is also determined to be a match. The reason is that the long-term static and sparse writing characteristics of cold data can avoid the risk of right offset pages being susceptible to programming interference due to electronic traps.

[0049] Conversely, if any of the above matching conditions are not met, the processor 211 determines it as a mismatch. For example, a mismatch occurs when target data of a "hot data attribute" is found stored in an entity page of a "right offset attribute"; similarly, a mismatch occurs when target data of a "cold data attribute" is found stored in an entity page of a "left offset attribute". By providing such a clear and physically meaningful technical definition for the "data attribute" and "matching" relationship, the accuracy of subsequent mismatch identification and correction decisions is ensured.

[0050] After determining a mismatch, the processor 211 further performs a risk assessment. Specifically, the processor 211 determines the mismatch level of the target data based on the data attributes of the target data and the offset attributes of the target entity page. Subsequently, the processor 211 determines whether to prioritize moving the target data from the target entity page to the matching entity page based on the determined mismatch level and the current operating state of the storage device 20. This mechanism, which incorporates mismatch level and operating state as decision-making criteria, achieves an intelligent migration decision-making process that balances risk and system load.

[0051] In one specific implementation, the processor 211 determines the mismatch level according to the following rules: when the target data of a cold data attribute is stored in a target entity page with a left offset attribute, the mismatch level is determined to be the highest priority, the highest risk; when the target data of a hot data attribute is stored in a target entity page with a right offset attribute, it is determined to be the second highest priority, the second highest risk; and when the target data is stored in an entity page that does not have a left offset attribute or a right offset attribute (i.e., a standard entity page), it is determined to be a low priority. By assigning differentiated risk levels to different types of mismatch states, the processor 211 is able to quantitatively assess the urgency of each mismatch situation.

[0052] Processor 211 further determines that the first high priority is higher than the second high priority. Therefore, when multiple mismatched data exist, processor 211 will prioritize moving the first target data corresponding to the first high priority over the second target data corresponding to the second high priority. The reason for setting this priority is that entity pages with left offset attributes have weak data retention capabilities, and storing cold data that needs to be static for a long time in them will directly expose them to the risk of data loss. Prioritizing the movement of cold data that is at risk of data retention is a better strategy to ensure the overall data security of the system.

[0053] Finally, in step S240, the processor 211 moves the target data from the target entity page to the matching entity page. This step is performed based on the aforementioned judgment result, which combines the mismatch level and the operating state of the storage device.

[0054] Specifically, if the mismatch level determined by the processor 211 is the highest priority or the second highest priority, the processor 211 will prioritize moving the target data from the target entity page to the matching entity page. If the mismatch level determined by the processor 211 is low priority, the processor 211 will only move the target data from the target entity page to the matching entity page if the current operating state of the storage device 20 is idle; if the storage device 20 is busy, the move will not be performed. This differentiated execution strategy ensures that internal bandwidth resources are prioritized for handling high-risk mismatches, while avoiding interference from low-risk maintenance tasks on the user's foreground performance.

[0055] In some embodiments, to ensure that the responsiveness of the storage device 20 to the host system 10 is not affected, the entire mismatch correction process of this disclosure, including the data transfer operation in step S240, is designed to be executed as a background task within the memory controller 210.

[0056] Specifically, when processor 211 is performing a data transfer operation (e.g., reading target data from a target entity page), if memory controller 210 receives an I / O instruction from host system 10 via connection interface circuit 230, processor 211 will immediately suspend the currently executing background transfer task. During the suspension, processor 211 will save the current execution context or breakpoint information of the task (e.g., the number of data pages already transferred, the address of the next data to be processed, etc.) to buffer memory 214. Subsequently, processor 211 will allocate all necessary hardware resources, such as data management circuit 212 and memory interface control circuit 213, to prioritize processing the host I / O instruction. After the I / O instruction is processed, if processor 211 determines that the working state of storage device 20 has become idle again, it will read the previously saved breakpoint information from buffer memory 214 and resume the execution of the interrupted background transfer task from that breakpoint. Through this interruptible background task execution mechanism, the method of this disclosure can utilize idle system resources to continuously optimize the background data layout without affecting the user experience of the foreground.

[0057] In some embodiments, the memory management method of this disclosure is not executed continuously, but rather the processor 211 executes the step of acquiring the target data stored in the target entity page among multiple entity pages only when a preset condition is met, thereby initiating the process. Figure 2 The entire mismatch correction process is shown. This reduces system resource overhead.

[0058] Specifically, the preset conditions include one of the following: the total capacity of hot data stored in memory module 220 exceeds the hot data backlog threshold; and the total number of free entity pages with offset attributes among multiple entity pages exceeds the free offset page availability threshold.

[0059] For example, processor 211 can periodically monitor the system status in the background. When processor 211 queries the dynamic heat table and finds that the total capacity of logical addresses currently marked as hot data attributes exceeds a preset hot data backlog threshold, this may mean that there is a large amount of potential mismatch risk that will soon become "cold data" due to attribute changes. Based on this, processor 211 can trigger a correction process. As another example, when processor 211 queries the offset entity page list and finds that the system has accumulated a sufficient number of free offset entity pages that can be used for optimized migration (i.e., the total number exceeds the available free offset page threshold), this indicates that the system has the resource capacity to perform data layout optimization. Processor 211 can also trigger a correction process based on this. Through this system status-based, on-demand triggering mechanism, preventative data layout optimization can be performed when necessary, while avoiding unnecessary scanning when system resources are insufficient or optimization is not necessary, thus balancing system performance and maintenance overhead.

[0060] In summary, Figure 2 The illustrated process provides a systematic, closed-loop data layout correction method for this disclosure. By periodically executing steps S210 to S240, the memory controller 210 can proactively identify and correct attribute mismatch problems caused by dynamic changes in data access patterns. This method is no longer limited to a one-time static placement when data is first written, but ensures that stored data is always located in the physical area best suited to its current access characteristics through continuous monitoring and relocation. This continuous dynamic optimization can effectively avoid the data retention risks and performance bottlenecks reintroduced due to mismatch, thereby maintaining the rationality of the data layout throughout the entire lifecycle of the storage device and improving the long-term data reliability and overall durability of the storage device.

[0061] The following uses Figure 3 This section will explain in detail the heat tables mentioned above and similar dynamic heat tables.

[0062] Figure 3 This is a dynamic heat table and a schematic diagram of the heat table shown according to an embodiment of this disclosure. (Refer to...) Figure 3 In one embodiment, Figure 3 This disclosure provides a mechanism for determining the data attributes of target data, the mechanism being... Figure 2 One specific implementation of step S220 in the process. In this embodiment, the processor 211 mainly performs real-time calculation of data attributes through a dynamically maintained dynamic heat table T31.

[0063] Specifically, the dynamic heat table T31 is a data structure maintained in the buffer memory 214. It divides the logical address space into multiple units and records an access count value for each unit. When executing step S220 to determine data attributes, the processor 211 obtains the current access count value of the logical address corresponding to the target data and compares it with a preset heat threshold. As shown by the dashed arrow A33, if the processor 211 determines that the current access count value AC5 of logical address LBA5 is higher than the heat threshold, it determines that its data attribute is a hot data attribute. Conversely, as shown by the dashed arrow A34, if the processor 211 determines that the current access count value AC3 of logical address LBA3 is not higher than the heat threshold, it determines that its data attribute is a cold data attribute. This method of comparing access count values ​​with thresholds provides a reliable quantitative basis for dynamically determining data attributes.

[0064] To ensure that the access count accurately reflects the current access pattern of the data, the processor 211 executes a dynamic maintenance mechanism that includes accumulation and decay. As shown by arrow A31, when the processor 211 receives an I / O access operation pointing to a logical address, it increments the access count corresponding to that logical address in response to the access operation, reflecting the increase in heat. Furthermore, as shown by arrow A32, the processor 211 also periodically performs decay operations on all access count values ​​in the dynamic heat table T31 to simulate the natural cooling of heat. This periodic trigger can be triggered when the number of I / O instructions processed by the memory controller 210 reaches a preset instruction count threshold, or in response to the expiration of an internal timer's cycle. When triggered, the processor 211 uniformly performs decay operations to reduce all access count values. This dynamic maintenance mechanism, combining accumulation and decay, aims to focus heat assessment on access behavior within a sliding time window, rather than the historical accumulation over the entire lifecycle, thereby ensuring the timeliness and accuracy of data attribute judgment.

[0065] It should be noted that, in another embodiment, when executing step S220, processor 211 may determine data attributes using a hybrid strategy. Specifically, processor 211 first queries the heat table T32 stored in buffer memory 214. Heat table T32 is used to record the static attributes of data with inherent, predictable access patterns, such as internal system data. If processor 211 finds an entry corresponding to the target data in heat table T32 (e.g., based on its logical address or data type), it directly adopts its preset data attributes. If no corresponding entry is found in heat table T32 (which usually means the target data is user data), processor 211 will then use the aforementioned real-time calculation method based on dynamic heat table T31 to determine its data attributes.

[0066] In another embodiment, the data types that can be statically recorded in the heat table T32 will be further described. Specifically, the processor 211 can pre-define some metadata that is frequently accessed due to system operation needs as hot data attributes. For example, the logical-to-physical address mapping table data of the Flash Translation Layer (FTL) can be statically determined as a hot data attribute because it needs to be queried or updated in almost every I / O operation. Similarly, metadata used for Garbage Collection (GC), such as valid page bitmaps or block status tables, are also frequently read and written during GC operation and can also be pre-defined as hot data attributes.

[0067] Correspondingly, the processor 211 can also pre-define data with extremely low access frequency but extremely high data integrity requirements as cold data attributes. For example, firmware code or configuration information stored in the memory module 220 is typically loaded only once during the power-on initialization of the storage device and is rarely written thereafter, making it typical cold data. Similarly, the bad block table that records bad block information in flash memory, or the SMART log used for device health monitoring, has an update frequency far lower than the frequency of user data writing and can also be statically determined as cold data attributes. By pre-defining these data attributes with known access patterns in the heat table T32, the processor 211 can avoid unnecessary dynamic access counting of this data, thereby reducing system overhead and improving the efficiency of attribute determination.

[0068] In other embodiments, to achieve more refined data management, the processor 211 may employ a three-state model when determining data attributes. Specifically, the processor 211 may preset a hot threshold and a cold threshold, wherein the hot threshold is higher than the cold threshold. When the processor 211 obtains the access count value of the target data: if the count value is higher than the hot threshold, the data attribute is determined to be a hot data attribute; if the count value is lower than the cold threshold, the data attribute is determined to be a cold data attribute; if the count value is between the cold threshold and the hot threshold, the data attribute is determined to be a "warm data" attribute (as shown by the logical address LBA14 in the figure, a "normal" attribute). Under this three-state model, the definition and handling strategy of mismatch are also adjusted accordingly. For example, storing warm data in a standard entity page can be considered a matching state.

[0069] Figure 7 This is a flowchart illustrating a mismatch state identification method according to an embodiment of the present disclosure.

[0070] Reference Figure 7 In one embodiment, Figure 7The process details how the processor 211 systematically collects information and determines whether there is attribute mismatch in the target data after starting the mismatch correction process.

[0071] Specifically, in step S710, the processor 211 obtains the target logical address of the target data. As described in the previous embodiment, this target logical address may come from the processor 211's traversal scan of the logical-to-entity address mapping table. After obtaining the target logical address, the process enters a series of information query steps.

[0072] In step S720, processor 211 queries the dynamic heat table or heat table based on the target logical address to obtain the data attributes of the target data. This process is as described above. Figure 3 As described in detail in the embodiments, the processor 211 will eventually determine whether the data attribute of the target data is a hot data attribute or a cold data attribute.

[0073] Next, in step S730, the processor 211 queries the logic-to-entity address mapping table based on the target logical address to obtain the physical address where the target data is currently located, that is, the address of the target entity page.

[0074] Subsequently, in step S740, the processor 211 queries the offset entity page list based on the target physical address obtained in step S730 to obtain the target offset attribute of the corresponding target physical address, that is, the offset attribute of the target entity page.

[0075] After collecting all the above information, the process enters the core judgment step S750. Processor 211 determines whether the data attributes of the target data match the target offset attribute. Specifically, a match is defined as follows: when the data attribute is a hot data attribute and the offset attribute is a left offset attribute, or when the data attribute is a cold data attribute and the offset attribute is a right offset attribute, the two are considered a match. If the judgment result is yes, it means that the current data layout is reasonable, the process enters step S770, processor 211 does not perform any movement operation on the target data, and can continue to check the next target data.

[0076] If the judgment result in step S750 is negative, it means that processor 211 has identified a mismatch state, and the process then proceeds to step S760. In step S760, processor 211 determines the mismatch level of the corresponding target data based on the specific mismatch type. After determining the mismatch level, processor 211 uses this mismatch level in subsequent relocation decision-making processes, such as... Figure 8 This will be explained in detail.

[0077] Figure 8 This is a flowchart illustrating a relocation decision method based on mismatch level according to an embodiment of the present disclosure.

[0078] Reference Figure 8 In one embodiment, Figure 8 A flowchart illustrating a relocation decision-making method based on mismatch level provided in this disclosure. This process follows from... Figure 7 After determining that the target data is mismatched, the paper elaborates on how the processor 211 executes differentiated relocation strategies based on the risk level of the mismatch.

[0079] In step S810, the processor 211 determines the mismatch level between the corresponding target data and the storage address. Specifically, the processor 211 determines the mismatch level as high priority or low priority based on the specific mismatch type. In one specific implementation, when the processor 211 finds target data with a cold data attribute stored in a target entity page with a left offset attribute, it determines the mismatch level as the highest priority, the highest risk. When it finds target data with a hot data attribute stored in a target entity page with a right offset attribute, it determines the mismatch level as the second highest priority, the second highest risk. Furthermore, when the target data (whether hot or cold data attribute) is stored in an entity page that does not have a left or right offset attribute, the processor 211 determines the mismatch level as low priority.

[0080] Processor 211 further determines that the first high priority is higher than the second high priority. The reason for this priority setting is that physical pages with left offset attributes have weaker data retention capabilities and are at risk of data corruption due to charge loss. Storing cold data that needs to remain dormant for a long time in these pages directly exposes them to the risk of data loss, a serious threat to data integrity. In contrast, storing frequently accessed hot data in physical pages with right offset attributes mainly risks increased programming interference, which manifests more as a performance or write reliability issue. Therefore, when multiple mismatched data exist, processor 211 will prioritize moving the first target data corresponding to the first high priority over the second target data corresponding to the second high priority.

[0081] After determining the mismatch level, the process proceeds to different decision branches based on the level. If the mismatch level determined by processor 211 is high priority (i.e., first high priority or second high priority), the process proceeds to step S820. In this case, since the high-priority mismatch poses a direct threat to data integrity, processor 211 will prioritize the data migration operation. Specifically, processor 211 will select a new storage address (i.e., a matching entity page) based on the target data attributes to migrate the target data. For example, if the target data has a cold data attribute, processor 211 will select a free entity page with a right offset attribute from the offset entity page list as the new storage address and immediately initiate the data migration operation.

[0082] If the mismatch level determined by processor 211 in step S810 is low priority, the process proceeds to step S830. Although low-priority mismatches are not the optimal data layout, they pose a lower immediate risk to data integrity. Therefore, to avoid background data transfer operations affecting the foreground performance of the storage device, processor 211 adds an additional judgment step.

[0083] In step S830, the processor 211 determines whether the current operating state of the storage device is idle. If the determination result is yes, meaning the storage device is not currently processing any host I / O instructions, the process proceeds to step S820, where the processor 211 utilizes this idle window to select a new storage address and move the target data. If the determination result is no, meaning the storage device is currently in a busy state, the process proceeds to step S840, where the processor 211 determines not to move the target data this time, prioritizing the response to host instructions, and can re-evaluate the target data in subsequent check cycles. Through this differentiated decision-making mechanism, an effective balance is achieved between ensuring the security of critical data and maintaining the user experience.

[0084] The following uses multiple embodiments, in conjunction with Figures 4 to 6 This will illustrate how the offset entity page list is generated.

[0085] In one embodiment, processor 211 can generate or update the list of offset entity pages by performing a voltage offset identification operation to obtain the critical voltage offset trend of the entity pages. This operation aims to diagnose the physical health of the entity pages to determine their offset attributes, such as whether they generally tend towards a decreasing left offset or a increasing right offset. The operation can be triggered by a failed read operation or other preset conditions.

[0086] Specifically, when performing a voltage offset identification operation, the processor 211 first obtains the current critical voltage of each memory cell in the physical page. In one embodiment, this acquisition step can be implemented as follows: First, the processor 211 recovers the correct data stored in the physical page based on physical layer information (e.g., soft information obtained through soft decision reading); then, the processor 211 uses the recovered correct data as a logical reference and combines it with the physical layer information to calculate the current critical voltage of each memory cell.

[0087] After obtaining the current critical voltage of all memory cells, the processor 211 compares it with the initial critical voltage to determine the offset direction (left or right) of each cell. Finally, the processor 211 performs statistical analysis to determine whether the total number of memory cells in a certain offset direction dominates within the page (e.g., the number exceeds a preset threshold). If so, the processor 211 determines the overall offset attribute of that entity page as the dominant offset direction and records its information in the offset entity page list.

[0088] The following combination Figure 5 The specific implementation mechanism is illustrated by the critical voltage distribution of the multi-level memory cells shown. Figure 5 This is a schematic diagram of the critical voltage distribution of a multi-level memory cell (MLC) according to an embodiment of the present disclosure.

[0089] In one embodiment, the specific implementation of how processor 211 recovers correct data by combining physical layer information after a read failure, and ultimately determines the current critical voltage for each memory cell, will be further explained. When a regular hard-decision read operation fails due to too many errors, processor 211 instructs memory interface control circuitry 213 to perform a soft-decision read operation on the faulty physical page. A soft-decision read scans the memory cell by applying a series of fine voltage levels to obtain soft information that quantifies the reliability of data bits, such as the log-likelihood ratio (LLR) value. Processor 211 then inputs this soft information into its internal error-correcting code (ECC) decoder to perform a soft decoding operation, thereby recovering the original correct data stored in the physical page.

[0090] After successfully acquiring the correct data, the processor 211 can use this known correct data as a logical reference to go back and interpret the physical layer information initially obtained through soft decision reading. By combining the logically correct value with the physical layer voltage response information, the processor 211 can accurately infer the current critical voltage of each memory cell in the physical page, thereby providing accurate physical layer data for subsequent offset direction determination.

[0091] For example, refer to Figure 5 A memory cell that should be in state S2 (corresponding to data "00", initial critical voltage 2.5V) experiences a charge leakage that causes the actual critical voltage to drop to 1.9V. Consequently, during a hard-decision read, it is incorrectly read as state S1 (corresponding to data "01"), leading to decoding failure. In this situation, the processor 211 initiates a soft-decision read, for example, by applying a fine voltage sequence ranging from 1.8V to 2.2V near the 2V decision boundary, obtaining a read result vector (e.g., [1,0,0,0,0]). The processor 211 then calculates the LLR value based on this vector and corrects the erroneous data "01" back to the correct data "00" through soft decoding. Finally, the processor 211 combines the known correct logic state S2 with physical layer information indicating that the voltage inversion point is near 1.9V to ultimately determine the current critical voltage of the memory cell as 1.9V.

[0092] After obtaining the current critical voltage of each memory cell within a physical page, the processor 211 compares it with the initial critical voltage to determine the offset direction (left or right) of each cell. Subsequently, the processor 211 counts the number of cells with different offset directions. If the number of cells in a certain offset direction exceeds a preset threshold (e.g., half the total number of cells in the page), the processor 211 determines the overall offset attribute of that physical page as the dominant offset direction (e.g., left offset attribute) and records this information in the offset physical page list.

[0093] It should be noted that the above embodiments are described with respect to MLC storage units, but this disclosure is not limited thereto. For example, this disclosure is also applicable to SLC storage units.

[0094] It should be noted that the above embodiments are described with respect to MLC memory cells, but this disclosure is not limited thereto. For example, this disclosure is also applicable to SLC memory cells, and the principle of voltage offset identification is similar.

[0095] Reference Figure 4 , Figure 4 This is a schematic diagram of the critical voltage distribution of a single-level memory cell (SLC) according to an embodiment of the present disclosure. For an SLC type memory cell, the memory controller 210 distinguishes between state S0 (e.g., data "1") and state S1 (e.g., data "0") by setting a read reference voltage Vread.

[0096] In one embodiment, suppose an SLC memory cell that should be in state S1 (initial critical voltage 2.0V) has its actual critical voltage drop to 1.2V due to charge leakage. In this case, when the processor 211 performs a normal read operation, since 1.2V is lower than the read reference voltage Vread (e.g., 1.5V), the hard-decision read will incorrectly interpret it as state S0, outputting erroneous data "1", and ultimately causing ECC decoding failure.

[0097] After triggering the voltage offset identification operation, processor 211 also performs soft-decision reading and soft-decoding. Based on the fact that a hard decision misreads "0" as "1", processor 211 can infer that the actual critical voltage is lower than Vread, and therefore can focus a fine scan on the voltage range below 1.5V (e.g., 1.1V to 1.4V). By scanning to obtain the physical layer read result vector (e.g., [1,0,0,0]) and combining it with the correct logical layer data "0" recovered by soft decoding, processor 211 can infer that the current critical voltage of the cell is 1.2V. Finally, by comparing the current critical voltage (1.2V) with the initial critical voltage (2.0V), processor 211 can determine that the memory cell has experienced a "left offset". After completing this operation for all memory cells of the entire physical page, processor 211 can also determine the overall offset attribute of the physical page through statistical analysis.

[0098] Figure 6 This is a schematic diagram of the critical voltage offset shown according to an embodiment of the present disclosure.

[0099] Reference Figure 6 , Figure 6 The study demonstrates two typical scenarios after the critical voltage of a memory cell deviates from its initial distribution state.

[0100] Figure 6 The initial critical voltage distribution represents the standard critical voltage distribution state of the memory cells in memory module 220 when they are manufactured or used for the first time. This initial distribution exhibits a concentrated bell-shaped curve characteristic, indicating that the critical voltage of most memory cells is distributed around the design target value, exhibiting relatively stable voltage characteristics. This initial state provides an important benchmark reference for subsequent offset attribute identification. In one embodiment, the critical voltage value used for comparison with the current critical voltage can be a recorded standard critical voltage or a preset initial critical voltage.

[0101] For example, in one embodiment, the initial critical voltage value of each memory cell can be set at the factory according to the chip specifications of the memory module 220, so that the corresponding memory cell can be programmed with the required bit value. The initial critical voltage value can also represent the critical voltage value that each memory cell should have under ideal conditions.

[0102] Figure 6 The dashed curve on the left represents the "left offset attribute." This attribute indicates that the critical voltage distribution of physical page 220 generally tends to decrease. This situation is usually related to charge leakage in the floating gate of memory cell 230, and its main negative impact is a decrease in data retention capability. According to the method of this disclosure, physical page 220 with the left offset attribute will be preferentially used to store frequently accessed hot data.

[0103] Figure 6 The dashed curve on the right represents the "right offset attribute." This attribute indicates that the critical voltage distribution of the physical page 220 generally tends to increase. This situation is usually associated with the generation of electron traps in the tunnel oxide layer, and its main negative impact is a reduction in the programming window margin and an increase in sensitivity to programming disturbances. According to the method of this disclosure, the physical page 220 with the right offset attribute will be preferentially used to store cold data that needs to be stored for a long time.

[0104] Through the voltage offset identification operation disclosed herein, the processor 211 can accurately determine the offset trend of the critical voltage distribution for each physical page 220 that experiences a read failure, and assign it a corresponding offset attribute. This classification mechanism based on real physical states forms the management foundation for subsequent intelligent data placement.

[0105] In addition, in one embodiment, after performing the voltage offset identification operation, the processor 211 records the information of the identified offset entity page in an offset entity page list.

[0106] Figure 10 This is a schematic diagram of an offset entity page list according to an embodiment of the present disclosure.

[0107] Specifically, the Offset Entity Page Listing (BPL) may include the following fields:

[0108] (1) Physical address: This field is used to uniquely identify an entity page, and its format can be, for example, "entity block number_entity page number". For example, "B1_P1" means the first entity page belonging to entity block B1.

[0109] (2) Offset direction: This field records the offset attribute of the entity page. For example, "left" means that the entity page has a left offset attribute with the critical voltage tending to decrease, and "right" means that the critical voltage tends to increase.

[0110] (3) Availability Status: This field indicates whether the entity page is currently available for data write operations. For example, a value of "1" indicates availability, and a value of "0" indicates that it is occupied. It should be noted that the availability status field is optional; for example, in other implementations, the offset entity page list only contains the physical address and offset direction fields. The processor 211 can determine whether an offset entity page is available by looking up either the logical-to-entity address mapping table or the entity-to-logical address mapping table.

[0111] Figure 9 This is a timing diagram of the mismatch data identification and relocation decision-making process according to an embodiment of this disclosure.

[0112] Reference Figure 9 In one embodiment, Figure 9 This demonstrates how the memory controller 210, as the core execution entity, interacts with other key components over time to complete a full mismatch correction operation. The components involved in the interaction include: the memory controller 210, the Dynamic Heat Table (DHT), the Offset Entity Page List (BPL), and the memory module 220.

[0113] Specifically, in step S900, the process begins when a preset condition is met, and the memory controller 210 triggers a background mismatch correction process accordingly. This preset condition can be the satisfaction of the hot data backlog threshold or the available free offset page threshold as described in the previous embodiments.

[0114] After the process is triggered, the memory controller 210 begins executing a series of information queries and decisions targeting the target data. In step S910, the memory controller 210 sends a query request to the dynamic heat table DHT to obtain the data attributes of the target data. After processing the request, the dynamic heat table DHT returns the queried data attributes to the memory controller 210. In another embodiment, the dynamic heat table DHT can also be replaced by a static heat table (e.g., Figure 3 (T32). Next, in step S920, the memory controller 210 sends a query request to the offset entity page list BPL to obtain the entity page where the target data is currently located (i.e., the offset attribute of the target entity page). After processing the request, the offset entity page list BPL returns the corresponding offset attribute to the memory controller 210.

[0115] After obtaining the necessary information, the memory controller 210 internally executes step S930 to determine whether the obtained data attributes and offset attributes constitute a mismatch. If a mismatch is determined, in step S940, the memory controller 210 further determines the risk level of the mismatch, i.e., the mismatch level (e.g., high priority or low priority), based on the specific mismatch type.

[0116] Subsequently, the process enters a differentiated execution phase based on the mismatch level. In an optional process represented by an `alt` block, if the mismatch level determined by the memory controller 210 is high priority, then in step S950, the memory controller 210 determines to immediately perform the data transfer. Accordingly, in step S951, the memory controller 210 issues an instruction to the memory module 220 to perform a specific data transfer operation, for example, reading data from the target entity page and writing it to a matching entity page with a matching offset attribute. After the memory module 220 completes the operation, it returns a signal indicating that the transfer is complete to the memory controller 210.

[0117] In another optional flow represented by an `alt` block, if the mismatch level determined by the memory controller 210 is low priority, a further judgment of its own operating status will be introduced. In one branch of this flow, if the memory controller 210 determines that its current operating status is idle, then in step S960, it determines to perform the data transfer during the current idle window. Accordingly, in step S961, the memory controller 210 issues an instruction to the memory module 220 to perform the data transfer operation and receives a return signal after the operation is completed. In another branch, if the memory controller 210 determines that its current operating status is busy, then in step S970, it determines not to perform the data transfer for the time being, in order to prioritize the foreground tasks that caused the busy state.

[0118] pass Figure 9 The timing diagram illustrates a smart, efficient, and minimally impactful backend data layout optimization mechanism. Specifically, the timing diagram shows how the memory controller 210, as the decision-making core, systematically schedules internal resources and external hardware to complete a full mismatch diagnosis and correction. More importantly, this mechanism dynamically adjusts its execution strategy based on real-time assessment of mismatch risks (high / low priority), ensuring that backend data maintenance tasks are always executed at the most appropriate time. This achieves continuous data layout optimization while avoiding foreground performance fluctuations or increased latency caused by backend operations, ultimately improving the overall responsiveness of the storage device and the user experience.

[0119] In another embodiment, to improve the management efficiency of the offset entity page list, the processor 211 can execute an aggregation management strategy from the page level to the block level. Specifically, the processor 211 periodically scans the offset entity page list (BPL) in a background task. When the processor 211 finds that the number of entity pages located in a certain entity block and having the same offset attribute (e.g., all with left offset attribute) reaches a preset page number threshold, the processor 211 marks the entire entity block as an "offset entity block" with the same offset attribute and records its information in an independent offset entity block list. At the same time, the processor 211 can remove all independent entity page entries belonging to the aggregated entity block from the original offset entity page list. When performing subsequent data migration operations and needing to select a matching entity page for the target data, if the target data requires a storage location with a left offset attribute, the processor 211 can preferentially select an offset entity block marked with a left offset attribute from the offset entity block list and find an available free entity page within that block as the matching entity page. This aggregation management mechanism reduces the number of entries in the list, thereby reducing storage overhead and query complexity.

[0120] In another embodiment, when processor 211 performs an erase operation on a physical block (e.g., after garbage collection), it first queries the offset attribute of the physical block. Based on the queried offset attribute, processor 211 employs a differentiated erase voltage or timing strategy. Specifically, if processor 211 determines that the target physical block has a right offset attribute, considering that the memory cells of this type of block may contain residual electrons that are difficult to remove due to electron traps, processor 211 instructs memory interface control circuit 213 to employ a "forceful erase" strategy. This strategy may include increasing the initial erase voltage, increasing the magnitude of the voltage step, or extending the duration of each erase pulse to ensure that residual electrons are completely removed, thereby attempting to restore the critical voltage distribution of the block. Conversely, if processor 211 determines that the target physical block has a left offset attribute, considering that the tunnel oxide layer of this type of block may be relatively fragile, processor 211 employs a "gentle erase" strategy. This strategy may include reducing the initial erase voltage or slowing down the voltage step size to avoid further physical damage to the memory cells caused by applying an excessively strong electric field. Through this adaptive, differentiated erase strategy, the processor 211 can perform targeted physical maintenance on physical blocks in different health states while performing regular erase operations, thereby helping to mitigate their aging process and extend the overall effective lifespan of the memory module 220.

[0121] In another embodiment, processor 211 can optimize the heat determination mechanism based on the principle of temporal locality. The principle of temporal locality states that recently written or modified data has a high probability of being accessed again in the short term. To utilize this characteristic, when performing a write operation, processor 211, in addition to normally accumulating the access count value of its respective heat statistics unit, can also provide a temporary, additional "heat boost" (e.g., adding an extra access count value greater than 1, i.e., N) for the specific logical address range involved in the write operation. This heat boost is a temporary count increase, and its effect diminishes rapidly with subsequent periodic decay operations (e.g., using a shorter decay period or using the concept of half-life to reduce the heat boost). Through this write operation-triggered instant heat boost mechanism, it can be ensured that newly written data will not be immediately and incorrectly classified as cold data because its macroscopic region is generally cold, thus providing a time window for its true heat attribute to be proven through subsequent actual accesses, avoiding unnecessary and premature mismatch judgments.

[0122] In another embodiment, the method of this disclosure can be further upgraded from reactive correction to predictive management. Specifically, processor 211 not only focuses on the current value of the access count in the dynamic heat table, but also on its trend of change, i.e., the "temperature gradient". To achieve this function, processor 211 can maintain historical count values ​​for each heat statistics unit over the past few decay cycles in buffer memory 214. By comparing these historical values, processor 211 can calculate the rate of change of the access count value for each unit. When processor 211 finds a target data whose current data attribute is still hot data, and whose access count value has shown a continuous and rapid downward trend over the past few cycles (i.e., with a large negative gradient), processor 211 can predict that the target data will soon become cold data in the future. Accordingly, even if the target data does not yet constitute an actual mismatch, processor 211 can "predictively" move it from an entity page with a left offset attribute to a standard entity page or an entity page with a right offset attribute in advance at a suitable system idle time. This temperature gradient-based predictive data migration upgrades the mismatch correction mechanism from "passive response" to "active prediction," helping to smooth the system load of background migration tasks and reduce the occurrence of mismatch states from the source.

[0123] In another embodiment, the method of this disclosure can be further extended to provide differentiated data protection and reading strategies for data in a mismatched state. Specifically, when the processor 211 has to perform a mismatched write under certain special circumstances (e.g., due to a lack of matching free entity pages), or when an existing mismatched data is identified in a background scan, the processor 211 can provide additional enhanced protection for the data. For example, when the processor 211 needs to write target data of a cold data attribute to an entity page with a left offset attribute, it can dynamically apply an error correction code (ECC) encoding with stronger strength and error correction capability than the standard configuration to the data while performing the write operation.

[0124] On the other hand, when performing a read operation on target data known to be in a mismatched state, the processor 211 can employ an adaptive read retry strategy. For example, when reading data from a physical page with a right offset attribute fails, considering that the critical voltage of such pages tends to increase, the processor 211 will prioritize trying preset read reference voltage sequences that offset to higher voltages when performing read retry. In this way, the system can provide dynamic and targeted enhanced protection and intelligent recovery strategies for data known to be in a higher-risk state, thereby ensuring data integrity and readability even when relocation correction cannot be performed immediately.

[0125] It should be noted that in other embodiments, the processor 211 can also periodically assess the system's current "resource requirements" for different types of free blocks. For example, if the processor 211 discovers through a dynamic heat table that a large amount of data has become hot data attributes and is in a mismatched state, it can determine that the system urgently needs free blocks with left offset attributes. Accordingly, when the garbage collection mechanism is activated, the processor 211 adjusts its block selection algorithm, prioritizing the selection of a suitable block from those entities marked as having "left offset attributes." In this way, the garbage collection operation not only reclaims invalid space but also proactively and purposefully "creates" the type of free block resource most needed by the system. This differentiated block selection strategy transforms background garbage collection from passive space organization to proactive resource supply optimization, thereby improving the efficiency of subsequent data movement or write operations.

[0126] In one embodiment, the triggering condition for garbage collection is not limited to the amount of available space. Processor 211 can be configured to periodically scan memory module 220 in the background to count the number of valid data whose offset attributes do not match their data attributes. When processor 211 detects that the amount of data in a high-risk mismatch state (e.g., cold data stored at a left offset entity address) exceeds a preset data amount threshold, processor 211 will proactively trigger a garbage collection operation primarily for "health maintenance," even if the available space is still sufficient. This "preventive GC triggering mechanism" based on mismatch states elevates garbage collection from a passive space management tool to a proactive system health management tool.

[0127] It should be noted that the mismatch handling mechanism described in this disclosure can be implemented during GC to reduce the load and wear on the system, or more proactively scanned and executed to thoroughly maintain data storage security.

[0128] In one embodiment, processor 211 may execute a preventative triggering mechanism based on "temperature changes." Specifically, processor 211 periodically acquires the current operating temperature of storage device 20 via an onboard temperature sensor. When processor 211 detects that the operating temperature remains above a preset safe temperature threshold, it proactively triggers a garbage collection operation aimed at "data retention enhancement." During this GC, processor 211's source block selection algorithm will particularly prioritize blocks containing a large amount of cold data, especially those blocks containing cold data that has been mismatched in left-offset block addresses.

[0129] For example, suppose a solid-state drive (SSD) is installed in a poorly cooled laptop, and its internal temperature consistently exceeds 70°C during high-load tasks. Upon detecting this state, processor 211 immediately initiates a preventative garbage collection (GC). It prioritizes reclaiming physical blocks containing user archive files (cold data) with left offset attributes, and uses the intelligent relocation mechanism disclosed herein to relocate these archive files to physical blocks with right offset attributes and stronger data retention capabilities. This mechanism proactively protects the most vulnerable data before high temperatures accelerate charge leakage and pose a substantial threat to data integrity.

[0130] This embodiment also provides a computer program product, including computer-readable code or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is executed in a processor, the processor performs the steps of the memory management method described above. This computer program product can be implemented specifically through hardware, firmware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied as a computer storage medium; in another optional embodiment, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0131] It should be understood that although the foregoing embodiments are mainly described using "entity pages" as the basic unit for target data storage, offset attribute recording, and popularity statistics, this is only an exemplary implementation of this disclosure and does not constitute a limitation on the scope of protection of this disclosure.

[0132] Specifically, those skilled in the art can adjust the granularity of each operation unit of this disclosure according to actual application requirements, the characteristics of the storage medium, or available hardware resources. For example, the scope of "target data" may not be limited to the data volume of a single physical page, but may be a data unit smaller than a physical page (e.g., a sector or a group of error correction codewords), or a data unit larger than a physical page (e.g., a superpage consisting of multiple consecutive physical pages).

[0133] Correspondingly, the management granularity of the "Offset Entity Page List" used to record offset attributes can also be adjusted. For example, it can record finer-grained, subpage-level offset attributes, or it can record more macroscopic, overall offset attributes on a per-entity-block basis. Similarly, the logical address space size (e.g., 4MB) corresponding to the "heat statistics unit" of the "dynamic heat table" used for access statistics is also configurable and can be set to a larger or smaller address range depending on the required heat identification accuracy and available buffer memory resources.

[0134] In summary, the core idea of ​​this disclosure is to identify and correct mismatches between "data attributes" and their "physical storage location attributes," and the specific operational granularity for such identification and correction (whether at the page level, block level, or subpage level) falls within the scope of protection claimed by this disclosure.

[0135] In summary, the memory management method and memory controller provided in this disclosure solve the problem of unreasonable storage layout caused by dynamic changes in data access patterns in the prior art by establishing an active, closed-loop mismatch data correction mechanism.

[0136] The technical solution disclosed herein triggers a background scan in response to preset conditions, actively acquiring target data already stored in the target entity page and determining whether its dynamically determined data attributes match the offset attributes of the target entity page. This mechanism enables the memory controller to continuously monitor the health of existing data, rather than simply placing it once during data writing. When a mismatch is identified, the target data is moved to a matching entity page with matching attributes, thus proactively correcting the mismatch and avoiding the risk of data loss or performance bottlenecks reintroduced due to changes in data attributes, maintaining the rationality of the data layout throughout the entire lifecycle of the storage device.

[0137] Specifically, this disclosure uses a dynamic maintenance mechanism that includes access accumulation and periodic decay operations to determine the data attributes of target data. This mechanism ensures that the judgment of data hot / cold attributes accurately reflects its actual access pattern within the current time window, avoiding the problem of historical hot data permanently occupying hot data labels, and providing a reliable and real-time decision-making basis for identifying mismatch states.

[0138] Furthermore, this disclosure achieves intelligent risk management by introducing mismatch level assessment and differentiated execution strategies based on mismatch levels. The processor can distinguish the risk levels of different mismatch types (e.g., the highest priority is higher than the second highest priority) and prioritize using limited internal bandwidth resources to handle high-risk mismatches that pose the most direct threat to data integrity. For lower-risk mismatches, an opportunistic strategy is adopted, executing only when the system is idle. This differentiated decision-making mechanism achieves an effective balance between ensuring critical data security and maintaining user experience, ultimately improving the long-term data reliability, overall durability, and user responsiveness of the storage device.

[0139] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this disclosure, and not to limit them; although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure.

Claims

1. A memory management method applied to a memory controller, the memory controller being used to control a storage device configured with a memory module, characterized in that, The method includes: Retrieve the target data stored within the target entity page across multiple entity pages; Determine the data attributes of the target data and the offset attributes of the target entity page; If the data attribute of the target data does not match the offset attribute, select a matching entity page from the plurality of entity pages whose offset attribute matches the data attribute; and Move the target data from the target entity page to the matching entity page.

2. The method according to claim 1, characterized in that, The data attributes used to determine the target data include: Obtain the access count value of the logical address corresponding to the target data; and The access count value is compared with a heat threshold to determine whether the data attribute of the target data is a hot data attribute or a cold data attribute.

3. The method according to claim 2, characterized in that, The method further includes: In response to an access operation to the logical address, the access count value is incremented; and When the number of I / O instructions processed by the memory controller reaches the instruction count threshold, a decay operation is performed to reduce the access count value.

4. The method according to claim 2, characterized in that, The method further includes: In response to an access operation to the logical address, the access count value is incremented; and In response to the expiration of the timing period, a decay operation is performed to reduce the access count value.

5. The method according to claim 1, characterized in that, The method further includes: In response to the fulfillment of preset conditions, the step of obtaining the target data stored in the target entity page among the plurality of entity pages is then executed.

6. The method according to claim 5, characterized in that, The preset conditions include one of the following: The total capacity of the hot data stored in the memory module exceeds the hot data backlog threshold; and The total number of idle entity pages with offset attributes among the multiple entity pages exceeds the threshold for available idle offset pages.

7. The method according to claim 1, characterized in that, The data attributes of the target data include one of the following attributes: Hot data attributes, wherein the offset attribute matching the hot data attribute is a left offset attribute; and Cold data attributes, wherein the offset attribute matching the cold data attribute is a right offset attribute.

8. The method according to claim 1, characterized in that, If the data attribute of the target data does not match the offset attribute, the method further includes: Determine the mismatch level between the data attribute of the target data and the offset attribute of the target entity page; and Based on the mismatch level and the operating status of the storage device, it is determined whether to prioritize moving the target data from the target entity page to the matching entity page.

9. The method according to claim 8, characterized in that, The determination of the mismatch level between the data attribute of the target data and the offset attribute of the target entity page includes: When the data attribute of the target data is a cold data attribute and the offset attribute is a left offset attribute, the mismatch level of the target data is determined to be the first high priority. When the data attribute of the target data is a hot data attribute and the offset attribute is a right offset attribute, the mismatch level of the target data is determined to be the second highest priority; and When the data attribute of the target data is a hot data attribute or a cold data attribute, and the target entity page is not a left offset attribute or a right offset attribute, the mismatch level of the target data is determined to be low priority.

10. The method according to claim 9, characterized in that, The step of determining whether to prioritize moving the target data from the target entity page to the matching entity page based on the mismatch level and the operating status of the storage device includes: If the mismatch level is the first high priority or the second high priority, the target data is preferentially moved from the target entity page to the matching entity page; and If the mismatch level is low priority, when the working state of the storage device is idle, the target data is moved from the target entity page to the matching entity page.

11. The method according to claim 9, characterized in that, The first high priority is higher than the second high priority, and the method further includes: Compared to the second target data corresponding to the second highest priority, the first target data corresponding to the first highest priority is moved first.

12. A memory controller for controlling a storage device configured with a memory module, the memory module comprising a plurality of physical pages, characterized in that, The memory controller includes: A memory interface control circuit, for electrically connecting to the memory module; and A processor, electrically connected to the memory interface control circuit, wherein the processor is configured to: Retrieve the target data stored within the target entity page across multiple entity pages; Determine the data attributes of the target data and the offset attributes of the target entity page; If the data attribute of the target data does not match the offset attribute, select a matching entity page from the plurality of entity pages whose offset attribute matches the data attribute; and Move the target data from the target entity page to the matching entity page.

13. The memory controller according to claim 12, characterized in that, The data attributes used to determine the target data include: Obtain the access count value of the logical address corresponding to the target data; and The access count value is compared with a heat threshold to determine whether the data attribute of the target data is a hot data attribute or a cold data attribute.

14. The memory controller according to claim 13, characterized in that, The processor is also configured to: In response to an access operation to the logical address, the access count value is incremented; and When the number of I / O instructions processed by the memory controller reaches the instruction count threshold, a decay operation is performed to reduce the access count value.

15. The memory controller according to claim 13, characterized in that, The processor is also configured to: In response to an access operation to the logical address, the access count value is incremented; and In response to the expiration of the timing period, a decay operation is performed to reduce the access count value.

16. The memory controller according to claim 12, characterized in that, The data attributes of the target data include one of the following attributes: Hot data attributes, wherein the offset attribute matching the hot data attribute is a left offset attribute; and Cold data attributes, wherein the offset attribute matching the cold data attribute is a right offset attribute.

17. The memory controller according to claim 12, characterized in that, If the data attribute of the target data does not match the offset attribute, the processor is further configured to: Determine the mismatch level between the data attribute of the target data and the offset attribute of the target entity page; as well as Based on the mismatch level and the operating status of the storage device, it is determined whether to prioritize moving the target data from the target entity page to the matching entity page.

18. The memory controller according to claim 17, characterized in that, The determination of the mismatch level between the data attribute of the target data and the offset attribute of the target entity page includes: When the data attribute of the target data is a cold data attribute and the offset attribute is a left offset attribute, the mismatch level of the target data is determined to be the first high priority. When the data attribute of the target data is a hot data attribute and the offset attribute is a right offset attribute, the mismatch level of the target data is determined to be the second highest priority; and When the data attribute of the target data is a hot data attribute or a cold data attribute, and the target entity page is not a left offset attribute or a right offset attribute, the mismatch level of the target data is determined to be low priority.

19. The memory controller according to claim 18, characterized in that, The step of determining whether to prioritize moving the target data from the target entity page to the matching entity page based on the mismatch level and the operating status of the storage device includes: If the mismatch level is the first high priority or the second high priority, the target data is preferentially moved from the target entity page to the matching entity page; and If the mismatch level is low priority, when the working state of the storage device is idle, the target data is moved from the target entity page to the matching entity page.

20. The memory controller according to claim 18, characterized in that, The first high priority is higher than the second high priority, and the processor is further configured to: Compared to the second target data corresponding to the second highest priority, the first target data corresponding to the first highest priority is moved first.

Images