Maintaining Sequentiality for Media Management in a Memory Subsystem

Abstract

This application relates to maintaining the sequencing of media management for a memory subsystem. A plurality of read commands related to a set of media management operations for a plurality of transfer units are issued according to a read sequence. A plurality of entries associated with the set of media management operations are stored. A plurality of write commands related to the set of media management operations are issued based on the plurality of entries of the read sequence.

Description

[0001] Relevant information of divisional application

[0002] This is a divisional application. The parent application of this divisional application is a Chinese patent application for invention with the title "Maintaining Sequentiality for Media Management of a Memory Subsystem", application date of December 17, 2020, and application number 202011494212.1.

[0003] Cross-reference

[0004] This patent application claims priority to U.S. Patent Application No. 16 / 721,704, titled "Maintaining Sequentiality for Media Management of a Memory Sub-System", filed on December 19, 2019, by Bianco, which is assigned to its assignee and incorporated herein by reference in its entirety.

[0005] The technical field relates to maintaining sequentiality for media management of a memory sub-system. Background Art

[0006] A memory sub-system may include one or more memory components that store data. The memory components may be, for example, non-volatile memory components and volatile memory components. Generally, a host system may utilize the memory sub-system to store data at and retrieve data from the memory components. Summary of the Invention

[0007] Describes a method. In some instances, the method may include: issuing a plurality of read commands related to a set of media management operations for a plurality of transfer units according to a read sequence, each read command including an instruction for reading one of the transfer units at a source address of the memory sub-system; storing a plurality of entries associated with the set of media management operations, each entry including a status of the set of media management operations for one of the transfer units, wherein the read sequence is implicit in the plurality of entries; and issuing a plurality of write commands related to the set of media management operations at least in part based on the plurality of entries and the read sequence, each write command including an instruction for writing one of the transfer units to a corresponding destination address of the memory sub-system.

[0008] Describe a system. In some instances, the system may include: a plurality of memory devices; and a processing device operatively coupled to the plurality of memory devices to: receive a plurality of read responses of the plurality of memory devices related to a set of media management operations; and store a plurality of entries related to the set of media management operations according to a read sequence, each entry including a status of the set of media management operations for one of the plurality of memory devices.

[0009] Describe a non - transitory computer - readable storage medium. In some instances, the non - transitory computer - readable storage medium may include instructions that, when executed by a processing device, cause the processing device to: issue a plurality of read commands related to a set of media management operations of a plurality of transfer units according to a read sequence, each read command including an instruction for reading one of the transfer units at a source address of a memory subsystem; store a plurality of entries related to the set of media management operations, each entry including a status of the set of media management operations for one of the transfer units, wherein the read sequence is implicit in the plurality of entries; and issue a plurality of write commands related to the set of media management operations at least in part based on the plurality of entries and the read sequence, each write command including an instruction for writing one of the transfer units to a corresponding destination address of the memory subsystem. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The present invention will be more fully understood from the following detailed description and the accompanying drawings of various embodiments of the invention. However, the drawings should not be regarded as limiting the invention to a particular embodiment, but are for explanation and understanding only.

[0011] Figure 1 Illustrate an example computing system including a memory subsystem according to some examples of the present invention.

[0012] Figure 2 Is a flowchart of an example method for maintaining sequencing for media management of a memory subsystem according to some examples of the present invention.

[0013] Figure 3 Is a block diagram of an example method for maintaining sequencing for media management of a memory subsystem according to some examples of the present invention.

[0014] Figure 4 Is an example scoreboard for maintaining sequencing for media management of a memory subsystem according to some examples of the present invention.

[0015] Figure 5 Is a block diagram of an example computer system in which examples of the present invention may operate. DETAILED DESCRIPTION

[0016] Aspects of the present invention relate to maintaining the operation and / or data sequencing for media management of a memory subsystem. The memory subsystem can be a storage device, a memory module, or a combination of a storage device and a memory module. Refer to Figure 1 Examples of storage devices and memory modules are described. Generally, a host system can utilize a memory subsystem that includes one or more memory devices storing data. The host system can provide data stored at the memory subsystem and can request data retrieved from the memory subsystem.

[0017] The memory device can be a non-volatile memory device. A non-volatile memory device is an encapsulation of one or more dies. Each die can be composed of one or more planes. For some types of non-volatile memory devices (e.g., "NAND" devices), each plane is composed of a set of physical blocks. Each block is composed of a set of pages. Each page is composed of a set of memory cells storing data bits. For some memory devices such as NAND devices, the block is the smallest unit that can be erased, and pages within a block cannot be erased individually. For such devices, the erase operation is performed one block at a time.

[0018] The pages of a block can contain valid data, invalid data, or no data. Invalid data is data that is marked as obsolete as a new version of the data is stored on the memory device. Invalid data includes data that was previously written but is no longer associated with a valid logical address (e.g., a logical address referenced by the host system in a physical-to-logical (P2L) mapping table). Valid data is the most recent version of such data stored on the memory device. The memory subsystem can mark data as invalid based on information received, for example, from an operating system. Pages containing no data include pages that have been previously erased and not written to.

[0019] The memory subsystem controller can perform operations for media management algorithms such as wear leveling, refresh, garbage collection, scrubbing, etc. A block can have some pages containing valid data and some pages containing invalid data. To avoid waiting for all pages in a block to have invalid data to erase and reuse the block, an algorithm hereinafter referred to as "garbage collection" can be invoked to allow the block to be erased and released as a free block for subsequent write operations. Garbage collection is a set of media management operations that includes, for example: selecting a block containing valid and invalid data; selecting pages in the block containing valid data; copying the valid data to a new location (e.g., a free page in another block); marking the data in the previously selected pages as invalid; and erasing the selected block.

