Generating command snapshots in memory devices

Systems and methods are disclosed including a processing device operatively coupled to memory device. The processing device performs operations comprising receiving a memory access command specifying a logical address; determining a physical address associated with the logical address; determining a portion of the memory device that is referenced by the physical address; determine an endurance factor associated with the portion; and increasing, by a value derived from the endurance factor, a media management metric associated with a management unit of the memory device, wherein the management unit is referenced by the physical address.

TECHNICAL FIELD

Embodiments of the disclosure generally relate to memory sub-systems, and more specifically, relate to generating command snapshots in memory devices.

BACKGROUND

DETAILED DESCRIPTION

Memory access operations can be performed by the memory sub-system. The memory access operations can be host-initiated operations or memory sub-system controller initialed. For example, the host system can initiate a memory access operation (e.g., write operation, read operation, erase operation, etc.) on a memory sub-system. The host system can send memory access commands (e.g., write command, read command) to the memory sub-system, such as to store data on a memory device at the memory sub-system and to read data from the memory device on the memory sub-system. The data to be read or written, as specified by a host request, is hereinafter referred to as “host data”. A host request can include logical address information (e.g., logical block address (LBA), namespace) for the host data, which is the location the host system associates with the host data. The logical address information (e.g., LBA, namespace) can be part of metadata for the host data. Metadata can also include error handling data (e.g., ECC codeword, parity code), data version (e.g. used to distinguish age of data written), valid bitmap (which LBAs or logical transfer units contain valid data), etc. Memory access operations initiated by the memory sub-system controller can relate to maintenance operations, such as garbage collection, wear leveling, bad block management, block refresh operations, etc.

While processing the memory access commands, the memory sub-system can experience quality of service issues, such a latency caused by defects (i.e., “bugs”) in the electronic device, such as a memory sub-system. Debugging can involve finding and reducing the number of defects. Various debugging techniques can be used to detect anomalies, assess their impact, and schedule hardware changes, firmware upgrades, or full updates to a system. The goals of debugging include identifying and rectifying defects in the system (e.g., logical or synchronization problems in the firmware, or a design error in the hardware), and collecting system state information. System state information can include various information related to the operation of the memory sub-system, and can be used to analyze the memory sub-system to find ways to boost its performance or to optimize other important characteristics.

One example of system state information can include event data generated in the memory sub-system. An event, as used herein, generally refers to a detectable change of state caused by an action performed by hardware, software, and/or firmware in the memory sub-system. Examples of events include a memory sub-system controller sending and/or receiving data or accessing a memory location of a memory device, a warning related to some reliability statistic (e.g., raw bit error rate (RBER), wear leveling, etc.) of a memory device, an error experienced by the memory sub-system controller in reading data from or writing data to a memory device, garbage collection, encoding and/or decoding, retrieving memory access commands from a queue(s) (e.g., a scheduling queue, a submission queue, etc.), data reconstruction, direct memory access (DMA) operations, media scans, or any other event relating to memory access operations. Data relating to the event can include time data (e.g., a timestamp of when execution of the event began, a timestamp of when execution of the event concluded, timer data relating to the duration of executing the event, etc.), metric data (e.g., data relating to metrics used by the memory sub-system), error handling data (e.g., types of error handling operations performed), queueing data, etc.

Point-in-time debug information can be important to analyzing events being reported from customer use and/or during the qualification of the memory sub-system (e.g., an SSD). Debug information can include a snapshot of the state of the memory sub-system taken during the time that the reported issue occurred (e.g., an error or a failure). In particular, a snapshot can save the state of memory device registers, the memory, and other critical data area. Analyzing the debug information can help determine the root cause of the issue. In order to create a snapshot, each CPU core saves its hardware registers and/or other important regions of memory.

In some systems, the memory sub-system can be configured to generate multiple snapshots (periodic snapshots, snapshots during a specified time range, etc.) to sample event data from the memory sub-system and store the captured data in a data structure (e.g., a log file). The memory sub-system can then send the log to the host system for analysis. For example, the host system120can analyze the log data (such as timestamp data) to determine whether and when latency issues occurred.

