Memory management method and memory controller

Abstract

The invention provides a memory management method and a memory controller. The method comprises the steps of determining a to-be-recycled source entity block in garbage recycling operation, and obtaining data attributes of effective data of the source entity block; selecting a target entity address with an offset attribute matched with the data attribute from a plurality of entity addresses based on the data attribute of the effective data; and moving the valid data to the target entity address. According to the method, the data attribute is matched with the offset attribute of the entity address, the inherent data migration process of garbage collection is utilized, continuous optimization of the data layout is achieved, the problem of data mismatching possibly caused by blind migration in traditional garbage collection operation is solved, and the efficiency of data distribution is improved. Therefore, the overall data reliability and the service life of the storage device are improved.

Description

Technical Field

[0001] This disclosure relates to the field of memory technology, and in particular to a memory management method and memory controller for garbage collection operations. Background Technology

[0002] Flash memory, as a non-volatile storage medium, is widely used in various storage devices due to its high storage density, low power consumption, and fast read / write speeds. Flash memory adjusts its threshold voltage (Vth) by changing the charge of the floating gate within the memory cell, thereby representing different data states.

[0003] However, as the number of program / erase (P / E) cycles accumulates and the data retention time increases, the physical structure of the memory cell gradually deteriorates, causing a shift in its critical voltage distribution. Specifically, the critical voltage shift manifests in two main trends: one is a decrease in critical voltage due to charge loss (also known as left shift), which weakens the data retention capability of the memory cell; the other is an increase in critical voltage due to charge trapping (also known as right shift), which increases the risk of program disturbance.

[0004] To reclaim physical space occupied by invalid data, storage devices need to periodically perform garbage collection (GC) operations. The core step of garbage collection is moving valid data from one or more physical blocks to a new, erased physical block. However, existing garbage collection mechanisms often perform this data movement blindly. Specifically, the memory controller only cares about the validity of the data, without considering the access characteristics of the data to be moved (e.g., hot or cold data). This blind movement can unintentionally create new data layout risks. Summary of the Invention

[0005] In view of this, existing garbage collection mechanisms lack awareness of data attributes and physical location characteristics, potentially introducing new data reliability risks during background maintenance. To address these issues, this disclosure provides a memory management method and memory controller that deeply integrates intelligent data placement strategies into garbage collection operations. By identifying the data attributes of valid data during the data movement phase of garbage collection and selecting target entity addresses with matching physical offset attributes, this disclosure transforms conventional garbage collection tasks into a proactive and intelligent data layout optimization process. This avoids data mismatches caused by blind movement, achieves continuous optimization of data layout throughout the entire lifecycle of the storage device, and thus improves overall data reliability and durability.

[0006] This disclosure provides one or more embodiments of a memory management method applied to a memory controller of a memory device configured with a memory module, the memory module including multiple physical blocks. The method includes: determining a source physical block to be reclaimed from the multiple physical blocks, and obtaining data attributes of valid data from the source physical block; selecting a target physical address with an offset attribute matching the data attributes from multiple physical addresses of the multiple physical blocks based on the data attributes of the valid data; and moving the valid data to the target physical address.

[0007] 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 blocks. 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. The processor is configured to: determine a source physical block to be reclaimed from the plurality of physical blocks, and obtain data attributes of valid data from the source physical block; based on the data attributes of the valid data, select a target physical address having an offset attribute matching the data attributes from a plurality of physical addresses of the plurality of physical blocks; and move the valid data to the target physical address.

[0008] Based on the above, the memory management method and memory controller provided in this disclosure can achieve the following technical effects:

[0009] First, by determining the data attributes of valid data from the source entity blocks to be recycled during the garbage collection operation, the memory controller can acquire key information for optimization decisions within the inherent data movement process. This transforms what was originally a blind background maintenance operation into a data-aware optimization opportunity, providing the necessary foundation for subsequent intelligent placement without introducing additional scanning overhead.

[0010] Next, based on this data attribute, target entity addresses with matching offset attributes are selected, ensuring that data with different characteristics can be placed in the physical region best suited to their access patterns. Specifically, frequently accessed hot data is directed to entity addresses that are more resistant to frequent reads and writes (e.g., entity addresses with left offset attributes), while cold data that needs to remain idle for a long time is directed to entity addresses with stronger data retention capabilities (e.g., entity addresses with right offset attributes). This matching strategy can effectively mitigate the negative impact of different physical wear and tear mechanisms on data reliability.

[0011] Ultimately, by moving valid data to the selected target entity address, this disclosure substantially transforms garbage collection, a routine background maintenance task, into a proactive and intelligent data layout optimization process. Compared to existing technologies that only place data during the initial write, the method of this disclosure can continuously and cost-effectively correct and optimize the data layout throughout the entire lifecycle of the storage device, taking advantage of garbage collection opportunities, thereby effectively improving the long-term data reliability and overall lifespan of the storage device. Attached Figure Description

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

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

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

[0015] Figure 4A This is a logic flowchart for selecting a target entity address according to an embodiment of the present disclosure;

[0016] Figure 4B This is a schematic diagram of the data transfer logic of the source entity block according to an embodiment of this disclosure;

[0017] 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;

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

[0019] Figure 7 This is a logic flowchart for determining a source entity block according to another embodiment of the present disclosure;

[0020] Figure 8This is a flowchart illustrating a method for selecting target entity addresses to achieve wear leveling, according to yet another embodiment of this disclosure.

[0021] Figure 9 This is an interaction timing diagram of the memory management method according to embodiments of the present disclosure;

[0022] Figure 10 This is a schematic diagram of the data structure of the offset entity address list according to an embodiment of this disclosure;

[0023] Figure 11 This is a schematic diagram of an offset entity address list sorted based on historical usage count values, according to an embodiment of this disclosure. Detailed Implementation

[0024] 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.

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

[0026] Please refer to Figure 1 The 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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. Specifically, the memory controller 210 implements a memory management method provided in this disclosure. During garbage collection, this method intelligently matches the data attributes of valid data with the offset attributes of the target entity address, transforming a conventional garbage collection task into an active data layout optimization process, thereby improving the long-term reliability of the storage device 20.

[0034] More specifically, the processor 211 in the memory controller 210 is a piece of 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. In a garbage collection operation, the processor 211 determines the source block to be reclaimed from multiple physical blocks of the memory module 220 and obtains the data attributes of the valid data of the source physical block. Then, based on the data attributes of the valid data, the processor 211 selects a target physical address with an offset attribute matching the data attributes from multiple physical addresses of the memory module 220. Finally, the processor 211 controls the movement of the valid data to the target physical address.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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).

[0041] 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 intelligent decision-making during garbage collection operations.