[0020] "Discarded item collection" as described below involves selecting blocks, rewriting valid data from the selected blocks to other blocks, and erasing all invalid and valid data stored at the selected blocks. The valid data from multiple selected blocks can be copied to fewer other blocks, and then the selected blocks can be erased. Thus, the number of blocks that have been erased can be increased so that more blocks are available for storing subsequent data from the host system.

[0021] During discarded item collection, the valid data of the block to be erased is first read into a buffer and stored by the buffer based on one or more read commands issued by the memory subsystem controller, and the corresponding page (e.g., the page on which the valid data is contained) is erased. Then, the valid data can be written (e.g., rewritten) to the memory device (e.g., a different page of the memory device). To write the valid data to a location (e.g., a different page of the memory device), a write command is issued by the memory subsystem controller, and each write command indicates the memory address (e.g., the destination memory address) to which the valid data is to be written.

[0022] In some discarded item collection procedures, the write command is issued after the corresponding read command is completed. The read commands are issued in a given order (e.g., a first sequential order), but in some cases, the read commands are not typically completed in the same order. Since the write command is issued after the corresponding read command is completed, the write commands are not issued in the same order as the read commands are issued (i.e., the write commands are issued in a non-sequential manner relative to the order in which the read commands are issued). Such conventional write techniques (e.g., writing the valid data back to the blocks in a non-sequential manner during the discarded item collection procedure) can cause the memory subsystem to experience a performance loss because the data blocks are not written to the pages in order, which can increase the latency of future read operations performed on the data blocks.

[0023] Aspects of the present invention solve these and other problems by using a scoreboard, which is a tracking data structure for maintaining the sequencing of operations and / or data for media management (e.g., for garbage collection). For example, when pages read valid data from a block during garbage collection, the scoreboard can store entries related to the sequence of read operations for garbage collection and use these entries to maintain (e.g., track) the order in which pages are read. Thus, after erasing the block, the valid data pages can be written (e.g., rewritten) to a new location in the same order as the pages were read (e.g., in sequential order). That is, the write commands for the valid data pages can be issued in the same order as the read commands were issued, which can result in the data being stored in the new location in the same order as it was originally stored. Maintaining sequencing during garbage collection can improve the overall performance of the memory subsystem. For example, the read performance of the system can be improved, which can improve the ability of the memory subsystem to aggregate read operations (e.g., into multi-plane reads). In some instances, aggregating multiple read operations can cause the memory subsystem to experience reduced power consumption. In other cases, the read speed can be increased because data can be read at the destination location in the same order in which it was written at the source location, which can allow the memory subsystem to perform read-at-a-time or other fast read operations.

[0024] First, the features of the present invention are described in the context of the computing system described in Figure 1 The features of the present invention are described in the context of the method diagrams and scoreboards for maintaining sequencing for media management of a memory subsystem described in Figures 2 to 4 The features of the present invention are further illustrated and described with reference to a computer system related to the scoreboard for maintaining sequencing for media management described in Figure 5 These and other features of the present invention are described with reference to the computer system.

[0025] Figure 1 An example computing system 100 including a memory subsystem 110 is described in accordance with some embodiments of the present invention. The memory subsystem 110 can include media such as, for example, one or more non-volatile memory devices (e.g., memory device 130), one or more volatile memory devices (e.g., memory device 140), or a combination thereof.

[0026] The memory subsystem 110 can be a storage device, a memory module, or a hybrid of a storage device and a memory module. Examples of storage devices include solid state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controllers (eMMCs), universal flash storage (UFS) drives, secure digital (SD) cards, and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small outline DIMMs (SO-DIMMs), and non-volatile DIMMs (NVDIMMs).

[0027] The computing system 100 can be, for example, a desktop computer, a laptop computer, a network server, a mobile device, a vehicle (such as an airplane, a drone, a train, an automobile, or other transportation vehicle), an Internet of Things (IoT) enabled device, an embedded computer (such as an embedded computer included in a vehicle, industrial equipment, or a networked commercial device), or a computing device such as this computing device that includes a memory and a processing device.

[0028] The computing system 100 can include a host system 105 coupled to one or more memory subsystems 110. In some instances, the host system 105 is coupled to different types of memory subsystems 110. Figure 1 An example of a host system 105 coupled to one memory subsystem 110 is illustrated. As used herein, "coupled to" or "coupled with" generally refers to a connection between components, which can be an indirect communication connection or a direct communication connection (e.g., without an intervening component), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

[0029] The host system 105 can include a processor chipset and a software stack executed by the processor chipset. The processor chipset can include one or more cores, one or more caches, a memory controller (such as an NVDIMM controller), and a storage protocol controller (such as a PCIe controller, a SATA controller). The host system 105 uses the memory subsystem 110, for example, to write data to the memory subsystem 110 and read data from the memory subsystem 110.

[0030] The host system 105 can be coupled to the memory subsystem 110 using a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect Express (PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), Dual In-line Memory Module (DIMM) interfaces (e.g., DIMM socket interfaces that support Double Data Rate (DDR)), and the like. The physical host interface can be used to transfer data between the host system 105 and the memory subsystem 110. When the memory subsystem 110 is coupled to the host system 105 via a PCIe interface, the host system 105 can further utilize a Non-Volatile Memory Express (NVMe) interface to access memory components (e.g., memory device 130). The physical host interface can provide an interface for transferring control, address, data, and other signals between the memory subsystem 110 and the host system 105.

[0031] Memory devices can include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) can be, but are not limited to, Random Access Memory (RAM), such as Dynamic RAM (DRAM) and Synchronous DRAM (SDRAM).