However, sampling via multiple snapshots can generate significant latency issues in the memory sub-system. For example, sampling can consume thousands of instruction cycles for capturing and extracting the debug information. Furthermore, sending the log file, to the host system, that contains data relating to thousands of snapshots can consume additional instruction cycles, which further worsens the experienced latency. In other memory sub-systems, sampling via multiple snapshots can require a large and costly infrastructure. Accordingly, a system capable of capturing debug information without adversely affecting the performance of the memory sub-system is desirable.

Aspects of the present disclosure address the above-noted and other deficiencies by enabling the memory sub-system to perform a command snapshot process. In particular, the memory sub-system controller can first determine whether a received memory access command satisfies a trigger condition. The trigger condition can be satisfied due to the memory access command specifying a certain logical address or a certain logical address range, a memory access command type (e.g., a read command, a write command, an erase command, a deallocate command, etc.), the memory access command occurring at a predefined interval value (e.g., each thousandth memory access command, each ten thousandth memory command, etc.), any other software based trigger, any firmware based trigger, any external trigger, etc. In response to the memory access command satisfying the trigger condition, the memory sub-system controller can enable write operations on a set of debug registers. The debug register can be located on the memory sub-system controller and/or on the memory device. Each debug register can be used to capture event data generated by the memory access command. In one embodiment, the memory sub-system can include a set of four debug registers. The first debug register can store time data (e.g., a timestamp of when execution of the event began, a timestamp of when execution of the event concluded, timer data relating to the duration of executing the event, etc.) relating to retrieving the memory access command from a memory access command queue. The second debug register can record time data relating to accessing the memory device. The third debug register can record time data relating to error handling and/or encoding and decoding operations performed on the memory access command. The fourth debug register can record time data relating to completion of the memory access command. In response to capturing the event data, the memory sub-system controller can disable write operations on the set of debug registers to prevent a subsequent memory access command from overwriting the captured event data prior to the memory sub-system controller extracting the captured event data from the set of debug registers. The memory sub-system controller can further set an indication that the set of debug registers contain event data.

In some embodiments, responsive to detecting the indication that the set of debug registers contain event data, the memory sub-system controller can extract the event data from the set of debug registers and generate a log file. The memory sub-system controller can the store the log file on the memory device, send the log file to the host system, etc. In some embodiments, the memory sub-system controller can append the log file to the memory access command. For example, in response to receiving a read command, the memory sub-system controller can capture the event data relating to the read command, using the set of debug registers, and then append the log containing the event data to read data sent to the host system.

In some embodiments, in response to a subsequent memory access command satisfying the trigger condition, the memory sub-system controller can enable write operations on another set of debug registers (e.g., another set of four debug registers). Thus, each debug register of the second set can be used to capture event data generated by the subsequent memory access command. By switching to the second set of debug registers, the memory sub-system controller can capture event data relating to the subsequent memory access command while extracting captured data from the first set of debug registers. The memory sub-system controller can alternate between sets of debug registers for subsequent memory access commands.

Advantages of the present disclosure include, but are not limited to, providing an improved system for capturing snapshots in response to specific software, hardware, or firmware triggers. These snapshots provides targeted point-in-time debug information, which can be used to determine the root cause of the issue that led to quality of service issues (e.g., latency issues) or system failure. In addition, these snapshots provide targeted point-in-time debug information relating to queueing data, error handling operations, etc. Aspects of the present disclosure provide reduced latency in capturing the debug state (registers, memory, and/or debug information) by enabling the hardware and/or software to capture event data using dedicated sets of debug registries, thus improving the performance of the memory device.

The memory device130can include one or more decks. A deck can be defined as an array of memory cells with electronically conductive access lines. Multiple decks can be stacked within memory device130. Each deck can have inherently different levels of endurance (e.g., an indication of approximately how many times the deck can be written to, read, and/or erased before physical wear causes the deck to fail).

In the illustrated example, the local memory119of the memory sub-system controller115includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system110, including handling communications between the memory sub-system110and the host system120.

The memory sub-system110includes a snapshot management component113that can used to perform a snapshot process (e.g., capture event data) for each memory access command that satisfies a trigger condition. In some embodiments, the memory sub-system controller115includes at least a portion of the snapshot management component113. In some embodiments, the snapshot management component113is part of the host system110, an application, or an operating system. In other embodiments, local media controller135includes at least a portion of snapshot management component113and is configured to perform the functionality described herein.