[0042] These data structures include: one or more heat tables for determining data attributes (e.g., Figure 3 The dynamic heat table T31 and static heat table T32 in the data; and an offset entity address list (e.g., Figure 10In the context of BPL (Body Leveling Program), the Offset Entity Address List is used to record multiple entity addresses and their corresponding offset attributes. In some embodiments, the Offset Entity Address List may also record a historical usage count value corresponding to each entity address for wear leveling purposes.

[0043] In one embodiment, when determining the data attributes of target data, the processor 211 first queries the heat table (T32). If the logical address corresponding to the target data exists in the heat table, the processor 211 directly adopts its preset data attributes. Specifically, the preset data attributes can be statically determined based on the inherent function or type of the data. For example, some metadata that is frequently accessed due to system operation needs, such as the mapping table data of the flash translation layer (FTL) or garbage collection (GC) metadata, can be preset as hot data attributes and recorded in the static heat table (T32); correspondingly, some data with extremely low access frequency, such as firmware code or bad block information tables, can be preset as cold data attributes.

[0044] In one embodiment, if the logical address corresponding to the target data does not exist in the static heat table (T32), the processor 211 dynamically determines the data attributes (e.g., hot data attributes or cold data attributes) of the target data by performing periodic accumulation and decay operations on the access count value in the dynamic heat table (T31). Subsequently, the processor 211 combines the logical-to-entity address mapping table and the offset entity page list to obtain the offset attribute of the entity page where the target data is currently located, thereby determining whether a mismatch exists. In addition, the buffer memory 214 is also used to store intermediate state information of the processor 211 during the process of determining the mismatch level and determining whether to perform a relocation.

[0045] In some embodiments, for more granular management, the buffer memory 214 may store a list of offset entity addresses, which records entity addresses (including entity addresses of corresponding entity pages and / or entity blocks) with a first offset attribute (critical voltage tends to decrease, left offset attribute) and a second offset attribute (critical voltage tends to increase, right offset attribute). Furthermore, the buffer memory 214 may also temporarily store soft information read from entity pages and intermediate data during the voltage offset identification process, such as logical likelihood ratio (LLR) values.

[0046] 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 memory cells. Each memory cell has an initial critical voltage value. As usage time increases, the critical voltage of the memory cell may shift left or right, causing the corresponding physical address to exhibit different offset attributes due to physical wear, such as left or right 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 addresses. The method of this disclosure uses the processor 211 to continuously monitor and manage the data stored in these physical addresses, ensuring that the data attributes always match the offset attributes of their respective physical addresses, thereby improving the long-term reliability of the storage device 20. The offset attributes of the physical addresses used to store the target data can be obtained through records such as an offset physical address list.

[0047] In some embodiments of this disclosure, processor 211 is also configured to execute a smart selection strategy when determining source entity blocks to be reclaimed. Specifically, processor 211 first determines the current operating state of storage device 20. In response to an unbusy operating state, processor 211 may base its selection on a static heat table (e.g., ...). Figure 3 The processor 211 uses the importance level information in T32 to prioritize the selection of entity blocks containing valid data with higher importance levels as source entity blocks, thereby utilizing system idle windows to maintain critical data. Correspondingly, in response to a busy operating state, the processor 211 can assess the current resource requirements of the system, for example, by analyzing the data patterns of the write data stream from the host system 10 to predict the demand for idle entity addresses with specific offset attributes, and select entity blocks with the corresponding offset attributes as source entity blocks to prioritize subsequent system performance.

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

[0049] Reference Figure 2 , Figure 2 The provided process aims to leverage the inherent data movement process in garbage collection operations to intelligently optimize the data layout within the storage module 220, thereby transforming routine background maintenance tasks into a proactive management process that enhances the long-term reliability of data.

[0050] In one embodiment, the memory management method, for example, begins with the triggering of a garbage collection operation. In step S220, the processor 211 determines the source entity block to be reclaimed from a plurality of entity blocks and obtains the data attributes of the valid data in the source entity block. Specifically, when the available space of the storage device 20 is lower than a preset threshold, or when other preset conditions are met (e.g., the amount of mismatched data in the system exceeds the limit or the temperature is abnormal), the processor 211 initiates the garbage collection process. After determining the source entity block as the target for reclamation, the processor 211 traverses the source entity block, identifies the valid data that is still mapped by logical addresses, and for each valid data, queries one or more forms (e.g., ... Figure 3 The data attributes (e.g., hot data attributes or cold data attributes) are determined using the dynamic heat table T31 or the static heat table T32 shown. For specific implementation methods of determining data attributes, please refer to the following text. Figure 3 Detailed explanation.

[0051] Next, in step S220, the processor 211 selects a target entity address with an offset attribute matching the data attributes from multiple entity addresses of multiple free entity blocks based on the data attributes of the valid data in the source entity block. In one embodiment, the offset attributes mainly include left offset attributes and right offset attributes, which respectively identify different physical aging trends of the entity address. The processor 211 searches for new storage locations (i.e., target entity addresses) with corresponding offset attributes for valid data with different data attributes according to a preset matching relationship.

[0052] Specifically, the matching relationship is defined as follows: when valid data has a "hot" data attribute, the offset attribute matched with it is a left offset attribute; while when valid data has a "cold" data attribute, the offset attribute matched with it is a right offset attribute. This will be discussed later. Figure 4A , Figure 4B This section details the logical process of making differentiated selections based on data attributes.

[0053] To illustrate with a real-world scenario, suppose processor 211 is performing garbage collection on a source entity block and identifies that the block contains two types of valid data: one part is frequently updated system log files (determined to be hot data attributes), and the other part is archived photos that users have stored for a long time (determined to be cold data attributes).

[0054] For that portion of the system log files, processor 211 queries the list of offset entity addresses, filters out free entity addresses with a "left offset attribute" (e.g., page 5 of entity block B1), and moves the log files there. This placement strategy leverages the physical characteristics of left offset addresses to accommodate the need for frequent rewriting of hot data.

[0055] Conversely, for that portion of archived photos, processor 211 selects free entity addresses with a "right offset attribute" (e.g., page 10 of entity block B2) from the list for relocation. By placing cold data in areas with a right offset attribute, the physical characteristics of that area can be better utilized to maintain data integrity during long-term inactivity. Through this differentiated relocation, mixed data within the same source entity block is distributed to entity blocks suitable for their respective data attributes.

[0056] For the physical meaning of the offset attribute, please refer to the following text. Figure 5 and Figure 6 Detailed explanation.

[0057] Finally, in step S230, the processor 211 controls the movement of valid data to the target entity address. After this movement is completed, the valid data is stored in a new storage location whose physical characteristics are better suited to its data attributes, thus completing the optimization of data layout in a garbage collection operation.

[0058] As described above, in one embodiment, the processor 211 can obtain the data attributes of each valid data through one or more maintained forms, as described below. Figure 3 Let me explain in detail.

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

[0060] Reference Figure 3 In one embodiment, when the processor 211 performs a garbage collection operation and needs to obtain valid data attributes, it may adopt a hybrid strategy that combines static query and dynamic calculation. Figure 3 Two key data structures used to support this strategy are shown: a dynamic heat table T31 and a static heat table T32, which are typically maintained by the processor 211 in a buffer memory 214.

[0061] In one embodiment, the processor 211 uses a dynamic heat table T31 to track the access frequency of data in real time. Specifically, the dynamic heat table T31 divides the logical address space into multiple units and records an access count value for each unit. To ensure that the access count value accurately reflects the current access pattern of the data, the processor 211 executes a dynamic maintenance mechanism. As shown by arrow A31, when an I / O access operation pointing to a certain logical address is received, the processor 211 increments the access count value corresponding to that logical address. At the same time, as shown by arrow A32, the processor 211 also periodically performs a decay operation on all access count values ​​in the dynamic heat table T31 to simulate the natural cooling of the heat. When it is necessary to determine the 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 dashed arrow A33, if the access count value AC5 of logical address LBA5 is higher than the hot threshold, processor 211 determines its data attribute as hot data attribute; conversely, as shown by dashed arrow A34, if the access count value AC3 of logical address LBA3 is not higher than the hot threshold, processor 211 determines its data attribute as cold data attribute. In the specific implementation of firmware or hardware, this offset direction field can be optimized to occupy only one bit of the flag. For example, a bit value "0" can be defined to represent a left offset attribute, and a bit value "1" can represent a right offset attribute, thereby saving storage space overhead of buffer memory 214.

[0062] In one specific embodiment, the construction and maintenance of the heat table T32 (i.e., the static heat table) mainly relies on the active instructions of the host system 10. Specifically, when the host system 10 sends a write command to the storage device 20, it can carry a "hint" or "stream ID" about the data attribute in the command.

[0063] For example, when host system 10 needs to write to the operating system's core log file, host 10 knows that this data will be frequently updated based on the preset data type classification, so it marks the logical address of the data as "hot data" in the write instruction. After receiving the instruction, memory controller 210 parses the mark and directly records the corresponding logical address and the determined "hot data attribute" in the static heat table T32.

[0064] For example, when the host system 10 writes a large number of video archive files, it marks them as "cold data." The memory controller 210 then records these logical addresses as cold data attributes in the static heat table T32. In this way, the memory controller 210 can directly utilize the host system 10's understanding of the file system hierarchy to quickly and accurately establish the static attributes of data without waiting for subsequent access statistics to accumulate. Of course, this does not preclude, in another embodiment, the memory controller 210 from automatically establishing and maintaining the heat table T32 based on a pre-defined logical address range within the firmware (e.g., an LBA area reserved for metadata).

[0065] It should be noted that the "static heat table (such as T32)" and the "dynamic heat table (such as T31)" mentioned in this disclosure have significant differences in the mechanism and timeliness of attribute determination.

[0066] Static heat tables (T32) focus on "predefined" and "inherent attributes." They are typically determined based on data type (such as FTL tables, firmware code), explicit indications from the host system (such as Host Hints), or fixed logical address ranges. A key characteristic is that once attributes are determined, they remain unchanged over a long period unless overwritten or explicitly modified. They are suitable for identifying data that has a clear hot / cold characteristic from its inception.

[0067] In contrast, the dynamic heat table (T31) focuses on "acquired behavior" and "real-time statistics." It does not rely on the initial type of data, but is entirely based on the I / O access frequency (i.e., access count value) actually monitored by the memory controller 210 during operation. Its characteristic is high time-varying variability; a user file initially considered cold data can rapidly increase its count value in the dynamic heat table and thus become hot data if it is suddenly read frequently.

[0068] This disclosure combines these two mechanisms, leveraging the rapid identification advantage of static tables while retaining the adaptive adjustment capability of dynamic tables.

[0069] The following uses Figure 4A This section details the process for selecting the target entity address for matching target data attributes.

[0070] Reference Figure 4A The process begins at step S410, where processor 211 obtains a valid data to be moved and its corresponding data attributes from the source entity block. These data attributes have been determined through the aforementioned static query or dynamic calculation methods (e.g., hot data attributes or cold data attributes).

[0071] Next, in step S420, the processor 211 determines the data attributes. If the determination result indicates that the valid data has the attribute of cold data, the process proceeds to step S430. In step S430, the processor 211 queries the offset entity address list and selects an available entity address with a right offset attribute as the target entity address for the cold data. For example, if the valid data is identified as a user backup document that has not been accessed for a long time (typical cold data), after querying the offset entity address list, the processor 211 locks an entity address marked as "right offset" and designates it as the new storage location for the backup document.

[0072] Conversely, if the determination result in step S420 indicates that the valid data has hot data attributes, the process proceeds to step S440. In step S440, the processor 211 also queries the offset entity address list, but this time it selects an available entity address with a left offset attribute as the target entity address for the hot data. For example, if the valid data is identified as frequently updated file system metadata or a log file (typical hot data), the processor 211 will select an entity address marked as "left offset" from the offset entity address list as the target.

[0073] To illustrate the data attribute-based traffic splitting mechanism described above more intuitively, please refer to [link / reference]. Figure 4B . Figure 4B This is a schematic diagram of data movement according to an embodiment of the present disclosure. In a garbage collection operation, the processor 211 selects a source entity block SB1. The source entity block SB1 stores valid data with different characteristics, including first valid data DT1 and second valid data DT2.

[0074] Processor 211 first reads and analyzes the first valid data DT1. After identifying that the first valid data DT1 has hot data attributes (e.g., frequently updated system logs), processor 211 selects a target entity address with a left offset attribute from the offset entity address list according to the matching rules, corresponding to the target entity block TB1. Subsequently, as shown by arrow A41, processor 211 moves the first valid data DT1 to the target entity address with the left offset attribute.

[0075] Next, processor 211 processes the second valid data DT2. After identifying that the second valid data DT2 has cold data attributes (e.g., a long-unmodified archive file), processor 211 selects a target entity address with a right offset attribute, corresponding to target entity block TB2. As shown by arrow A42, processor 211 moves the second valid data DT2 to the target entity block TB2 with the right offset attribute. Through this process, hot data and cold data that were originally mixed in the same source entity block SB1 are intelligently "diverted" to their most suitable physical locations during garbage collection, thereby achieving physical isolation and optimization of data layout.

[0076] By execution Figure 4A , Figure 4B As shown in the process, the processor 211 ensures that data with different characteristics can always be moved to the physical address whose physical characteristics are most suitable for its access mode, thereby realizing intelligent optimization of data layout.

[0077] In one embodiment, the processor 211 may utilize a static heat table T32 (such as...) Figure 3 The processor 211 manages the importance level of different data using the static heat table T32. A lower value in this field indicates higher importance. For example, Flash Translation Layer (FTL) mapping table data, which is critical to system operation, can be assigned the highest importance level, "0". Correspondingly, logical addresses LBA12 and LBA11, although marked as "cold" data attributes, can be assigned different importance levels, "1" and "2," depending on their content (e.g., firmware code and system log, respectively). For ordinary user data not listed in the static heat table T32, the processor 211 can assign a default, lower importance level (e.g., a value of "3" or higher) to indicate its lower importance relative to system data. In this way, the processor 211 can not only know the data attributes of valid data but also its importance to the overall system operation.

[0078] Based on this importance level, processor 211 can implement internal priority scheduling during the data migration of a single source entity block. Specifically, when migrating multiple valid data items within a source entity block to their respective target entity addresses, processor 211 can arrange their migration order according to the importance level of these valid data items. For example, processor 211 will prioritize migrating data with the highest importance level (such as FTL mapping table data) and then process user data with lower importance levels. This internal priority scheduling mechanism ensures that when garbage collection operations are interrupted by higher-priority tasks (such as urgent read requests from the host system), the most critical data for system operation has been prioritized and safely placed in a new location, thereby further improving system stability and responsiveness.

[0079] In one embodiment, to avoid over-concentrating on a few entity addresses during target entity address selection, thus accelerating their aging, for example, during the target entity address selection operation, the processor 211 may select a target entity address with a lower historical usage count value from multiple candidate entity addresses based on their respective historical usage count values. The following will combine... Figure 8 and Figure 10 Provide a detailed explanation of the implementation process of this strategy.

[0080] Reference Figure 8 and Figure 10 The wear leveling process begins at step S810, where processor 211 first determines a matching offset attribute that matches the data attributes of the valid data of the source entity block. For example, if the valid data has a hot data attribute, the matching offset attribute is determined to be a left offset attribute.

[0081] Next, in step S820, processor 211 obtains multiple available candidate entity addresses with matching offset attributes. Specifically, processor 211 queries the offset entity address list BPL (e.g., ...). Figure 10 (As shown), and filter out all entity addresses whose offset direction matches the matching offset attribute and whose availability status is "1" as candidate entity addresses. Here, the availability status field (such as...) Figure 10 (As shown) plays a crucial role in rapid filtering. A value of "1" clearly indicates that the entity address is currently in a free and writable state, while a value of "0" indicates that the address is occupied or marked as a bad block. By directly integrating this status information into the offset entity address list, the processor 211 can directly exclude invalid addresses without having to additionally query the global bitmap or allocation table. This mechanism not only avoids the risk of errors in performing write operations to already occupied addresses, but also significantly reduces the computational overhead and access latency in the filtering process, thereby improving the overall execution efficiency of garbage collection operations.

[0082] Subsequently, in step S830, processor 211 obtains the historical usage count value for each candidate entity address. This historical usage count value records the cumulative number of times each entity address has been selected as a relocation target in the past.

[0083] In step S840, the processor 211 determines the target entity address with the lower historical usage count value among the multiple candidate entity addresses based on their respective historical usage count values. By prioritizing entity addresses that have been used less historically, write operations can be effectively distributed across all entity addresses of the same type, thereby achieving wear leveling and extending the overall lifespan of the memory module 220.

[0084] For example, suppose processor 211 needs to find the address of a target entity with a left offset attribute for valid data of a hot data attribute. Processor 211 first starts from... Figure 10 From the offset entity address list BPL shown, all candidate entity addresses with an "offset direction" of "left" and an "availability status" of "1" are selected. These addresses include B1_P1, B1_P2, B1_P3, B1_P4, B2_P1, and B2_P2. Next, processor 211 obtains their respective "historical usage count values", which are "125, 88, 68, 32, 11, and 7", respectively. By comparing these count values, processor 211 selects the entity address B2_P2 (historical usage count value "7") with the lowest count value as the target entity address for this relocation.

[0085] Finally, in step S850, processor 211 moves the valid data to the target entity address and accumulates the target historical usage count value corresponding to the target entity address. In the above example, after processor 211 successfully moves the valid data to B2_P2, it also updates the historical usage count value corresponding to it in the offset entity address list BPL from 7 to 8.

[0086] In another embodiment, to further improve the reliability of the data transfer process, after performing the transfer operation, the processor 211 does not immediately erase the original valid data in the source entity block. Instead, it first performs a read verification operation on the data at the new location. Only after confirming that the data can be read correctly is the erasure operation performed. This avoids the risk of data loss due to potential defects in the target entity address.

[0087] Specifically, after moving the valid data to the target entity address, the processor 211 will first perform a read verification operation on the data at the new location. Only after the read verification operation successfully confirms that the data can be read correctly will the processor 211 erase the original valid data in the source entity block, thereby avoiding the risk of data loss due to potential health problems of the target entity address.

[0088] For example, in a garbage collection operation, processor 211 moves valid data from a source block (e.g., block A) to a newly selected target block address (e.g., page P1 of block B). After completing this write operation, processor 211 does not immediately erase block A. Instead, processor 211 initiates a read instruction to page P1 of block B, attempting to read the data that was just written and perform data verification (e.g., ECC check). If the data is successfully read and the verification is correct, processor 211 considers the move reliable and can then safely mark block A as pending erasure. Conversely, if the read fails or the verification fails, it indicates that the target block address (page P1 of block B) may have a physical defect. In this case, processor 211 can perform a reread operation on page P1 of block B, or processor 211 can mark page P1 of block B as a bad block or unusable, and reselect another corresponding target block address for the valid data to move again, thereby ensuring data integrity. For example, if the valid data is hot data, the corresponding target entity address with the left offset attribute (e.g., page P1 of block C with the left offset attribute) will be selected and moved again.

[0089] In one embodiment, the offset entity address list (such as...) Figure 10 The voltage offset identification operation (as shown in the BPL) can be generated and updated by the processor 211. This operation aims to diagnose the physical health of a physical address to determine its overall offset attributes. Specifically, the processor 211 acquires the current critical voltage of each memory cell within the physical address and compares it with an initial critical voltage to identify the offset direction of each cell (e.g., left-biased or right-biased). Subsequently, the processor 211 performs statistical analysis and, if it finds that the number of memory cells with a certain offset direction dominates the entire physical address (e.g., the number exceeds a preset threshold), assigns the corresponding offset attribute (e.g., left offset attribute or right offset attribute) to the physical address. In some implementations, the process of accurately acquiring the current critical voltage can be combined with physical layer information obtained by enhanced read operations (e.g., soft-decision reads) and correct logical data recovered through error-correcting codes.

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

[0091] 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.

[0092] Reference Figure 5In one embodiment, processor 211 may acquire the offset attributes of a physical address (e.g., a physical page) by performing a voltage offset identification operation. This operation is intended to diagnose the physical health of the physical address and determine the statistically significant offset trend of the critical voltages of its numerous memory cells, for example, whether it generally tends to decrease (i.e., left offset attribute) or increase (i.e., right offset attribute).

[0093] In one embodiment, when a regular read operation on a physical address fails (e.g., due to ECC decoding failure), processor 211 initiates a voltage offset identification operation. The core of this operation is to accurately infer the current critical voltage of each memory cell within that physical address using a comprehensive method that combines physical layer information and logical layer correction.

[0094] Specifically, this comprehensive approach first acquires soft information containing richer physical layer information by performing an enhanced read operation (e.g., a soft-decision read). The soft-decision read involves applying a series of fine voltage levels (e.g., ... Figure 5 The processor 211 scans the memory cells (around Vread1, Vread2, Vread3) using this soft information. Then, the processor 211 uses this soft information and performs a soft decoding operation with the help of its internal error correction code (ECC) decoder to recover the original correct data stored in the physical address.

[0095] After successfully acquiring the correct data at the logical level, the processor 211 uses it as a definitive logical reference to interpret the physical layer information obtained during the enhanced read operation. By correlating the known logical state with the actual voltage response behavior, the processor 211 can accurately infer the current actual critical voltage value for each memory cell within that physical address.

[0096] For example, refer to Figure 5 A memory cell logically intended to store data "00" (corresponding to state S2, with an initial critical voltage of 2.5V) experiences a drop in its actual critical voltage to 1.9V due to charge leakage. This causes it to be misread as state S1 (corresponding to data "01") at the reference voltage Vread2 (2V) during normal reading. In the voltage offset identification operation, the processor 211 first corrects the erroneous data "01" back to "00" through software decoding; then, by analyzing the software information, it discovers that the voltage reversal point of this cell is approximately 1.9V. Combining these two pieces of information, the processor 211 ultimately determines that the current critical voltage of this cell is indeed 1.9V.

[0097] After obtaining the current critical voltage of all memory cells within the physical address, the processor 211 compares these voltage values ​​with their respective initial critical voltage values ​​to determine the offset direction (left-biased or right-biased) of each cell. Finally, the processor 211 uses statistical analysis to determine which offset direction of memory cells dominates the number of cells within the physical address (e.g., exceeding a preset threshold, such as half the total number). If the number of left-biased cells dominates, the processor 211 determines the offset attribute of the physical address as a left offset attribute; conversely, if the number of right-biased cells dominates, it determines it as a right offset attribute. This determined offset attribute is then recorded in the offset physical address list, providing a basis for subsequent data management.

[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 This illustrates two typical scenarios after the critical voltage of a memory cell shifts from an initial distribution state (the bell-shaped curve shown by the solid line in the figure). This initial critical voltage distribution can be used as a benchmark to determine the offset attributes of a physical address.

[0100] In one embodiment, Figure 6 The dashed curve on the left represents the "left offset attribute." This attribute indicates that the critical voltage distribution of memory cells within a physical address tends to decrease overall. This situation is usually related to charge leakage in memory cells and may affect data retention capabilities. Figure 6 The dashed curve on the right represents the "right offset attribute," which indicates that the overall critical voltage distribution tends to increase. This is usually related to charge trapping and may increase the risk of programming interference.

[0101] In the memory management method disclosed herein, the processor 211 utilizes these physical characteristics to achieve intelligent data placement. Specifically, during the data movement process of garbage collection operations, the processor 211 places valid data with different data attributes into target entity addresses with corresponding offset attributes according to preset matching relationships.

[0102] In one embodiment, the matching relationship is defined as follows: hot data attributes that require frequent access and updates are matched with left offset attributes that are more tolerant of frequent reads and writes; while cold data attributes that require long-term reliable rest are matched with right offset attributes that have stronger data retention capabilities. In this way, the processor 211 can ensure that valid data is placed in the physical environment most suitable for its characteristics after garbage collection, thereby improving the overall reliability of the storage device 20.

[0103] The following uses Figure 10This will provide a detailed explanation of the specifics of the offset entity address list.

[0104] Figure 10 This is a schematic diagram of the data structure of the offset entity address list according to an embodiment of this disclosure.

[0105] In one embodiment, the processor 211 maintains an offset entity address list BPL in the buffer memory 214 to record information about entity addresses in the memory module 220 that have been identified as having specific physical offset characteristics.

[0106] Specifically, the Offset Entity Address List (BPL) may include the following fields:

[0107] Entity Address: This field uniquely identifies an entity address, and its format can be, for example, "Entity Block Number_Entity Page Number". For instance, the entry "B1_P1" represents the first entity address belonging to entity block B1.

[0108] Offset Direction: This field records the offset attribute (e.g., left offset or right offset) of the entity address. For example, "left" in the field indicates that the entity address has a left offset attribute, and "right" indicates that the entity address has a right offset attribute.

[0109] Availability Status: This field indicates whether the entity address 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. In other embodiments, the processor 211 may also determine the availability of an entity address by querying other system mapping tables.

[0110] Historical Usage Count: This field records the cumulative number of times each entity address has been selected as the target address for data migration. For example, the historical usage count for entity address "B1_P1" is 125. Processor 211 can use this count to perform wear leveling management on multiple candidate entity addresses with the same offset attributes. It should be noted that the historical usage count field is also optional. In another embodiment, the offset entity address list BPL may not include this field, in which case processor 211 can use other preset round-robin or random selection strategies to select from multiple candidate entity addresses. Alternatively, processor 211 can directly select the entity address with the lower PE cycle value as the target entity address. It should be noted that the "entity address" mentioned in this disclosure is not limited to the absolute physical address on the memory chip. In practical applications, memory controller 210 typically performs bad block management. Therefore, the entity address in this embodiment can refer to a physical resource address that is logically visible to the controller after bad block mapping. Processor 211 builds an offset entity address list based on these managed valid addresses, thereby ensuring that data is not moved to a damaged physical area.

[0111] In another embodiment, the processor 211 can implement wear leveling based on sorting. Specifically, after the processor 211 selects multiple candidate entity addresses with the same offset attribute from the list of offset entity addresses, it sorts them in ascending order according to their historical usage counts. The processor 211 then always selects the first entity address in the sorted list (i.e., the address with the lowest historical usage count) as the target entity address. After data migration is complete, the count of this entity address is updated and placed in a new position during the next sort. This sorting-based selection method, without requiring traversal comparisons, efficiently ensures that the load is evenly distributed across all available entity addresses of the same type.

[0112] To illustrate the sorting-based wear leveling mechanism more intuitively, please refer to [link / reference]. Figure 11 . Figure 11 This is a schematic diagram of an offset entity address list sorted based on historical usage count values, according to an embodiment of this disclosure. In this embodiment, to further improve search efficiency, the processor 211 logically or physically divides the offset entity address list into two independent sub-lists: a left offset sub-list BPL1 for recording left offset attribute entity addresses, and a right offset sub-list BPL2 for recording right offset attribute entity addresses.

[0113] Within each sublist, the processor 211 sorts the entity addresses in ascending order based on their historical usage count. For example, in the left offset sublist BPL1, the entity address "B2_P2" is placed at the beginning of the list because its historical usage count is "7" (currently the lowest); it is followed by "B2_P1" with a count of "11", and so on. This sorting maintains the order of wear levels.

[0114] When processor 211 needs to select a target entity address for valid data with hot data attributes during garbage collection, it does not need to traverse the entire list to find the minimum value. Processor 211 only needs to access the top of the left offset sublist BPL1. As shown by arrow A111, processor 211 directly selects the first entity address "B2_P2" with an availability status of "1" as the target. Similarly, if valid data with cold data attributes needs to be placed, processor 211 accesses the right offset sublist BPL2. As shown by arrow A112, processor 211 directly selects the first entity address "B1_P7" (whose historical usage count is "13") as the target. Through this mechanism of table sorting and first-to-last selection, this disclosure not only achieves accurate wear leveling but also minimizes the computational complexity of target address selection, significantly improving the real-time response capability of the system when handling large amounts of data movement.

[0115] Figure 9 This is an interactive timing diagram of a memory management method according to an embodiment of the present disclosure.

[0116] Reference Figure 9 , Figure 9 The demonstration showed how the processor 211, as the core execution unit, interacts with key components such as the memory module 220, the heat table HVT, and the offset entity address table BPL to complete a complete intelligent data transfer process in a garbage collection operation.

[0117] In one embodiment, the process begins at step S900, where processor 211 internally triggers a garbage collection operation. Then, in step S910, processor 211 issues an instruction to memory module 220 to identify a source entity block to be reclaimed.

[0118] In step S920, the memory module 220 confirms the source entity block with the processor 211.

[0119] Subsequently, processor 211 enters a loop to traverse and process each valid data within the source entity block. In step S930, processor 211 requests to read at least one valid data from memory module 220, and in step S940, receives the returned valid data.

[0120] In step S950, the processor 211 begins to determine the data attributes of the valid data.

[0121] For example, in a scenario where a heat table (HVT) is used to confirm data attributes, in step S951, the processor 211 sends a query request to the heat table HVT to obtain the historical access count value corresponding to the valid data. In step S952, the heat table HVT returns the queried count value. Then, in step S953, the processor 211 internally compares the returned count value with a preset threshold to determine whether the valid data attribute is a hot data attribute or a cold data attribute. In another scenario, the processor 211 can also query a pre-configured static heat table (such as...). Figure 3 The processor 211 uses a heat table (T32) to determine data attributes. Specifically, for system data with inherent, predictable access patterns (e.g., FTL mapping table data or firmware data), their data attributes can be pre-defined and stored in this static heat table. When the processor 211 needs to determine the data attributes of valid data, it first queries this static heat table. If the entry corresponding to the valid data is found in the table, the processor 211 directly adopts its pre-defined data attributes without performing a dynamic access count query, thereby improving decision-making efficiency.

[0122] In step S960, processor 211 selects a matching target entity address based on the data attributes determined in the previous step. In an optional flow (alt), if the data attribute is "hot data," then in step S961, processor 211 requests / queries a free entity address with a "left offset attribute" from the offset entity address table BPL, and receives the matching target entity address returned by BPL in step S962. Correspondingly, if the data attribute is "cold data," then in step S963, processor 211 requests / queries a free entity address with a "right offset attribute" from the offset entity address table BPL, and receives the returned matching target entity address in step S964.

[0123] Finally, in step S970, processor 211 sends an instruction to memory module 220 to move the valid data to the selected target entity address. In step S980, memory module 220 returns a signal to processor 211 indicating that the move is complete. At this point, the intelligent move process for a single valid data item ends. Processor 211 will repeat the above loop until all valid data within the source entity block has been processed.

[0124] It is worth mentioning that this disclosure also provides advanced strategies for intelligently determining source entity blocks under different system operating states. In some embodiments, the method of this disclosure can further optimize the generation of free block resources. Specifically, when selecting source entity blocks to be reclaimed for garbage collection, the processor 211 introduces different decisions in addition to considering traditional factors (e.g., the amount of invalid data in the block or the number of times the block has been programmed / erased). The following utilizes Figure 7 Let me explain in detail.

[0125] Figure 7 This is a logic flowchart for determining a source entity block according to another embodiment of the present disclosure.

[0126] Reference Figure 7 In one embodiment, the decision logic of processor 211 changes based on the current operating state of storage device 20. In step S720, processor 211 first determines whether the operating state of storage device 20 is a non-busy state. Additionally, processor 211 is configured to execute a smart selection strategy when determining source entity blocks to be reclaimed. Specifically, processor 211 first determines the current operating state of storage device 20. In response to a non-busy operating state, processor 211 may base its decision on a static heat table (e.g., ...). Figure 3 The processor 211 uses the importance level information in T32 to prioritize the selection of entity blocks containing valid data with higher importance levels as source entity blocks, thereby utilizing system idle windows to maintain critical data. Correspondingly, in response to a busy operating state, the processor 211 can assess the current resource requirements of the system, for example, by analyzing the data patterns of the write data stream from the host system 10 to predict the demand for idle entity addresses with specific offset attributes, and select entity blocks with the corresponding offset attributes as source entity blocks to prioritize subsequent system performance.

[0127] In one embodiment, in response to the determination that the operating state of the storage device is busy in step S720, the process proceeds to step S730. At this time, the decision objective of the processor 211 shifts to prioritizing the subsequent operating performance of the system, and executes a resource-oriented source entity block selection strategy. In step S730, the processor 211 evaluates the system resource requirements of the storage device to determine a demand offset attribute, and selects entity blocks with the same offset attribute as source entity blocks from multiple entity blocks based on the demand offset attribute.

[0128] Specifically, in one embodiment, assessing the system resource requirements of the storage device to determine a demand offset attribute may be achieved by the processor 211 predicting the demand for free entity addresses in a specific offset attribute by analyzing the write data stream issued by the host system 10, thereby determining a demand offset attribute consistent with that specific offset attribute.

[0129] For example, if the processor 211 detects a large amount of hot data being written in the hot and cold data tags of the data being written, it can predict that the system will soon need a large amount of free entity addresses with left offset attributes. Based on this, the processor 211 determines the required offset attribute to be a left offset attribute. As another example, if the processor 211 discovers through analysis that a large file archiving or backup task is currently being performed, and the data stream being written mainly consists of cold data that needs to be stored for a long time, it can predict that the system will soon need a large amount of free entity addresses with right offset attributes, thus determining the required offset attribute to be a right offset attribute.

[0130] Subsequently, in step S740, the processor 211 selects a source entity block from multiple candidate entity blocks based on the demand offset attribute, where the source entity block has an offset attribute consistent with the demand offset attribute. In this way, garbage collection not only reclaims invalid space but also proactively and purposefully "creates" the most urgently needed resource types for the system, thereby helping to alleviate performance bottlenecks and ensure smooth system operation under heavy load. A "candidate entity block" refers to the set of all entity blocks in the memory module 220 that meet the pre-selection criteria for garbage collection. Typically, these blocks contain a certain proportion of invalid data or are in a state requiring wear leveling, thus qualifying for reclamation. A "source entity block" is the specific entity block that the processor 211 ultimately selects from the set of "candidate entity blocks" based on a specific selection strategy (e.g., a traditional greedy algorithm or the intelligent strategy based on importance level / attribute requirements proposed in this disclosure), and on which data migration and erasure operations will be performed. In short, candidate entity blocks are the pool of candidates, while source entity blocks are the final winners.

[0131] In one embodiment, it is assumed that the write data sent by the host system 10 is currently temporarily stored in buffer memory 214 and has not yet been written to memory module 220. Processor 211 analyzes and finds that a large amount of hot data (e.g., frequently updated index files) has accumulated in the buffer memory. At this time, the garbage collection mechanism is triggered (whether due to insufficient space or the arrival of a preset period). In this round or the next garbage collection operation, in order to cope with the upcoming hot data write demand, processor 211 will execute a specific source entity block selection strategy and determine the source entity block with the left offset attribute to be selected.

[0132] Specifically, processor 211 first identifies all candidate entity blocks containing invalid data. Next, processor 211 queries the offset entity address list (BPL) and specifically selects a block with a "left offset attribute" from these candidate entity blocks, defining it as the source entity block. Subsequently, processor 211 performs valid data migration and erases the source entity block, thereby preferentially freeing a clean, left-offset free block. After updating the relevant logical-to-entity address mapping table, processor 211 can immediately write the hot data accumulated in the buffer memory into this newly reclaimed, physically best-matched left-offset free block and update the mapping table again. Through this "targeted reclamation-write" mechanism, the system achieves not only reclaimable space but also stable data storage.

[0133] Furthermore, in another embodiment, this disclosure also provides a supply-demand balance-based judgment mechanism to determine whether to execute the directional selection strategy of step S740. Specifically, after analyzing the attributes of the written data (e.g., determining it to be hot data with a demand for a left-offset attribute entity block), the processor 211 further checks whether there are a sufficient number of free entity addresses with that specific offset attribute (left offset) in the current memory module 220.

[0134] If the processor 211 determines that there are sufficient free blocks at the current left offset, it can execute a conventional garbage collection strategy (e.g., selecting source entity blocks based solely on the proportion of invalid data). However, if the processor 211 determines that there are insufficient free blocks at the corresponding offset, it executes step S740. In this case, the processor 211 will specifically select a block with a left offset attribute from the candidate entity blocks as the source entity block for reclamation, to ensure that the system can replenish scarce specific types of resources in a timely manner through garbage collection operations, thereby avoiding performance degradation caused by resource mismatch.

[0135] In another embodiment, in response to the storage device's operating state being non-busy (i.e., the system is idle), the process proceeds to step S750. Here, it is necessary to first explain the definition of the operating state. "Busy state" typically refers to the memory controller 210's instruction queue depth exceeding a preset threshold, or the execution of continuous large-scale data read / write operations. In this state, the system's primary goal is to ensure I / O throughput and response speed; therefore, garbage collection is usually triggered only when space is insufficient, or, as described in the previous embodiments, quickly reclaimed resources based on demand (such as an urgent need for left offset blocks). Conversely, "non-busy state" refers to an empty instruction queue or a depth below a threshold, and the duration exceeding a preset idle waiting time (e.g., 100 milliseconds). In this state, the system is in a low-load mode.

[0136] Upon detecting the entry into a non-busy state, the processor 211 utilizes this idle window to proactively execute a source entity block selection strategy aimed at maintaining critical data. Specifically, the processor 211 no longer focuses solely on which block has the most garbage (i.e., the highest proportion of invalid data), but instead acquires the importance level of the valid data for each candidate entity block to determine the overall importance level of each candidate entity block.

[0137] To give a concrete example: Suppose there are two candidate entity blocks available for reclamation. Candidate block A contains 90% invalid data, and the remaining 10% of valid data is ordinary "user downloaded videos" (lower importance level, e.g., level 3); candidate block B contains 50% invalid data, but the remaining 50% of valid data is the core "FTL logical-physical mapping table" (highest importance level, e.g., level 0).

[0138] In a busy state, in order to quickly free up space, processor 211 may select candidate block A, which has more garbage.

[0139] However, in the non-busy state of this embodiment, the processor 211 will determine that candidate block B has a higher overall importance level. In order to avoid storing these critical mapping table data in potentially aging physical locations for a long time, the processor 211 will preferentially select candidate block B as the source entity block.

[0140] Next, in step S760, the processor 211 preferentially selects candidate entity blocks with higher importance levels as source entity blocks. In this way, the system can opportunistically move and relocate critical and important data stored in non-optimal locations without affecting foreground performance, thereby improving the long-term storage reliability of important data for the storage device 20.

[0141] To illustrate the selection process under off-peak conditions, consider a more concrete example. Suppose that when processor 211 initiates garbage collection, it identifies two candidate blocks: block A and block B. Analysis reveals that 80% of the valid data in block A belongs to the Flash Translation Layer (FTL) mapping table (importance level "0"), while only 10% of the valid data in block B belongs to system metadata (importance level "1" or "2"). Since the storage device is under off-peak conditions, processor 211's strategy prioritizes maintaining critical data. Therefore, processor 211 will preferentially select block A, with its higher overall importance level, as the source block for this garbage collection, even if block B may have a higher proportion of invalid data.

[0142] Similarly, consider a specific example under heavy load. Suppose the storage device is performing a large database index rebuilding task from the host system. Processor 211 analyzes the write data stream and identifies this data as frequently accessed and rapidly updated, typical of hot data. Based on this, processor 211 predicts that the system will soon need a large number of free entity addresses with left offset attributes to handle subsequent write requests, thus determining the "demand offset attribute" as the "left offset attribute." At this point, suppose there are two candidate entity blocks: block C (with a left offset attribute) and block D (with a right offset attribute). Even if block D has a higher proportion of invalid data, processor 211 will still prioritize block C as the source entity block. This is because reclaiming block C can immediately generate a free block with a left offset attribute that the system currently urgently needs, thereby providing resource guarantees for subsequent hot data write operations and avoiding performance bottlenecks.

[0143] It should be noted that, in one embodiment, before the step of determining the source entity block to be reclaimed from multiple entity blocks, the process includes: counting the number of data attributes of valid data in multiple entity blocks that do not match the offset attributes of their respective entity addresses (mismatched data amount); if the mismatched data amount exceeds a preset data amount threshold, then the memory management method steps are executed. Specifically, before the step of determining the source entity block to be reclaimed from multiple entity blocks, the processor 211 periodically evaluates the system's current "resource demand" 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 started, the processor 211 adjusts its selection algorithm for the blocks to be reclaimed, prioritizing the selection of a suitable block to be reclaimed from those entity blocks that have been 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 that the system currently needs most. This differentiated strategy for selecting blocks to be reclaimed transforms background garbage collection from passive space organization to proactive resource supply optimization, thereby improving the efficiency of subsequent data migration or write operations.

[0144] For example, suppose processor 211 detects that the host system is performing a high-frequency database update operation, which will generate a large number of hot data write requests. Based on this, processor 211 predicts that the system will soon face a shortage of free blocks with a "left offset attribute" (because hot data is best stored in left offset blocks). At this point, when initiating garbage collection to free up space, processor 211 will change its strategy. Suppose there are two candidate blocks available for reclamation: block X (with a right offset attribute and 60% invalid data) and block Y (with a left offset attribute and 55% invalid data). Although block X is the better choice according to the traditional "most garbage first" principle, to respond to the current resource demand, processor 211 will prioritize block Y as the source block. This is because once the valid data in block Y is removed and block Y is erased, it will be transformed into a clean "left offset attribute" free block, which can be immediately put into use, perfectly accommodating the upcoming hot data write stream, avoiding performance degradation or mismatched writes due to a lack of suitable free blocks.

[0145] 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. In one embodiment, the steps of monitoring the operating temperature of the storage device, responding to the operating temperature exceeding a preset temperature threshold, and determining the source entity block to be reclaimed from multiple entity blocks include: detecting whether cold data exists in entity blocks with a left offset attribute among the multiple entity blocks. If so, the entity block with the left offset attribute is used as the source entity block. Specifically, processor 211 can execute a preventive triggering mechanism based on "temperature changes." Specifically, the processor 211 periodically obtains the current operating temperature of the storage device 20 through an onboard temperature sensor. When the processor 211 detects that the operating temperature is consistently higher than a preset safe temperature threshold, it will proactively trigger a garbage collection operation aimed at "enhancing data retention". In this GC, the source block selection algorithm of the processor 211 will give special priority to blocks containing a large amount of cold data, especially blocks containing cold data that have been mismatched in the left offset block address.

[0146] For example, suppose a solid-state drive (SSD) is installed in a poorly cooled laptop or placed in a high-temperature automotive system. When the processor 211 detects through its onboard temperature sensor that the internal operating temperature of the storage device 20 consistently exceeds a preset safety threshold (e.g., 75°C for more than 10 minutes), the processor 211 recognizes that the current environment poses a serious threat to data retention. This is because high temperatures significantly accelerate the Brownian motion of electrons in the floating gate, leading to an exponential increase in charge leakage, especially for physical blocks that already possess "left-off properties" (a decreasing critical voltage indicating charge loss), resulting in a very high risk of data loss.

[0147] In this emergency situation, processor 211 immediately initiates a "preventative garbage collection." When selecting a source entity block, processor 211 no longer follows the conventional principles of wear leveling or prioritizing invalid data percentages, but instead executes a "cold data rescue strategy." Assume processor 211 scans and finds that entity block B_Left stores user data (which belongs to the cold data attribute), and that entity block B_Left itself has been marked as having a "left offset attribute." To prevent these photos from being damaged by charge leakage due to high temperatures, processor 211 will prioritize locking entity block B_Left as the source entity block for recycling. Then, using the intelligent migration mechanism of this disclosure, processor 211 will move these photo data to a target entity address with a "right offset attribute" (the critical voltage tends to increase, usually indicating a thicker tunnel oxide layer or stronger charge trapping ability, resulting in better leakage resistance). Through this intelligent migration, the system successfully utilizes the complementarity of physical attributes to offset the negative impact of high ambient temperatures, proactively protecting the most vulnerable data before high temperatures accelerate charge leakage and pose a substantial threat to data integrity.

[0148] In another embodiment, processor 211 can execute a predictive triggering mechanism based on "host instruction mode". The instruction analysis module inside processor 211 can analyze instruction sequences from host system 10 in real time to identify the current workload mode, such as "random small file read / write" or "large file sequential write". When processor 211 detects a significant shift in workload mode, it can proactively trigger a garbage collection operation for "resource preparation", preparing the most suitable free block resources in advance for the upcoming new type of workload.

[0149] For example, a storage device has primarily handled sporadic reads and writes (random hot data) from the operating system and applications over the past few hours. Suddenly, the host system begins copying a 100GB video file (typical sequential cold data) to it. Upon recognizing this shift from "random writes" to "sequential large file writes," processor 211 immediately triggers a predictive garbage collection (GC). In this GC, processor 211 prioritizes reclaiming blocks with right offsets, quickly generating a large number of available free blocks with right offsets. Thus, when subsequent large streams of video file data arrive, the storage device is already prepared with optimal storage space, enabling efficient and smooth writes without frequent background cleanup due to resource mismatches during the write process.

[0150] On the other hand, the method disclosed herein can extend intelligent decision-making to the physical erasure level. Specifically, in another embodiment, when the garbage collection operation has completed effective data transfer and the source entity block needs to be erased, the processor 211 first queries the offset attribute of the source entity block. Based on the queried attribute, the processor 211 adopts an "adaptive erasure strategy" based on physical attributes.

[0151] For example, if the source block has a right-off offset (potentially containing persistent residual electrons), the processor 211 instructs the memory interface control circuit 213 to use stronger erase parameters. Specifically, this may include increasing the initial erase voltage from the standard 15V to 16V, and / or increasing the voltage step size after each erase pulse from the standard 0.5V to 0.7V. By applying a higher electric field strength, electrons trapped in deep traps can be more effectively expelled, ensuring the block is thoroughly erased to its initial state. Conversely, if the source block has a left-off offset (its tunnel oxide layer may be more fragile), the processor 211 uses gentler erase parameters. Specifically, this may include decreasing the initial erase voltage from the standard 15V to 14V, and / or extending the duration of each erase pulse from the standard 1 millisecond (ms) to 1.2 ms, while slowing down the voltage step rate. By using a lower electric field and extending the duration, the charge in the floating gate can be gently removed while reducing physical stress on the tunnel oxide layer. It should be noted that the voltage and duration mentioned above are for illustrative purposes only and are not intended to limit the invention.

[0152] This differentiated physical maintenance strategy allows for the fine-tuning of physical blocks in different health conditions while performing routine erasure, thereby slowing down their aging process.

[0153] It is worth mentioning that, in another embodiment, the method of this disclosure also provides a data protection enhancement mechanism under resource-constrained conditions. During the data migration process of garbage collection, if the processor 211 is forced to perform a "suboptimal placement" due to a lack of matching free entity addresses, the processor 211 can execute a risk-aware "dynamic ECC protection mechanism".

[0154] Specifically, when performing high-risk write operations, the processor 211 instructs its internal error correction code (ECC) engine to apply a stronger and more error-correcting ECC encoding scheme to the data than the standard configuration. In this way, by using logical-level redundancy enhancements, the inherent limitations of physical storage locations are compensated for, thereby ensuring the reliability of critical data even when an optimal choice cannot be made.

[0155] To illustrate with a practical example: Suppose processor 211 is searching for a new storage location for valid data with a "cold" attribute. According to the matching principle, the optimal choice is an entity address with a right offset attribute. However, after querying the offset entity address list, processor 211 finds that all currently available free entity addresses with right offset attributes are occupied, but there are available free entity addresses with left offset attributes. Under this resource-constrained situation, to complete garbage collection, processor 211 has to make a suboptimal choice: write this cold data, which needs to remain dormant for a long time, to a target entity address with a relatively weaker data retention capability (left offset attribute). While performing this write operation, processor 211 dynamically adjusts its ECC strategy; for example, switching from the standard BCH code, which can correct 80-bit errors, to a more redundant LDPC code, which can correct 100-bit errors, to encode the data. Although this increases data storage overhead and encoding / decoding latency slightly, it provides an additional logical layer of protection for this misplaced cold data against the potentially higher risk of data loss at its physical location.

[0156] 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.

[0157] It should be understood that although the foregoing embodiments are mainly described using "entity pages" as the basic unit of data management, this is only an exemplary implementation of this disclosure and not a limitation on the scope of protection of this disclosure.

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

[0159] Correspondingly, the granularity of the "target entity address" can also be flexible. The management granularity of the "offset entity address list" used to record offset attributes can also be adjusted. For example, it can record more fine-grained subpage-level offset attributes or more macro-level overall offset attributes on the basis of the entire entity block.

[0160] In summary, the core idea of ​​this disclosure is to select a "target entity address" with a specific "offset attribute" that matches the "data attributes" of valid data during garbage collection operations. The specific operational granularity for achieving this matching and relocation, whether at the page level, block level, or subpage level, all fall within the scope of protection claimed by this disclosure.

[0161] In summary, the memory management method and memory controller provided in this disclosure achieve the following technical effects by integrating data storage strategies into the garbage collection operation:

[0162] First, the method disclosed herein transforms a conventional garbage collection task into a proactive and intelligent data layout optimization process. By acquiring the data attributes (e.g., hot or cold data attributes) of valid data during garbage collection, and based on preset matching relationships (e.g., hot data matches left offset attributes, cold data matches right offset attributes), it selects target entity addresses with matching offset attributes for relocation. This ensures that after each background maintenance, data is placed in an area whose physical characteristics best suit its access mode. This not only avoids new data mismatches that may arise from traditional blind relocation but also leverages the inherent data movement of garbage collection to continuously optimize the data layout with minimal overhead, resolving potential data mismatch issues and effectively improving the long-term data reliability of the storage device.

[0163] Secondly, the method disclosed in this paper further enhances the granularity and security of data management by introducing a wear leveling mechanism and a reliability verification step. When selecting target entity addresses, by considering the historical usage counts of multiple candidate entity addresses and prioritizing those with lower usage counts, the write pressure can be effectively distributed evenly across all offset entity addresses of the same type, avoiding premature aging of local areas and thus extending the overall lifespan of the memory module. Furthermore, by adding a read verification operation after data migration and erasing the source data only after successful verification, a reliable insurance mechanism is constructed, effectively mitigating the risk of accidental data loss during migration due to potential defects in the target entity address, and ensuring the atomicity of garbage collection operations and data integrity.

[0164] Furthermore, this disclosure proposes a highly intelligent dual-mode source block selection strategy based on the storage device's operating state, achieving a dynamic balance between system performance and long-term reliability. When the storage device is not busy, the processor prioritizes the reclamation of blocks containing higher-priority data, utilizing the system idle window to preventatively organize and maintain critical data such as the Flash Translation Layer (FTL) mapping table. Conversely, when the storage device is busy, the processor assesses the system's current resource needs, predicting the types of free blocks that will be needed by analyzing the write data stream pattern, and prioritizing the reclamation of blocks capable of generating that type of resource. This adaptive decision-making mechanism allows garbage collection to proactively reserve resources for subsequent operations to ensure smooth performance during busy periods, and to perform internal health management to improve reliability during idle periods, demonstrating a more intelligent garbage collection mechanism.

[0165] 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 of a memory device configured with a memory module, characterized in that, The method includes: Identify the source entity block to be reclaimed from multiple entity blocks, and obtain the data attributes of the valid data in the source entity block; Based on the data attributes of the valid data, the target entity address corresponding to the offset attribute is selected from the target free entity block; and Move the valid data to the target entity address.

2. The method according to claim 1, characterized in that, The data attributes include hot data attributes or cold data attributes.

3. The method according to claim 2, characterized in that, The offset attribute includes a left offset attribute or a right offset attribute, wherein the offset attribute is matched with the data attribute based on the following relationship: When the data attribute is the hot data attribute, the offset attribute that matches the hot data attribute is the left offset attribute; as well as When the data attribute is the cold data attribute, the offset attribute that matches the cold data attribute is the right offset attribute.

4. The method according to claim 1, characterized in that, The offset attribute is determined based on an offset entity address list, which records multiple entity addresses and the offset attribute corresponding to each of the multiple entity addresses.

5. The method according to claim 2, characterized in that, The step of selecting the target entity address includes: Based on the historical usage count values ​​of multiple candidate entity addresses with the same offset attribute, the target entity address with the lower historical usage count value is selected from the multiple candidate entity addresses.

6. The method according to claim 1, characterized in that, After the step of moving the valid data to the target entity address, the method further includes: Perform a read verification operation on the valid data stored at the target entity address; and In response to the successful read verification operation, the valid data stored in the source entity block is erased.

7. The method according to claim 1, characterized in that, The step of determining the source entity block to be reclaimed from the plurality of entity blocks includes: In response to the storage device being in a non-busy operating state. Obtain the importance level of the valid data for each candidate entity block to determine the importance level of each candidate entity block; and Candidate entity blocks with higher importance levels are prioritized as the source entity blocks.

8. The method according to claim 1, characterized in that, Determining the source entity block to be reclaimed from the plurality of entity blocks includes: In response to the storage device being in a busy state; Assess the system resource requirements of the storage device to determine the demand offset attribute; and Based on the required offset attribute, the entity block with the same offset attribute as the required offset attribute is selected from the plurality of entity blocks as the source entity block.

9. The method according to claim 8, characterized in that, The process of assessing the system resource requirements of the storage device to determine the requirement offset attribute includes: By analyzing the write data stream issued by the host system, the demand for free entity addresses in a specific offset attribute is predicted, thereby determining the demand offset attribute that matches the specific offset attribute.

10. The method according to claim 1, characterized in that, The method further includes: Monitor the operating temperature of the storage device; In response to the operating temperature exceeding a preset temperature threshold, the step of determining the source physical block to be recycled from a plurality of physical blocks further includes: Detect whether there is cold data in the entity blocks with the left offset attribute among the multiple entity blocks; If it exists, the entity block with the left offset attribute is taken as the source entity block.

11. The method according to claim 1, characterized in that, Prior to the step of identifying the source entity block to be reclaimed from multiple entity blocks, the following steps are included: The amount of mismatched data in multiple entity blocks where the data attributes of the valid data do not match the offset attributes of the entity address they reside in is counted. If the amount of mismatched data exceeds a preset data amount threshold, then the steps of the memory management method are executed.

12. A memory controller for controlling a storage device configured with a memory module, the memory module comprising a plurality of physical blocks, 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: The source entity block to be reclaimed is determined from the plurality of entity blocks, and the data attributes of the valid data of the source entity block are obtained; Based on the data attributes of the valid data, a target entity address with an offset attribute matching the data attributes is selected from the multiple entity addresses of the multiple entity blocks; and Move the valid data to the target entity address.

13. The memory controller according to claim 12, characterized in that, The data attributes include hot data attributes or cold data attributes.

14. The memory controller according to claim 12, characterized in that, The offset attribute includes a left offset attribute or a right offset attribute, wherein the offset attribute is matched with the data attribute based on the following relationship: When the data attribute is a hot data attribute, the offset attribute matching the hot data attribute is the left offset attribute; and When the data attribute is a cold data attribute, the offset attribute that matches the cold data attribute is the right offset attribute.

15. The memory controller according to claim 12, characterized in that, The offset attribute is determined based on an offset entity address list, which records multiple entity addresses and the offset attribute corresponding to each of the multiple entity addresses.

16. The memory controller according to claim 13, characterized in that, The step of selecting the target entity address includes: Based on the historical usage count values ​​of multiple candidate entity addresses with the same offset attribute, the target entity address with the lower historical usage count value is selected from the multiple candidate entity addresses.

17. The memory controller according to claim 12, characterized in that, After the step of moving the valid data to the target entity address, the processor is further configured to: Perform a read verification operation on the valid data stored at the target entity address; and In response to the successful read verification operation, the valid data stored in the source entity block is erased.

18. The memory controller according to claim 12, characterized in that, The step of determining the source entity block to be reclaimed from the plurality of entity blocks includes: In response to the storage device being in a non-busy operating state. Obtain the importance level of the valid data for each candidate entity block to determine the importance level of each candidate entity block; and Candidate entity blocks with higher importance levels are prioritized as the source entity blocks.

19. The memory controller according to claim 12, characterized in that, Determining the source entity block to be reclaimed from the plurality of entity blocks includes: In response to the storage device being in a busy state; Assess the system resource requirements of the storage device to determine the demand offset attribute; and Based on the required offset attribute, the entity block with the same offset attribute as the required offset attribute is selected from the plurality of entity blocks as the source entity block.

20. The memory controller according to claim 12, characterized in that, The processor is also configured to: Monitor the operating temperature of the storage device; In response to the operating temperature exceeding a preset temperature threshold, the step of determining the source physical block to be recycled from a plurality of physical blocks further includes: Detect whether there is cold data in the entity blocks with the left offset attribute among the multiple entity blocks; If it exists, the entity block with the left offset attribute is taken as the source entity block.

Images