[0032] Examples of non-volatile memory devices (e.g., memory device 130) include NAND-type flash memory. Another example of a non-volatile memory device is write-in-place memory, such as 3D cross-point (“3DXP”) memory. A cross-point non-volatile memory array can perform bit storage based on bulk resistance changes along with a stackable cross-gate format data access array. Additionally, compared to many flash-based memories, cross-point non-volatile memory can perform write-in-place operations, where non-volatile memory cells can be programmed without first erasing the non-volatile memory cells.

[0033] Each of the memory devices 130 may include one or more memory cell arrays. One type of memory cell, such as a single-level cell (SLC), may store one bit per cell. Other types of memory cells, such as multi-level cells (MLC), triple-level cells (TLC), and quad-level cells (QLC), may store multiple bits per cell. In some embodiments, each of the memory devices 130 may include one or more memory cell arrays, such as SLC, MLC, TLC, QLC, or any combination thereof. In some embodiments, a particular memory device may include an SLC portion and an MLC portion, a TLC portion, or a QLC portion of memory cells. The memory cells of the memory devices 130 may be grouped into pages, which may refer to the logical units of the memory device for storing data. For some types of memory, such as NAND, pages may be grouped to form blocks.

[0034] Although non-volatile memory devices such as NAND-type flash memory are described, the memory devices 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase change memory (PCM), self-selecting memory, other chalcogenide-based memories, ferroelectric RAM (FeRAM), magnetic RAM (MRAM), "NOR" flash memory, electrically erasable programmable ROM (EEPROM).

[0035] The memory subsystem controller 115 (or simply controller 115) may communicate with the memory devices 130 to perform operations such as reading data, writing data, or erasing data at the memory devices 130 and other such operations. The memory subsystem controller 115 may include hardware such as one or more integrated circuits and / or discrete components, buffer memory, or a combination thereof. The hardware may include digital circuitry having dedicated (i.e., hard-coded) logic for performing the operations described herein. The memory subsystem controller 115 may be a microcontroller, dedicated logic circuitry (such as a field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.), or other suitable processor.

[0036] The memory subsystem controller 115 may include a processor 120 (such as a processing device) configured to execute instructions stored in local memory 125. In the illustrative example, the local memory 125 of the memory subsystem controller 115 includes embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines for controlling the operation of the memory subsystem 110, including handling communications between the memory subsystem 110 and the host system 105.

[0037] In some instances, the local memory 125 may include memory registers that store memory pointers, fetched data, etc. The local memory 125 may also include a read-only memory (ROM) for storing microcode. Although the example memory subsystem 110 in Figure 1 is illustrated as including the memory subsystem controller 115, in another example of the present invention, the memory subsystem 110 does not include the memory subsystem controller 115, but may rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory subsystem).

[0038] Generally, the memory subsystem controller 115 may receive commands or operations from the host system 105 and may convert the commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may be responsible for other operations associated with the memory device 130, such as wear leveling operations, garbage collection operations, error detection and error correction code (ECC) operations, encryption operations, cache operations, and address translation between logical addresses (e.g., logical block addresses (LBAs), namespaces) and physical addresses (e.g., physical block addresses). The memory subsystem controller 115 may further include host interface circuitry that communicates with the host system 105 via a physical host interface. The host interface circuitry may convert commands received from the host system into command instructions for accessing the memory device 130 and convert responses associated with the memory device 130 into information for the host system 105.

[0039] The memory subsystem 110 may also include additional circuitry or components not illustrated. In some instances, the memory subsystem 110 may include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that may receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0040] In some instances, the memory device 130 includes a local media controller 135 that operates together with the memory subsystem controller 115 to perform operations on one or more memory cells of the memory device 130. An external controller (e.g., the memory subsystem controller 115) may manage the memory device 130 externally (e.g., perform media management operations on the memory device 130). In some embodiments, the memory device 130 is a managed memory device, which is an original memory device combined with a local controller (e.g., the local controller 135) for media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0041] Memory subsystem 110 includes a scoreboard manager 150 that can maintain sequencing for media management. For example, the scoreboard manager 150 can perform a garbage collection operation, through which data is migrated from one location (e.g., a source memory address) to another location (e.g., a target or destination memory address) independent of any direct host interaction. In some instances, the scoreboard manager 150 can pack valid data together to free up space for new writes, for error avoidance, for wear leveling, and / or for recovering redundant array of independent nodes (RAIN) parity protection in case of a write error. Additionally or alternatively, the scoreboard manager 150 can be used to transfer data from one or more source blocks (e.g., one or more NAND cell blocks) to one or more destination blocks in the same order as the data was initially written (e.g., sequentially).

[0042] In some instances, memory subsystem controller 115 includes at least a portion of the scoreboard manager 150. For example, memory subsystem controller 115 can include a processor 120 (e.g., a processing device) configured to execute instructions stored in local memory 125 for performing the operations described herein. In some instances, the scoreboard manager 150 is part of the host system 105, an application, or an operating system.

[0043] The scoreboard manager 150 can perform operations for maintaining sequencing for media management (e.g., garbage collection). For example, the scoreboard manager 150 can manage (e.g., track) valid data pages read from a block during garbage collection. Specifically, the scoreboard manager 150 can track the order of the read pages (e.g., the order in which read commands are issued for a given memory address at the source location). After erasing a block (which can be performed by the scoreboard manager 150 or another component), the valid data can be written (e.g., rewritten) to a new location in sequential order. That is, write commands for the valid data can be issued (e.g., by processor 120) in the same order as the read commands were issued (i.e., in the same order as the read commands were initially stored on the block). The write commands can be issued based on the status of one or more entries managed by the scoreboard manager 150. Further details regarding the operation of the scoreboard manager 150 are described below.