The snapshot management component113can configure a trigger condition(s). The trigger condition can be related to any process, characteristic, or data related to a memory access command. In some embodiments, the trigger condition can relate to logical address information. For example, the trigger condition can indicate a certain logical address (e.g., LBA 23), a certain logical address range (e.g., LBA 24-30), multiple certain logical addresses, multiple certain logical address ranges, or any combination thereof. To satisfy this trigger condition, a memory access command can specify the logical address indicated by trigger condition. In some embodiments, the trigger condition can relate to a memory access command type. The memory access command type can include a read command, a write command, an erase command, a deallocate command, etc. To satisfy this trigger condition, the memory access command can be of the type indicated by the trigger condition.

In some embodiments, the trigger condition can include a periodic command. The periodic command can relate to a memory access command that occurs at a predefined interval value. For example, the periodic command can be set to a predetermined value (e.g., each thousandth memory access command, every memory access command at 10 millisecond intervals, etc.). The snapshot management component113can maintain a memory access command counter, where each memory access command received by the memory sub-system controller115. The trigger condition can be satisfied responsive to the memory access command counter satisfying a threshold criterion (e.g., the predefined interval value).

In some embodiments, the trigger condition can include a firmware based trigger. The firmware based trigger can include any condition that can be generated or implemented by firmware of the memory sub-system110. For example, a firmware based trigger can include the condition that in response to an event or process occurring while processing a previous memory access command, perform the snapshot process in for the subsequent memory access command. In some embodiments, the trigger condition can include an external trigger. The external trigger can include a command issued by an external device (e.g., Peripheral Component Interconnect (PCI) device) coupled to a sideband management interface (e.g., system management bus (SMBus)). For example, an external device may receive statistics data, temperature data, or any other data related to the memory sub-system110. In response an external device based criterion being satisfied (e.g., temperature value crosses a threshold value), the external device can instruct the snapshot management component113to perform the snapshot function.

The trigger condition(s) can be configurable by the host system120. In some embodiments, the host system can enable a trigger condition from a predetermined set of trigger conditions. In some embodiments, host system120can configure a trigger condition from the predetermined set of trigger conditions. For example, the host system120can set the logical address trigger condition to be satisfied when a memory access command specifies a specific logical address (e.g., LBA 23). In some embodiments, the snapshot process operations can be enabled and disabled by the host system120.

In response to the memory access command satisfying the trigger condition, snapshot management component113can enable write operations on a set of debug registers. The debug registers can be located on snapshot management component113, memory device130, and/or memory device140. Each debug register can be configured to capture and store data relating to an event (a detectable change of state caused by an action performed by hardware, software, firmware, or a combination thereof). Thus, snapshot management component113can use each debug register to capture data relating to different events performed by the execution of the memory access command. An event can generally refer to a detectable change of state caused by an action performed by hardware, software, firmware, or a combination of any of the above in the memory sub-system. Examples of events include a memory sub-system controller sending and/or receiving data or accessing a memory location of a memory device, a warning related to some reliability statistic (e.g., raw bit error rate (RBER), wear leveling, etc.) of a memory device, an error experienced by the memory sub-system controller in reading data from or writing data to a memory device, garbage collection, encoding and/or decoding, retrieving memory access commands from a queue(s) (e.g., a scheduling queue, a submission queue, etc.), data reconstruction, direct memory access (DMA) operations, media scans, or any other event relating to memory access operations.

In some embodiments, the data captured by the debug registers can include time data relating to the corresponding event. For example, the time data can include a timestamp of when execution of the event began, a timestamp of when execution of the event concluded, timer data relating to the duration of executing the event, or any combination thereof. In some embodiments, the data captured by the debug registers can include metric data (e.g., data relating to metrics used by the memory sub-system), error handling data (e.g., types of error handling operations performed), queueing data, etc.

In response to capturing the event data, the snapshot management component113can disable write operations on the set of debug registers. In some embodiments, snapshot management component113can disable write operations on a set of debug register in response to determining that the last debug register of the set captured data, in response to detecting an indicator, etc. By disabling write operations, snapshot management component can prevent a subsequent memory access command from overwriting the captured event data prior to the snapshot management component113extracting the captured event data from the set of debug registers.