[0044] Figure 2 is a flowchart of an example method 200 for maintaining sequencing for media management of a memory subsystem in accordance with some instances of the present invention. Method 200 can be executed by processing logic that can include hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, an integrated circuit, etc.), software (e.g., instructions running or executing on a processing device), or a combination thereof. In some instances, method 200 is performed by Figure 1is performed by the scoreboard manager 150. Although shown in a particular sequence or order, the order of operations may be modified unless otherwise specified. Accordingly, the illustrative examples should be understood as merely examples, and the operations shown may be performed in a different order and some operations may be performed in parallel. Additionally, one or more operations may be omitted in each example. Thus, not all operations are required in every example. Other method flows are possible.

[0045] At operation 205, the processing device may issue a set of read commands related to a set of media management operations for a set of transfer units (TUs) according to a read sequence. In one example, the set of media management operations is for discard item collection. In other examples, the set of media management operations is for other media management algorithms such as wear leveling. A TU refers to the smallest data size that is internally managed by a memory subsystem controller, a local media controller, or a host system. In some examples, the set of TUs may correspond to one or more data blocks of the memory subsystem. In some examples, the read sequence may be implicit in a set of entries. In some examples, each read command may include an instruction to read one of the TUs at a source address of the memory subsystem. In some examples, method 200 may include receiving a set of read values that is a subset of the set of TUs in response to a corresponding subset of the set of read commands. The set of read values may be received in an order different from the read sequence. In some examples, the read sequence may correspond to the physical-to-logical address mapping order of the set of TUs.

[0046] At operation 210, the processing device may store a set of entries associated with the set of media management operations. In some examples, each entry may include a status of a media management operation for one of the TUs (e.g., the status of a media management operation for discard item collection). In some examples, each entry may correspond to a pairing of a logical address and an associated physical address for one of the TUs.

[0047] In some examples, method 200 may include updating the status of a media management operation of an entry for one of the TUs based at least in part on a received read value in the set of read values that corresponds to one of the TUs. In some examples, the status of the media management operation may include one of a buffer allocation status, a read request send status, a read response receive status, or a write request send status. In some examples, method 200 may include discarding each scoreboard entry from a storage device that receives a corresponding invalid read response. In some examples, discarding a scoreboard entry may include deleting (e.g., erasing) the scoreboard entry from the scoreboard.

[0048] At operation 215, the processing device may issue a plurality of write commands related to the set of media management operations based at least in part on the set of entries and the read sequence. In some examples, each write command may include an instruction to write one of the TUs to a corresponding destination address of the memory subsystem.

[0049] In some instances, method 200 may include: issuing a first read command for a first TU of a TU group; issuing a second read command for a second TU of the TU group; receiving a first read response to the first read command after receiving a second read response to the second read command; and issuing a first write command corresponding to the first read response before issuing a second write command corresponding to the second read response. In some instances, the second TU may follow the first TU in the entry group according to a read sequence.

[0050] Note that the above method describes possible implementations, and the operations and steps may be rearranged or otherwise modified and other implementations are possible. Additionally, parts from two or more of the methods may be combined.

[0051] Figure 3 An example of method 300 for maintaining sequencing for media management of a memory subsystem in accordance with the examples disclosed herein is illustrated. Method 300 illustrates stages for identifying valid data (e.g., at stage 305), reading the valid data (e.g., at stage 310), and issuing write commands (e.g., at stage 315). In some instances, the operations performed as described with reference to Figure 3 may be implemented at the memory subsystem and may utilize scoreboard 302. Additionally, the operations may be performed in accordance with the operations of the host system and / or local media controller and may be implemented based on the setting of a state machine. In some instances, method 300 may illustrate range flow program 320 and replay flow program 325.

[0052] Method flow 300 may illustrate one or more media management operations for media management (e.g., media management operations for garbage collection). During garbage collection, data may be migrated (e.g., within a memory device) from one location (e.g., from a source memory address) to another location (e.g., to a destination memory address) independent of any direct host interaction. Garbage collection may be performed to pack valid data together to free space for new writes, for error avoidance, for wear leveling, and / or for recovering RAIN parity protection in the event of an error. Additionally or alternatively, garbage collection may consist of moving or copying data from one or more source blocks (e.g., one or more NAND cell blocks) to one or more destination blocks. In some instances, garbage collection may result in data consolidation to free resources (e.g., NAND cells) for subsequent erase and new write processing.

[0053] In some instances, the data blocks transferred during media management may be or may be referred to as transfer units (TUs) and may be processed by a memory subsystem controller (e.g., processor 120 as described with reference to Figure 1 ), a local media controller, or a host system (e.g.,Figure 1 The minimum data size managed internally by the host system 105), corresponding to a logical address (e.g., a TU address (TUA)) and a physical address (e.g., an abstract physical address (e.g., a flash logical address (FLA)), which may be related to the physical address of the NAND unit referred to as the platform physical address (PPA)). To consolidate data and / or free up resources for subsequent access operations, a TU may be written to a new location (e.g., a destination address), and the original block (e.g., the block from which the TU is moved) may be erased. Candidates (e.g., blocks) for media management (e.g., garbage collection) may be selected using a tree (pool, list, queue, etc.). In some instances, the candidates may be maintained by the scoreboard 302. Based on the identification of valid TUs and the scoreboard 302 maintaining the tree, a set of sequential operations for media management (e.g., garbage collection) may be performed. As discussed herein, writing TU units sequentially (e.g., in the same order as each TU is read) to a new block may be beneficial for improving the performance of the memory subsystem.

[0054] To sequentially move (e.g., write) valid TUs to a destination block, the scoreboard 302 may be or may include a linked list. The linked list may be utilized by the scoreboard 302 due to its ability to maintain a sequence of entries. In other instances, the scoreboard 302 may be or may include any type of data structure (e.g., (e.g.) a circular buffer or a tree) capable of maintaining a sequence of entries. Each linked list may include at least one TUA and FLA associated with a TU. Additionally or alternatively, among other parameters that may be included in the linked list, the linked list may include a next node identifier. The next node identifier may indicate the subsequent TU for media management (e.g., garbage collection). Thus, using a list in which each entry indicates the next (e.g., subsequent) TU may allow valid TUs to be sequentially written to the destination block.

[0055] In some instances, a tree may be maintained by the scoreboard 302. The tree may be composed of a list (queue, pool, etc.) of TUs for media management (e.g., garbage collection). For example, a read operation may occur and the TUA and / or FLA of each TU (e.g., sequentially) may be stored in the scoreboard 302 according to the order in which the read commands are issued. The status of each TUA and / or FLA may be maintained in a list (e.g., a linked list) at the scoreboard 302. The order of the list (e.g., the order in which the read commands are issued) may allow TUs to be sequentially written to the destination block, regardless of the order in which the responses to the read commands (e.g., read responses) are received. In other instances, the order of the linked list may be calculated on the fly using a prediction algorithm (e.g., an algorithm for predicting the order in which the host system may issue read commands).

[0056] In stage 305, one or more operations may be performed to identify valid data (e.g., TUs). Although the count of valid TUs in a block may be readily obtained (e.g., for use by a controller), the location of each valid TU may be identified. In some instances, a range flow program 320 or a replay flow program 325 may be used to identify the location of valid TUs. The range flow program 320 may include processing commands that fold data across the entire memory subsystem (e.g., shift data and organize data). Additionally or alternatively, the replay flow program 325 may use a buffer (e.g., a read buffer 335) and may cycle through the physical locations in a block.

[0057] In stage 310, one or more operations may be performed to read the valid data (e.g., TUs) identified in stage 305. For example, after identifying valid TUs, the FLA corresponding to each valid TU may be compared to the tree maintained by the scoreboard 302. If the FLA corresponding to a valid TU matches the FLA maintained by the scoreboard 302, then the read command associated with the valid TU may occur. Conversely, if the FLA does not match, then the entry maintained by the scoreboard 302 may be released (e.g., moved to the end of a linked list). In other instances, if the FLA does not match, the system may be configured to continue cycling through the valid TUs until the FLA matches an entry maintained by the scoreboard 302.

[0058] In stage 315, one or more operations may be performed to write the valid data (e.g., TUs) read in stage 310. As discussed herein, when the FLA corresponding to a valid TU matches the FLA maintained by the scoreboard 302, the read command associated with the valid TU is issued. Additionally or alternatively, based on issuing the read command, the data associated with the valid TU may be written (e.g., moved) into a destination block (e.g., to a destination address). Due to the use of a linked list, the data associated with the valid TUs may be written sequentially into the destination block.

[0059] In stage 305, various methods may be employed to determine valid data (e.g., valid TUs). For example, the replay flow program 325 may support determining valid data by iterating through the individual TUs stored in a buffer (e.g., within a read buffer 335). The buffer may include one or more addresses (e.g., TUA and / or FLA) corresponding to the location in the block from which the respective TU was read. In some instances, the replay flow program 325 may be selected based on one or more settings associated with a mode register and / or a controller (e.g., a memory subsystem controller, a local media controller). In some instances, the replay flow program 325 may be executed in multiple stages (e.g., a first stage 330 and a second stage 340).

[0060] When the replay stream program 325 is employed, signal 371 may be received by the read buffer 335 during the first stage 330. Signal 371 may initiate the read buffer 335 to cycle through one or more TUs (illustrated by 373 for example). That is, the read buffer 335 may map (such as determine, identify, etc.) the TUA and FLA of potential valid TUs according to the order in which the read commands are issued therein. During the second stage 340, the TUA and FLA of each TU may be identified and provided to the scoreboard 302 (e.g., via signal 375 and / or signal 369). In some instances, the first stage 330 and the second stage 340 may be asynchronous (e.g., the durations may occur between the start of the first stage 330 and the completion of the second stage 340).

[0061] After identifying the TUA and FLA and providing them to the scoreboard, a list (such as a linked list) may be compiled at the scoreboard 302. In some instances, then, a lookup for the TUA and FLA may be issued (e.g., at 350) to determine whether the associated data remains valid, and if so, the valid data may be written (e.g., sequentially) to the destination block. In some instances, the lookup 350 may occur in the order in which the read responses are received and may be performed to determine whether the TUA and FLA match the entries of the tree stored at the scoreboard 302. Since the tree may utilize a linked list, the TUA and FLA stored at the scoreboard 302 may be compared (e.g., sequentially compared) with the corresponding TUA and FLA of each received read response. Depending on the result of the comparison, a read command may be issued and the TU may be written to the destination block.

[0062] The range stream program 320 may include processing commands to fold data of the entire memory subsystem (e.g., move data and organize data). For example, the range stream program 320 may be selected based on one or more settings associated with a mode register and / or a controller (such as a memory subsystem controller, a local media controller). That is, the use of the range stream program 320 may be optional. In some instances, the range stream program 320 may include making a request indicating the start and end lists of the TUA to be scanned. In some instances, when this request is made (i.e., recognized by the memory subsystem controller and / or the host system), a flag is set to guide the firmware along the list of the TUA to be scanned.

[0063] When the range flow program 320 is employed, read commands for each FLA in a particular block can be issued. The corresponding TUA and FLA can be stored as part of a list (such as a linked list) in the scoreboard 302. Then, in some instances, a search for the TUA and FLA can be issued (e.g., at 350) to determine whether the associated data remains valid and to write the valid data (e.g., sequentially) to the destination block. Since the tree can utilize the linked list, the identified TUA and FLA can be compared with the first entry (e.g., the head of the list) of the list. Depending on the result of the comparison, a read command can be issued and the TU can be written to the destination block.