Furthermore, in response to capturing the event data, snapshot management component113can further set an indication (e.g., a flag, a bit, etc.) that the set of debug registers contain event data. In an embodiment, the indication can be set in a table (e.g., a metadata table) maintained by snapshot management component113and/or local media controller135. Responsive to detecting the indication that the set of debug registers contains event data, the snapshot management component113can extract the event data from the set of debug registers and generate a data structure (e.g., a log file). The data structure can be formatted using any desired format (e.g., an executable and linkable format (ELF), and stored on the memory device130and/or140.

In some embodiments, the snapshot management component113can send the data structure to the host system120. In some embodiments, the snapshot management component113can append the data structure to the memory access command. For example, in response to receiving a read command, the snapshot management component113can capture the event data relating to the read command, using the set of debug registers, and then append the data structure containing the event data to read data sent to the host system120. In some embodiments, the snapshot management component113can send the data structure to the host system120independent of the memory access command using, for example, an interface (e.g., Non-Volatile Memory Express (NVMe), SMBus, etc.).

In some embodiments, each debug register of the memory sub-system110can be configurable by the host system120. In particular, the host system120can configure which type of data for which type of event is captured by each debug register. For example, the host system120can configure that a first debug register records timer data relating to retrieving the memory access command from a memory access command queue, that a second debug register records timestamp data to error handling operations performed on the memory access command, and so forth.

In an exemplary example, memory device130and/or140can include two sets debug registries. Both sets of debut registers can initially be set to read-only mode. In response to detecting that a memory access command satisfies the trigger condition, the snapshot management component113can enable write operations on the first of the two sets of debug registers. In response to capturing the event data, the snapshot management component113can disable write operations on the first set of debug registers. In response to receiving subsequent memory access command that satisfying the trigger condition, the memory sub-system controller can enable write operations on another set of debug registers (e.g., another set of four debug registers). Thus, each debug register of the second set can be used to capture event data generated by the subsequent memory access command. By switching to the second set of debug registers, the memory sub-system controller can capture event data relating to the subsequent memory access command while extracting captured data from the first set of debug registers. It should be understood that any number of debug register sets can be used by in accordance with aspects of the present disclosure (e.g., one set, two sets, three sets, and so forth). The snapshot management component113can cycle between debug register sets for each memory access command that satisfies a trigger condition.

At operation210, the processing logic can receive a memory access command. For example, the processing logic can receive a write command, a read command, an erase command, a deallocate command, etc.

At operation220, responsive to detecting that the memory access command satisfies a trigger condition, the processing logic can record data (e.g., event data) associated with events performed by processing the memory access command. The processing logic can record the data in a first set of debug registers. The trigger condition can be related to logical address information of the memory access command, the memory access command type, a periodic command, a firmware based trigger, or a hardware based trigger. The event data can include time data, metric data, error handling data, queueing data, etc. In some embodiments, responsive to detecting that the memory access command satisfies the trigger condition, the processing logic can enable write operations on the first set of debug registers.

In some embodiments, the processing logic can set an indication that the first set of debug registers include the event data. Responsive to detecting the set indication, the processing logic can extract the event data from the first set of debug registers. The processing logic can then generating a log containing the event data from the first set of debug registers. In some embodiments, the processing logic can append the event data from the first set of debug registers to data (e.g., read data) retrieved by the memory access command. In some embodiments, responsive to detecting that the first set of debug registers contains the event data, the processing logic can disable write operations on the first set of debug registers.

At operation230, the processing logic can receive a next memory access command.

At operation240, responsive to detecting that the next memory access command satisfies the trigger condition, the processing logic can record, in a second set of debug registers, new event data relating to the events performed by processing the next memory access command. In some embodiments, responsive to detecting that the next memory access command satisfies the trigger condition, the processing logic can enable write operations on the second set of debug registers. In some embodiments, the processing logic can set an indication that the second set of debug registers include the new event data. Responsive to detecting the set indication, the processing logic can extract the new event data from the second set of debug registers. The processing logic can then generating a log containing the new event data from the second set of debug registers. In some embodiments, the processing logic can append the event data from the second set of debug registers to data retrieved by the next memory access command. In some embodiments, responsive to detecting that the second set of debug registers contains the new event data, the processing logic can disable write operations on the second set of debug registers.

FIG.3is a flow diagram of another example method300illustrating processes performed for snapshot process operations in the memory device, in accordance with some embodiments of the present disclosure. The method300can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method300is performed by the snapshot management component113ofFIG.1. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible.

At operation310, the processing logic can receive a memory access command. For example, the processing logic can receive a write command, a read command, an erase command, a deallocate command, etc.

At operation320, responsive to detecting that the memory access command satisfies a trigger condition, the processing logic can enable write operations on a set of debug registers. The trigger condition can be related to logical address information of the memory access command, the memory access command type, a periodic command, a firmware based trigger, or a hardware based trigger.

At operation330, the processing logic can record, in the set of debug registers, data (event data) relating to with events performed by processing the memory access command. The event data can include time data, metric data, error handling data, queueing data, etc.

At operation340, responsive to detecting that the set of debug registers include the event data, the processing logic can disable write operations in the set of debug registers.

In some embodiments, the processing logic can set an indication that the set of debug registers include the event data. Responsive to detecting the set indication, the processing logic can extract the event data from the set of debug registers. The processing logic can then generating a data structure containing the event data from the set of debug registers. In some embodiments, the processing logic can append the event data from the set of debug registers to data (e.g., read data) retrieved by the memory access command.

FIG.4schematically illustrates example sets of debug registers maintained by memory sub-system400, in accordance with some embodiments of the present disclosure. Memory sub-system400can be similar to memory sub-system110.

Memory sub-system400includes snapshot management component113and two sets of debug registers. The first set of debug registers include debug register1-A420, debug register2-A424, and debug register N-A428. The second set of debug registers include debug register1-B422, debug register2-B426, and debug register N-B430. A debug register from each set can be can assigned to record data from a preconfigured event. For example, debug registers1-A420and1-B422can be assigned to record data from event1(440), debug registers2-A424and2-B426can be assigned to record data from event2(442), and debug registers N-A428and N-B430can be assigned to record data from event3(444).

Responsive to detecting that a memory access command satisfies a trigger condition, the snapshot management component113can enable write operations on the first set of debug registers and record event data associated with events performed by processing the memory access command. Data relating to event1(440) can be recorded by debug register1-A420, data relating to event2(442) can be recorded by debug register2-A424, and data relating to event3(444) can be recorded by debug register N-A428. In some embodiments, snapshot management component113can set an indication that the first set of debug registers include the event data, and extract the event data from the first set of debug registers. The snapshot management component113can then generating data structure450containing the event data from the first set of debug registers. Responsive to detecting that the first set of debug registers contains the event data, snapshot management component113can disable write operations on the first set of debug registers.

Responsive to detecting that a next memory access command satisfies the trigger condition, the snapshot management component113can enable write operations on the second set of debug registers and record, in the second set of debug registers, new event data relating to the events performed by processing the next memory access command. For example, data relating to event1(440) can be recorded by debug register1-B424, data relating to event2(442) can be recorded by debug register2-B426, and data relating to event3(444) can be recorded by debug register N-B430. In some embodiments, snapshot management component113can set an indication that the second set of debug registers includes the event data, and extract the new event data from the second set of debug registers. The snapshot management component113can then generate another data structure450containing the event data from the second set of debug registers. Responsive to detecting that the second set of debug registers contains the event data, the snapshot management component113can disable write operations on the second set of debug registers. Responsive to another memory access command that satisfies the trigger condition, the snapshot management component113can enable write operations on the first set of debug registers and alternate between the first set of debug registers and the second set of debug registers.

The example computer system500includes a processing device502, a main memory504(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory506(e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system518, which communicate with each other via a bus530. Processing device502represents one or more general-purpose processing devices such as a microprocessor, a central processing unit, or the like. More particularly, the processing device can be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets, or processors implementing a combination of instruction sets. Processing device502can also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device502is configured to execute instructions526for performing the operations and steps discussed herein. The computer system500can further include a network interface device508to communicate over the network520.