[0064] In some instances, both the range flow program 320 and the replay flow program 325 can cause a search 350 to be performed to determine whether the read response (e.g., the TUA and FLA corresponding to the read response) matches an entry in the tree stored at the scoreboard 302. Accordingly, the TUA and FLA associated with the read response can be provided to the scoreboard 302 via the signal 381. The signal 381 can be transmitted to the scoreboard 302 by the controller or another component. In some instances, the signal 381 can be transmitted to the scoreboard 302 at a first time (e.g., at 350 (not shown)), and the result of the comparison can be received at a second time (e.g., via the signal 383 at 355). Accordingly, in some instances, a portion of the comparison can occur at stage 305 (e.g., during stage 305) and at stage 310 (e.g., during stage 310). In some instances, the steps performed at 350 and 355 can be asynchronous (e.g., the durations can occur between the steps performed by the respective components at 350 and 355).

[0065] When a read response is received, the corresponding TUA and FLA can be compared with the first entry (e.g., the head of the list) of the tree stored at the scoreboard 302. In some examples, the TUA and FLA may not match the first entry. For example, the comparison of the first entry with the first received TUA and FLA can indicate a mismatch. In this instance, the first entry of the list can be released (e.g., moved to the bottom of the list). Accordingly, the TUA and FLA can be compared with a subsequent entry (or subsequent entries) in the list until a match is determined. After a match is determined, a read of the associated TU can be issued (e.g., at 360), and subsequently the TU can be written to the destination block (e.g., at 365, which can occur at stage 315). In some instances, stage 310 and stage 315 can be asynchronous (e.g., the durations can occur between the two stages).

[0066] The TUA and FLA associated with each valid TU can be compared to a list in the manner described herein. When a match does not exist, an entry in the scoreboard can be released. Conversely, when a match exists, a read can be issued and the TU can be written to the destination block. When the TU is written to the destination block (e.g., when a write command is issued at 365), the associated entry in scoreboard 302 can be released. Thus, this process can result in the TUs being written to the destination block in an order identical to the order in which the read commands were issued, which can maintain the sequentiality of the overall media management (e.g., garbage collection).

[0067] Figure 4 Example block diagram 400 illustrating media management operations for maintaining the sequentiality of garbage collection according to an example disclosed herein. The operations illustrate a read sequence 405, a read response 410, and a write command 415. In some examples, the write command 415 can be based on the order of the read sequence 405 and the read response 410 during garbage collection. Additionally or alternatively, the operations can be implemented using a scoreboard 425, which can be an example of the scoreboard 302 described in reference Figure 3 Therein. In some examples, the scoreboard 425 can include one or more scoreboard entries 420 that facilitate garbage collection, such as entries of a tree described in reference Figure 3 Therein.

[0068] In some examples, Figure 4 illustrates garbage collection operations. As discussed herein, garbage collection can occur to migrate data from one location to another independent of any direct host system interaction. In Figure 4 this context, each of the read sequence 405, the read response 410, and the write command 415 can be associated with a block (e.g., a data block). Each block can include one or more pages capable of storing a finite amount of data. For example, each block can include 32 pages each capable of storing 4 kilobytes (KB) or 8 KB of data (or other amounts). For illustration, each of the read sequence 405, the read response 410, and the write command 415 illustrate twelve (12) valid data blocks (numbered 1 through 12) and various dirty / expired data and / or erased data blocks. Dirty data is data in the cache memory that has not been saved to the media (e.g., NAND) in its most recent version. Expired data includes data that was previously written but is no longer associated with a valid logical address (e.g., a logical address referenced by the host system in a physical-to-logical (P2L) mapping table). Each valid data block (e.g., 1 through 12) can be or can be referred to as a TU.

[0069] Range flow programs (e.g., the range flow program 320 described in reference Figure 3 Therein) and / or replay flow programs (e.g., the replay flow program described in reference Figure 3The described replay stream program 325) can be associated with the read sequence 405. For example, the range stream program and / or the replay stream program can issue one or more read commands for reading TUs for discard item collection. As Figure 4 shown, and for illustration only, the read sequence 405 can issue one or more read commands for TUs 1 to 12. The read sequence 405 can issue read commands simultaneously such that the read commands for each subsequent TU are issued in sequence (i.e., the read commands for each TU are issued continuously). The read commands can be stored in the scoreboard 425 as a list (such as a linked list, circular buffer, or tree). In some instances, the TUA and FLA associated with each TU can be stored as scoreboard entry 420 in the scoreboard 425 (such as Figure 1 the scoreboard 150) maintained by a scoreboard manager (such as Figure 3 the scoreboard 302).

[0070] In some instances, the scoreboard entry 420 can store the corresponding values associated with each TU. That is, the scoreboard 425 and the scoreboard entry 420 can be used as buffers to maintain the read values of each TU for discard item collection. Thus, when the associated read response (i.e., the response associated with the TUA and FLA stored in the scoreboard 425) is received, the corresponding values can be updated. A list of some potential states reflected by the scoreboard entry is illustrated in Table 1 below. The states reflected in Table 1 can reflect the scoreboard entry at any point in time.

[0071] Value Meaning 0 Empty 1 Find TUA / FLA pair 2 Send find request 3 Receive find response 4 Allocate buffer 5 Send read request 6 Receive read response 7 Send write request

[0072] Table 1

[0073] As shown in Table 1, the scoreboard 425 can contain various entries. Each of the pages (and TUs 1 to 12) can be associated with a corresponding entry. For example, some pages (and TUs) can be associated with the same entry, and other pages (and TUs) can be associated with different entries. Each entry represents the current state of the corresponding page and / or TU.

[0074] In some instances, the entry "0" represents the empty state. The empty state can indicate that the page is empty (e.g., it has been erased previously) and no valid data has been read from the page and / or the page can be freely written. In some instances, the entry "1" represents the identified TUA and FLA. In some instances, the entry "2" represents that a lookup has been performed on the TUA and FLA to determine whether the associated data is still valid.

[0075] In some instances, entry “3” represents a response as to whether data associated with the TUA and FLA is valid. If the data is valid, then the entry remains on the scoreboard. If the data is invalid, then the entry may be moved to the end of the linked list and assigned “0”. In some instances, entry “4” represents the allocation of valid data to a buffer (e.g., the read buffer 335 referenced in Figure 3 ). In some instances, entry “5” represents that valid data associated with the TUA and FLA has been read.

[0076] In some instances, entry “6” represents that valid data associated with the TUA and FLA has been received. In some instances, entry “7” represents that valid read data will be written. After the data is written, the entry may be assigned “0” and moved to the end of the linked list. This may indicate that the data has been successfully (and sequentially) written back.

[0077] After issuing the read sequence 405, read responses 410 may be received in a non-sequential order (e.g., at the scoreboard 425). For example, as Figure 4 shown, each response may be received in a non-sequential order or at least in an order different from the order in which the read sequence 405 was issued. Receiving the read responses 410 in a non-sequential order may be due to various reasons including (but not limited to) a particular channel being temporarily used for a different operation (e.g., for a host read operation). If the read responses 410 are written to the destination block in the order received (i.e., non-sequentially), then the overall performance of the memory subsystem will degrade. Therefore, issuing write commands 415 in a sequential order as Figure 4 shown may be beneficial.

[0078] To issue write commands 415 in the same order as the issued read sequence 405, a list (e.g., a linked list) can be maintained by the scoreboard 425. As discussed herein, when a read response 410 is received, the corresponding TUA and FLA can be compared with the first entry (e.g., the head of the list) of the list stored at the scoreboard 425. For example, when a read response "1" (i.e., the first valid TU) is received, it can be compared with the first entry of the read sequence 405 stored at the scoreboard 425. Since the entries (e.g., the associated TUA and FLA of the entry) match, the read response "1" can be written to the destination block first. That is, the write command 415 associated with the read response "1" can be issued first. If the read response "1" is not received first (e.g., if the read response "2" is received first), then the entries will not match. Accordingly, the entry associated with TU "1" stored at the scoreboard 425 can be freed (e.g., moved to the bottom of the list). Then, the read response "2" can be compared with the next stored entry (TU "2" stored at the scoreboard). Since these entries match, the read response "2" can be written to the destination block first. This process can continue such that the TUs are written to the destination block (e.g., issue write commands) in sequential order (e.g., in the order in which the read commands were issued). The performance of the associated memory subsystem can be improved by writing each TU to the destination block in sequential order.

[0079] Figure 5 An example machine of a computer system 500 that supports maintaining sequencing for media management in accordance with the examples disclosed herein. The computer system 500 can include a set of instructions for causing the machine to perform any one or more of the techniques described herein. In some examples, the computer system 500 can correspond to a host system (e.g., the host system 105 described with reference to Figure 1 ), the host system includes a memory subsystem (e.g., the memory subsystem 110 described with reference to Figure 1 ), coupled to or utilizing the memory subsystem or can be used to perform the operations of a controller (e.g., execute an operating system to perform operations corresponding to the scoreboard manager 150 described with reference to Figure 1 ). In some examples, the machine can be connected (e.g., networked) to other machines in a local area network (LAN), an intranet, an extranet, and / or the Internet. The machine can act as a server or a client machine in a client-server network environment, a peer machine in a peer-to-peer (or distributed) network environment, or a server or a client machine in a cloud computing infrastructure or environment.

[0080] The machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, network device, server, network router, switch, or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by the machine. Additionally, although a single machine is illustrated, the term "machine" can also include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0081] An example computer system 500 can include a processing device 505, a main memory 510 (such as ROM, flash memory, DRAM (such as SDRAM or Rambus DRAM (RDRAM), etc.), a static memory 515 (such as flash memory, static RAM (SRAM)), etc.), and a data storage system 525, which communicate with each other via a bus 545.

[0082] The processing device 505 represents one or more general-purpose processing devices, such as a microprocessor, central processing unit, or the like. More specifically, the processing device can be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or multiple processors implementing a combination of instruction sets. The processing device 505 can also be one or more special-purpose processing devices, such as an ASIC, FPGA, DSP, network processor, or the like. The processing device 505 is configured to execute instructions 535 for performing the operations and steps discussed herein. The computer system 500 can further include a network interface device 520 that communicates via a network 540.

[0083] The data storage system 525 can include a machine-readable storage medium 530 (also referred to as a computer-readable medium) on which one or more sets of instructions 535 or software embodying any one or more of the methodologies or functions described herein are stored. The instructions 535 can also reside, completely or at least partially, within the main memory 510 and / or within the processing device 505 during execution by the computer system 500, and the main memory 510 and the processing device 505 also constitute machine-readable storage media. The machine-readable storage medium 530, the data storage system 525, and / or the main memory 510 can correspond to a memory subsystem.

[0084] In one example, the instructions 535 include those for implementing corresponding to a scoreboard manager 550 (such as reference Figure 1Instructions for the functionality of the described scoreboard manager 150). Although the machine-readable storage medium 530 has been shown as a single medium, the term "machine-readable storage medium" can include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" can also include any medium that is capable of storing or encoding a set of instructions executable by a machine and causing the machine to perform any one or more of the methodologies of the present invention. The term "machine-readable storage medium" can include (but is not limited to) solid-state memory, optical media, and magnetic media.

[0085] Some portions of the foregoing detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0086] However, it should be borne in mind that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. The present invention may relate to the actions and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the registers and memories of the computer system and transforms it into other data similarly represented as physical quantities within the memories or registers of the computer system or other such information storage systems.

[0087] The present invention also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the intended purpose or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a computer-readable storage medium, such as (but not limited to) any type of disk (including floppy disks, optical disks, CD-ROMs, and magneto-optical disks), ROM, RAM, EPROM, EEPROM, magnetic or optical cards, or any type of media suitable for storing electronic instructions, each coupled to a computer system bus.

[0088] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used in conjunction with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method. The structure for various of these systems will appear as set forth in the following description. In addition, the present invention has not been described with reference to any particular programming language. It will be understood that various programming languages may be used to implement the teachings of the present invention as described herein.

[0089] The present invention may be provided as a computer program product or software, which may include a machine-readable medium having stored thereon instructions that can be used to program a computer system (or other electronic device) to perform a process according to the present invention. The machine-readable medium includes any mechanism for storing information in a form readable by a machine, such as a computer. In some instances, the machine-readable (e.g., computer-readable) medium includes a machine (e.g., computer) readable storage medium, such as a ROM, a RAM, a magnetic disk storage medium, an optical storage medium, a flash memory component, etc.

[0090] In the foregoing description, embodiments of the present invention have been described with reference to specific exemplary embodiments of the present invention. It is apparent that various modifications may be made to the present invention without departing from the broader spirit and scope of the embodiments of the present invention as set forth in the appended claims. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. A method of operating a memory subsystem, comprising: Issuing a plurality of read commands related to a set of media management operations of a plurality of transfer units according to a read sequence, wherein each transfer unit of the plurality of transfer units corresponds to one or more data blocks of the memory subsystem; Receiving a first subset of read responses according to a read response sequence at least in part based on issuing the set of media management operations, wherein the first subset of read responses is associated with a second subset of the plurality of read commands; And Issuing a write command for each received read response of the first subset of read responses, wherein each write command is issued based on the read sequence and includes an instruction for writing one of the plurality of transfer units to a corresponding destination address of the memory subsystem.

2. The method according to claim 1, further comprising: Receiving a set of read values for a third subset of the plurality of transfer units at least in part based on a third subset of the plurality of read commands.

3. The method according to claim 2, further comprising: Updating an indication of the set of media management operations of an entry of one of the plurality of transfer units at least in part based on receiving the set of read values for the third subset of the plurality of transfer units.

4. The method according to claim 3, further comprising: Removing each entry associated with the corresponding transfer unit from a scoreboard at least in part based on receiving an invalid read response for the corresponding transfer unit.

5. The method according to claim 3, wherein the indication of the set of media management operations includes one of an allocation status, a request send status, or a response receive status.

6. The method according to claim 1, wherein the read sequence corresponds to a physical-to-logical address mapping order of the plurality of transfer units.

7. The method according to claim 6, wherein the read response sequence is different from the read sequence.

8. A memory device, comprising: A memory array; And A controller coupled to the memory array, wherein the controller is operable to cause the memory device to: Issue a plurality of read commands related to a set of media management operations of a plurality of transfer units according to a read sequence, wherein each transfer unit of the plurality of transfer units corresponds to one or more data blocks of the memory array; Receive a first subset of read responses according to a read response sequence at least in part based on issuing the set of media management operations, wherein the first subset of read responses is associated with a second subset of the plurality of read commands; And Issue a write command for each received read response of the first subset of read responses, wherein each write command is issued based on the read sequence and includes an instruction for writing one of the plurality of transfer units to a corresponding destination address of the memory array.

9. The memory device according to claim 8, wherein the controller is operable to cause the memory device to: Receive a set of read values for a third subset of the plurality of transfer units at least in part based on a third subset of the plurality of read commands.

10. The memory device according to claim 9, wherein the controller is operable to cause the memory device to: Update an indication of the set of media management operations for an entry of one of the plurality of transfer units, at least in part based on receiving the set of read values for the third subset of the plurality of transfer units.

11. The memory device according to claim 10, wherein the controller is operable to cause the memory device to: Remove each entry associated with the corresponding transfer unit from the scoreboard, at least in part based on receiving an invalid read response for the corresponding transfer unit.

12. The memory device according to claim 10, wherein the indication of the set of media management operations includes one of an allocation status, a request send status, or a response receive status.

13. The memory device according to claim 8, wherein the read sequence corresponds to a physical-to-logical address mapping order of the plurality of transfer units.

14. The memory device according to claim 13, wherein the read response sequence is different from the read sequence.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing device, cause the processing device to: Issue a plurality of read commands related to a set of media management operations for a plurality of transfer units according to a read sequence, wherein each transfer unit of the plurality of transfer units corresponds to one or more data blocks of a memory subsystem; Receive a first subset of read responses according to a read response sequence, at least in part based on issuing the set of media management operations, wherein the first subset of read responses is associated with a second subset of the plurality of read commands; And Issue a write command for each received read response of the first subset of read responses, wherein each write command is issued based on the read sequence and includes instructions for writing one of the plurality of transfer units to a corresponding destination address in the memory subsystem.

16. The non-transitory computer-readable storage medium according to claim 15, wherein the processing device further: Receives a set of read values for a third subset of the plurality of transfer units, at least in part based on the third subset of the plurality of read commands.

17. The non-transitory computer-readable storage medium according to claim 16, wherein the processing device further: Updates an indication of the set of media management operations for an entry of one of the plurality of transfer units, at least in part based on receiving the set of read values for the third subset of the plurality of transfer units.

18. The non-transitory computer-readable storage medium according to claim 17, wherein the processing device further: Removes each entry associated with the corresponding transfer unit from the scoreboard, at least in part based on receiving an invalid read response for the corresponding transfer unit.

19. The non-transitory computer-readable storage medium according to claim 17, wherein the indication of the set of media management operations includes one of an allocation status, a request send status, or a response receive status.

20. The non-transitory computer-readable storage medium according to claim 15, wherein the reading sequence corresponds to the physical-to-logical address mapping order of the plurality of transfer units.

Images