Command snapshot generation in memory devices

Abstract

This application relates to command snapshot generation in memory devices. Systems and methods are disclosed that include a processing device operatively coupled to a memory device. The processing device performs operations including 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 referenced by the physical address; determining a durability factor associated with the portion; and increasing a media management metric associated with a management unit of the memory device by a value derived from the durability factor, where the management unit is referenced by the physical address.

Description

TECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to memory sub-systems, and more specifically, to command snapshot generation in a memory device. BACKGROUND

[0002] A memory sub-system can include one or more memory devices that store data. The memory devices can be, for example, non-volatile memory devices and volatile memory devices. Generally, a host system can utilize a memory sub-system to store data at the memory devices and retrieve data from the memory devices. SUMMARY

[0003] According to an aspect of the present application, a system is provided. The system comprises a memory device; and a processing device, operatively coupled with the memory device, to perform operations comprising: receiving a first memory access command; in response to detecting that the first memory access command satisfies a trigger condition, recording first data associated with a plurality of events performed by processing the first memory access command in a first set of registers; receiving a second memory access command; and in response to detecting that the second memory access command satisfies the trigger condition, recording second data associated with a plurality of events performed by processing the second memory access command in a second set of registers.

[0004] According to another aspect of the present application, a method is provided. The method comprises: receiving, by a processing device, a memory access command; in response to detecting that the memory access command satisfies a trigger condition, enabling a write operation in a set of registers; recording data associated with a plurality of events performed by processing the memory access command in the set of registers; and in response to detecting that the set of registers comprises the data, disabling the write operation in the set of registers.

[0005] According to yet another aspect of the present application, a non-transitory computer- readable storage medium is provided. The non-transitory computer-readable storage medium comprises instructions that, when executed by a processing device operatively coupled to a memory device, perform operations comprising: receiving a first memory access command; in response to detecting that the first memory access command satisfies a trigger condition, recording first data associated with a plurality of events performed by processing the first memory access command in a first set of registers; receiving a second memory access command; and in response to detecting that the second memory access command satisfies the trigger condition, recording second data associated with a plurality of events performed by processing the second memory access command in a second set of registers. BRIEF DESCRIPTION OF DRAWINGS

[0006] The disclosure will become more fully understood from the detailed description and the accompanying drawings provided below.

[0007] Figure 1 An example computing system including a memory sub-system according to some embodiments of the disclosure is illustrated.

[0008] Figure 2 is a flow diagram illustrating an example method of a process performed for snapshot process operations in a memory device according to some embodiments of the disclosure.

[0009] Figure 3 is a flow diagram illustrating another example method of a process performed for snapshot process operations in a memory device according to some embodiments of the disclosure.

[0010] Figure 4 An example set of debug registers maintained by a memory sub-system according to some embodiments of the disclosure is schematically illustrated.

[0011] Figure 5 is a block diagram of an example computer system in which embodiments of the disclosure can operate. DETAILED DESCRIPTION

[0012] Aspects of the disclosure are directed to command snapshot generation in a memory device. A memory sub-system can be a storage device, a memory module, or a combination of a storage device and a memory module. Examples of storage devices and memory modules are described below in connection with Figure 1 An example computing system including a memory sub-system according to some embodiments of the disclosure is illustrated.

[0013] Memory access operations can be performed by a memory sub-system. Memory access operations can be host initiated or memory sub-system controller initiated. For example, a host system can initiate memory access operations (e.g., write operations, read operations, erase operations, etc.) on a memory sub-system. The host system can send memory access commands (e.g., write commands, read commands) to the memory sub-system to, for example, store data at memory devices at the memory sub-system and read data from memory devices on the memory sub-system. 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 a location associated with the host data by the host system. 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 codewords, parity check codes), data version (e.g., to distinguish age of written data), valid bitmap (whose LBA or logical transfer unit contains valid data), etc. Memory sub-system controller initiated memory access operations can involve maintenance operations, such as garbage collection, wear leveling, bad block management, block flush operations, etc.

[0014] In processing memory access commands, a memory sub-system can experience quality of service issues, such latency caused by defects (i.e., “bugs”) in electronic devices of the memory sub-system. Debugging can involve finding defects 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 complete updates to the system. Debugging targets include identifying and fixing defects in the system (e.g., logic or synchronization problems in firmware, or design errors in hardware), and gathering 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 improve its performance or optimize other important characteristics.

[0015] One example of system state information can include event data generated in the memory sub-system. As used herein, an event generally refers to a detectable state change caused by an action performed by hardware, software, and / or firmware in the memory sub-system. Examples of events include the memory sub-system controller sending and / or receiving data or accessing memory locations of a memory device, a warning related to some reliability statistics of the memory device (e.g., raw bit error rate (RBER), wear leveling, etc.), an error experienced by the memory sub-system controller when reading data from or writing data to the memory device, garbage collection, encoding and / or decoding, retrieving memory access commands from a queue (e.g., a dispatch queue, a commit queue, etc.), data reconstruction, direct memory access (DMA) operations, media scan, or any other event related to memory access operations. Data related to an event can include time data (e.g., a timestamp when the execution of the event started, a timestamp when the execution of the event ended, timer data related to the duration of the execution of the event, etc.), metrics data (e.g., data related to metrics used by the memory sub-system), error handling data (e.g., the type of error handling operation performed), queued data, etc.

[0016] Time point debug information can be important for analyzing events that are being reported from customer usage and / or during qualification of a memory sub-system (e.g., an SSD). Debug information can include a state snapshot of the memory sub-system that is present during the time when a reported issue (e.g., an error or a failure) occurs. In particular, the snapshot can save the state of memory device registers, memory, and other critical data areas. Analyzing the debug information can help determine the root cause of the issue. To produce the snapshot, each CPU core saves its hardware registers and / or other important areas of memory.

[0017] 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 system 120 can analyze the log data (e.g., timestamp data) to determine whether and when a latency issue occurred.

[0018] However, sampling via multiple snapshots can create significant latency issues in a memory sub-system. For example, sampling can consume thousands of instruction cycles for capturing and extracting debug information. Additionally, sending log files containing data related to thousands of snapshots to the host system can consume additional instruction cycles, which additionally increases the latency experienced. In other memory sub-systems, sampling via multiple snapshots can require large, high-cost infrastructure. Thus, a system that is capable of capturing debug information without adversely affecting the performance of a memory sub-system is desirable.

[0019] Aspects of the present disclosure address the deficiencies set forth above, and other deficiencies, by enabling a memory sub-system to perform a command snapshot process. In particular, a 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 a memory access command specifying a particular logical address or a particular range of logical addresses, a memory access command type (e.g., a read command, a write command, an erase command, a deallocate command, etc.), a memory access command occurring at a predefined interval value (e.g., every thousand memory access commands, every ten thousand memory commands, 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 a write operation on a set of debug registers. The debug registers can be located on the memory sub-system controller and / or on a memory device. Each debug register can be used to capture event data resulting from the memory access command. In one embodiment, the memory sub-system can include a set of four debug registers. A first debug register can store time data related to retrieving the memory access command from a memory access command queue (e.g., a timestamp when the event execution started, a timestamp when the event execution ended, timer data related to a duration of executing the event, etc.). A second debug register can record time data related to accessing the memory device. A third debug register can record time data related to error handling and / or encoding and decoding operations performed on the memory access command. A fourth debug register can record time data related to completion of the memory access command. In response to capturing the event data, the memory sub-system controller can disable the write operation on the set of debug registers to prevent subsequent memory access commands from overwriting the captured event data before the memory sub-system controller extracts 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 contains event data.

[0020] In some embodiments, in response to detecting the indication that the set of debug registers contains 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 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 a memory access command. For example, in response to receiving a read command, the memory sub-system controller can capture event data related to the read command using the set of debug registers, and then append the log containing the event data to the read data sent to the host system.

[0021] In some embodiments, in response to the 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 in 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 related to the subsequent memory access command while extracting the captured data from the first set of debug registers. The memory sub-system controller can alternate between the sets of debug registers for the subsequent memory access command.

[0022] Advantages of the present disclosure include, but are not limited to, providing improvements for systems for capturing snapshots in response to specific software, hardware, or firmware triggers. These snapshots provide targeted point-in-time debug information that can be used to determine the root cause of problems that lead to quality-of-service issues (e.g., latency issues) or system failures. Additionally, these snapshots provide targeted point-in-time debug information related to queued data, error handling operations, etc. Aspects of the present disclosure provide for reduced latency in capturing debug state (registers, memory, and / or debug information) by enabling hardware and / or software to capture event data using a dedicated set of debug registers, thus improving the performance of memory devices.

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

[0024] The memory sub-system 110 can be a storage device, a memory module, or a mix of storage devices and memory modules. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded Multi-Media Controllers (eMMC) drives, 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 various types of non-volatile dual in-line memory modules (NVDIMMs).

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

[0026] The computing system 100 can include a host system 120 coupled to one or more memory sub-systems 110. In some embodiments, the host system 120 is coupled to different types of memory sub-systems 110. Figure 1 One example of a host system 120 coupled to one memory sub-system 110 is described. As used herein, “coupled to” or “coupled with” generally refers to a connection between components that is either an indirect communicative connection or a direct communicative connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc.

[0027] The host system 120 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 (e.g., NVDIMM controller), and a storage protocol controller (e.g., PCIe controller, SATA controller). The host system 120 uses the memory sub-system 110, for example, to write data to and read data from the memory sub-system 110.

[0028] The host system 120 can be coupled to the memory sub-system 110 via a physical host interface. Examples of a physical host interface include, but are not limited to, a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, a universal serial bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), a double data rate (DDR) memory bus, a small computer system interface (SCSI), a dual in-line memory module (DIMM) interface (e.g., a DIMM socket interface that supports double data rate (DDR)), etc. The physical host interface can be used to transmit data between the host system 120 and the memory sub-system 110. When the memory sub-system 110 is coupled with the host system 120 by a physical host interface (e.g., a PCIe bus), the host system 120 can further utilize an NVM Express (NVMe) interface to access the memory components (e.g., the memory devices 130). The physical host interface can provide an interface for communicating control, address, data, and other signals between the memory sub-system 110 and the host system 120. Figure 1 The memory sub-system 110 is illustrated as an example. In general, a host system 120 can access multiple memory sub-systems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0029] The memory devices 130, 140 can include any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., the memory devices 140) can be, but are not limited to, random access memories (RAMs) such as dynamic random access memories (DRAMs) and synchronous dynamic random access memories (SDRAMs).

[0030] Some examples of non-volatile memory devices (e.g., the memory devices 130) include “not- and” (NAND) type flash memory and in-place write memory such as a three-dimensional cross-point (“3D cross-point”) memory device, which is a cross-point array of non-volatile memory cells. A cross-point array of non-volatile memory can incorporate a stackable cross-gridded data access array to store bits based on changes in bulk resistance. Additionally, in contrast to many flash-based memories, cross-point non-volatile memory can perform in-place write operations, where a non-volatile memory cell can be programmed without first erasing the non-volatile memory cell. NAND type flash memory includes, for example, two-dimensional NAND (2D NAND) and three-dimensional NAND (3D NAND).

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

[0032] The memory devices 130 can include one or more tiers. A tier can be defined as an array of memory cells with conductive access lines. Multiple tiers can be stacked within the memory device 130. Each tier can have a different level of endurance by itself (e.g., an indication of about how many times the tier can be written to, read, and / or erased before physical wear causes the tier to fail).

[0033] While non-volatile memory components are described, such as 3D cross-point non-volatile memory cell arrays and NAND-type flash memory (e.g., 2D NAND, 3D NAND), the memory devices 130 can 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 memory, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer torque (STT)-MRAM, conductive-bridge RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), or non- (NOR) flash memory, electrically erasable programmable read-only memory (EEPROM).

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

[0035] The memory sub-system controller 115 can be a processing device that includes one or more processors (e.g., the processor 117) configured to execute instructions stored in local memory 119. In the illustrated example, the local memory 119 of the memory sub-system controller 115 includes embedded memory configured to store instructions for various processes, operations, logic flows, and routines that control operation of the memory sub-system 110, including handling communications between the memory sub-system 110 and the host system 120.

[0036] In the illustrated example, the local memory 119 of the memory sub-system controller 115 includes embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory sub-system 110, including handling communications between the memory sub-system 110 and the host system 120.

[0037] In some embodiments, the local memory 119 can include memory registers that store memory pointers, fetched data, etc. The local memory 119 can also include read-only memory (ROM) for storing microcode. While the example memory sub-system 110 in Figure 1 While the example memory sub-system 110 has been illustrated as including the memory sub-system controller 115, in another embodiment of the present disclosure, the memory sub-system 110 does not include the memory sub-system controller 115, but instead can rely on external control (e.g., provided by an external host or by a processor or controller separate from the memory sub-system).

[0038] In general, memory sub-system controller 115 can receive commands or operations from host system 120 and can convert the commands or operations into instructions or appropriate commands to achieve the desired access to memory devices 130. Memory sub-system controller 115 can be responsible for other operations such as media management operations, garbage collection operations, error detection and error-correcting code (ECC) operations, encryption operations, caching operations, and address translations between logical addresses (e.g., logical block addresses (LBAs), name space) and physical addresses (e.g., physical management unit addresses, physical block addresses) associated with memory devices 130. Memory sub-system controller 115 can additionally include host interface circuitry to communicate with host system 120 via the physical host interface. The host interface circuitry can convert commands received from the host system into command instructions to access memory devices 130, as well as convert responses associated with memory devices 130 into information for host system 120.

[0039] Memory sub-system 110 can also include additional circuitry or components not illustrated. In some embodiments, memory sub-system 110 can include a cache or buffer (e.g., DRAM) and address circuitry (e.g., row and column decoders) that can receive addresses from memory sub-system controller 115 and decode the addresses to access memory devices 130.

[0040] In some embodiments, memory devices 130 include a local media controller 135 that operates in conjunction with memory sub-system controller 115 to perform operations on one or more memory units of memory devices 130. An external controller (e.g., memory system controller 115) can externally manage memory devices 130 (e.g., perform media management operations on memory devices 130). In some embodiments, memory sub-system 110 is a managed memory sub-system that includes raw memory devices 130 with control logic (e.g., local controller 132) on a die and a controller (e.g., memory sub-system controller 115) that performs media management within the same memory device package. An example of a managed memory device is a managed NAND (MNAND) device.

[0041] Memory sub-system 110 includes a snapshot management component 113 that can be used to perform a snapshot process (e.g., capture event data) for each memory access command that satisfies a trigger condition. In some embodiments, memory sub-system controller 115 includes at least a portion of snapshot management component 113. In some embodiments, snapshot management component 113 is part of host system 110, an application, or an operating system. In other embodiments, local media controller 135 includes at least a portion of snapshot management component 113 and is configured to perform the functionality described herein.

[0042] The snapshot management component 113 can configure a trigger condition. The trigger condition can relate 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 particular logical address (e.g., LBA 23), a particular range of logical addresses (e.g., LBAs 24-30), a plurality of particular logical addresses, a plurality of particular ranges of logical addresses, or any combination thereof. To satisfy this trigger condition, a memory access command can specify a logical address indicated by the 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, and the like. To satisfy this trigger condition, a memory access command can have a type indicated by the trigger condition.

[0043] In some embodiments, the trigger condition can include a periodic command. The periodic command can relate to a memory access command occurring at a predefined interval value. For example, the periodic command can be set to a predetermined value (e.g., every thousand memory access commands, a time interval of 10 milliseconds for every memory access command, and the like). The snapshot management component 113 can maintain a memory access command counter, where each memory access command received by the memory sub-system controller 115 is counted. The trigger condition can be satisfied in response to the memory access command counter satisfying a threshold criterion (e.g., the predefined interval value).

[0044] 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-system 110. For example, the firmware-based trigger can include a condition to perform a snapshot process for a subsequent memory access command in response to an event or process occurring while processing a previous 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., a peripheral component interconnect (PCI) device) coupled to a sideband management interface (e.g., a system management bus (SMBus)). For example, the external device can receive statistics data, temperature data, or any other data related to the memory sub-system 110. In response to satisfying an external device-based criterion (e.g., a temperature value exceeding a threshold value), the external device can instruct the snapshot management component 113 to perform a snapshot function.

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

[0046] In response to the memory access command satisfying the trigger condition, the snapshot management component 113 can enable a write operation on a set of debug registers. The debug registers can be located on the snapshot management component 113, the memory device 130, and / or the memory device 140. Each debug register can be configured to capture and store data related to an event, a detectable state change caused by an action performed by hardware, software, firmware, or a combination thereof. Thus, the snapshot management component 113 can use each debug register to capture data related to different events performed by executing the memory access command. An event can generally refer to a detectable state change caused by an action performed by hardware, software, firmware, or a combination thereof in a 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 statistics of a memory device (e.g., raw bit error rate (RBER), wear leveling, etc.), an error experienced by a memory sub-system controller when reading data from or writing data to a memory device, garbage collection, encoding and / or decoding, retrieving a memory access command from a queue (e.g., a dispatch queue, a commit queue, etc.), data reconstruction, a direct memory access (DMA) operation, a media scan, or any other event related to a memory access operation.

[0047] In some embodiments, the data captured by the debug registers can include time data related to the corresponding event. For example, the time data can include a timestamp when the execution of the event begins, a timestamp when the execution of the event ends, timer data related to a 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 related to metrics used by the memory sub-system), error handling data (e.g., a type of error handling operation performed), queued data, etc.

[0048] In response to capturing the event data, the snapshot management component 113 can disable write operations on the set of debug registers. In some embodiments, the snapshot management component 113 can disable write operations on the set of debug registers in response to determining that a last debug register in the set of debug registers captured data, in response to detecting an indicator, and so forth. By disabling write operations, the snapshot management component can prevent subsequent memory access commands from overwriting the captured event data before the snapshot management component 113 extracts the captured event data from the set of debug registers.

[0049] In addition, in response to capturing the event data, the snapshot management component 113 can further set an indication (e.g., a flag, a bit, and so forth) that the set of debug registers contains event data. In embodiments, the indication can be set in a table (e.g., a metadata table) maintained by the snapshot management component 113 and / or the local media controller 135. In response to detecting the indication that the set of debug registers contains event data, the snapshot management component 113 can 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 Linkable Format (ELF)) and stored on the memory devices 130 and / or 140.

[0050] In some embodiments, the snapshot management component 113 can send the data structure to the host system 120. In some embodiments, the snapshot management component 113 can append the data structure to a memory access command. For example, in response to receiving a read command, the snapshot management component 113 can capture event data related 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 system 120. In some embodiments, the snapshot management component 113 can use, for example, an interface (e.g., a Non-Volatile Memory Express (NVMe), an SMBus, and so forth) to send the data structure to the host system 120 independent of the memory access command.

[0051] In some embodiments, each debug register of the memory sub-system 110 can be configurable by the host system 120. In particular, the host system 120 can configure each debug register to capture data for which type of event. For example, the host system 120 can configure a first debug register to record timer data related to retrieving a memory access command from a memory access command queue, a second debug register to record timestamp data for error handling operations performed on a memory access command, and so forth.

[0052] In the example, the memory devices 130 and / or 140 can include two sets of debug registers. Initially, both sets of debug registers can be set to a read-only mode. In response to detecting that a memory access command satisfies a trigger condition, the snapshot management component 113 can enable write operations on a first set of the two sets of debug registers. In response to capturing event data, the snapshot management component 113 can disable write operations on the first set of debug registers. In response to receiving a subsequent memory access command that satisfies 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 in the second set can be used to capture event data resulting from the subsequent memory access command. By switching to the second set of debug registers, the memory sub-system controller can capture event data related to the subsequent memory access command while extracting the captured data from the first set of debug registers. It should be understood that any number of sets of debug registers (e.g., one set, two sets, three sets, etc.) can be used in accordance with aspects of the disclosure. The snapshot management component 113 can cycle between sets of debug registers for each memory access command that satisfies the trigger condition.

[0053] Figure 2 is a flow diagram illustrating an example method 200 of a process performed for snapshot processing operations in a memory device in accordance with some embodiments of the present disclosure. The method 200 can 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 method 200 is performed by the snapshot management component 113 of Figure 1 FIG. 1. Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, it is to be understood that the illustrated embodiments are merely examples, and that the illustrated processes can be performed in different orders, 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 also possible.

[0054] At operation 210, 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.

[0055] At operation 220, in response to detecting that the memory access command satisfies the trigger condition, the processing logic can record data (e.g., event data) associated with an event performed by processing the memory access command. The processing logic can record the data in the first set of debug registers. The trigger condition can relate to logical address information of the memory access command, a 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, queued data, etc. In some embodiments, in response 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.

[0056] In some embodiments, the processing logic can set an indication that the first set of debug registers includes event data. In response 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 generate 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 retrieved from the memory access command (e.g., read data). In some embodiments, in response to detecting that the first set of debug registers includes event data, the processing logic can disable write operations on the first set of debug registers.

[0057] At operation 230, the processing logic can receive a next memory access command.

[0058] At operation 240, in response to detecting that the next memory access command satisfies the trigger condition, the processing logic can record new event data related to an event performed by processing the next memory access command in the second set of debug registers. In some embodiments, in response 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 includes new event data. In response to detecting the set indication, the processing logic can extract the event data from the second set of debug registers. The processing logic can then generate 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 from the next memory access command. In some embodiments, in response to detecting that the second set of debug registers includes new event data, the processing logic can disable write operations on the second set of debug registers.

[0059] Figure 3is another example method 300 of a flow diagram illustrating a process for snapshot process operation execution in a memory device, in accordance with some embodiments of the present disclosure. The method 300 can 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 method 300 is performed by the snapshot management component 113 of Figure 1 Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, it is to be understood that the illustrated embodiments are merely examples, and that the illustrated processes can be performed in different orders, 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 also possible.

[0060] At operation 310, 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.

[0061] At operation 320, in response 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 relate to logical address information of the memory access command, a memory access command type, a periodic command, a firmware-based trigger, or a hardware-based trigger.

[0062] At operation 330, the processing logic can record data related to an event performed by processing the memory access command (event data) in the set of debug registers. The event data can include time data, metric data, error handling data, queued data, etc.

[0063] At operation 340, in response to detecting that the set of debug registers includes event data, the processing logic can disable write operations in the set of debug registers.

[0064] In some embodiments, the processing logic can set an indication of the set of debug registers including event data. In response to detecting the set indication, the processing logic can extract event data from the set of debug registers. The processing logic can then generate 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 retrieved from the memory access command (e.g., read data).

[0065] Figure 4 An example set of debug registers maintained by the memory sub-system 400, in accordance with some embodiments of the present disclosure, is schematically illustrated. The memory sub-system 400 can be similar to the memory sub-system 110.

[0066] Memory sub-system 400 includes snapshot management component 113 and two sets of debug registers. The first set of debug registers includes debug register 1-A 420, debug register 2-A 424, and debug register N-A 428. The second set of debug registers includes debug register 1-B 422, debug register 2-B 426, and debug register N-B 430. Debug registers from each set can be assigned to record data from preconfigured events. For example, debug registers 1-A 420 and 1-B 422 can be assigned to record data from event 1 (440), debug registers 2-A 424 and 2-B 426 can be assigned to record data from event 2 (442), and debug registers N-A 428 and N-B 430 can be assigned to record data from event 3 (444).

[0067] In response to detecting that the memory access command satisfies the trigger condition, snapshot management component 113 can enable write operations on the first set of debug registers and record event data associated with events performed by processing the memory access command. Debug register 1-A 420 can record data related to event 1 (440), debug register 2-A 424 can record data related to event 2 (442), and debug register N-A 428 can record data related to event 3 (444). In some embodiments, snapshot management component 113 can set an indication that the first set of debug registers includes event data, and extract event data from the first set of debug registers. Snapshot management component 113 can then generate data structure 450 containing event data from the first set of debug registers. In response to detecting that the first set of debug registers includes event data, snapshot management component 113 can disable write operations on the first set of debug registers.

[0068] In response to detecting that the next memory access command meets the trigger condition, the snapshot management component 113 may enable write operations on the second set of debug registers and record new event data related to the event executed by processing the next memory access command in the second set of debug registers. For example, debug register 1-B 424 may record data related to event 1 (440), debug register 2-B 426 may record data related to event 2 (442), and debug register N-B 430 may record data related to event 3 (444). In some embodiments, the snapshot management component 113 may set an indication that the second set of debug registers contains event data and extract new event data from the second set of debug registers. The snapshot management component 113 may then generate another data structure 450 containing event data from the second set of debug registers. In response to detecting that the second set of debug registers contains event data, the snapshot management component 113 may disable write operations on the second set of debug registers. In response to another memory access command that meets the triggering condition, the snapshot management component 113 may 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.

[0069] Figure 5 An example machine illustrating computer system 500 is described, capable of executing a set of instructions within said computer system 500 for causing said machine to perform any or more methods discussed herein. In some embodiments, computer system 500 may correspond to a host system (e.g., Figure 1 The host system 120 includes or utilizes a memory subsystem (e.g., Figure 1 The memory subsystem 110) or can be used to perform controller operations (e.g., run an operating system to perform corresponding...). Figure 1 (Operation of the snapshot management component 113). In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, intranet, extranet, and / or the Internet. The machine may operate as a peer machine in a peer-to-peer (or distributed) network environment or as a server or client machine in a cloud computing infrastructure or environment, operating at the capacity of a server or client machine in a client-server network environment.

[0070] The machine can be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single machine is illustrated, the term "machine" shall also be taken to 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.

[0071] The example computer system 500 includes a processing device 502, a main memory 504 (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 memory 506 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage system 518, which communicate with each other via a bus 530. The processing device 502 represents one or more general -purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device can be complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or processor implementing other instruction sets, or processors implementing a combination of instruction sets. The processing device 502 is configured to execute instructions 526 for performing the operations and steps discussed herein. The computer system 500 can further include a network interface device 508 to communicate over the network 520.

[0072] The data storage system 518 can include a machine-readable storage medium 524 (also known as a computer-readable medium) on which is stored one or more sets of instructions 526 or software embodying any one or more of the methodologies or functions described herein. The instructions 526 can also reside, completely or at least partially, within the main memory 504 and / or within the processing device 502 during execution thereof by the computer system 500, the main memory 504 and the processing device 502 also constituting machine-readable storage media. The machine-readable storage medium 524, data storage system 518, and / or main memory 504 can correspond to memory subsystem 110 of FIG. 1. Figure 1

[0073] In one embodiment, the instructions 526 include instructions to implement a Figure 1 ​instructions to implement functionalities of the snapshot management component 113. While the machine-readable storage medium 524 is shown in an example embodiment to be a single medium, the term "machine-readable storage medium" should be taken to include a single medium or multiple media that store one or more sets of instructions. The term "machine-readable storage medium" shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that causes the machine to perform any one or more of the methodologies of the present disclosure. The term "machine-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

[0074] Some portions of the preceding detailed descriptions 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. In this context, and for purposes of

[0075] It is also important to note that the machine-readable storage medium can include any medium that can be accessed by a computer. For example, this can include storage media such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired computer program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a machine-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, or twisted pair, then the coaxial cable, fiber optic cable, or twisted pair are included in the definition of medium. Likewise, if the software is transmitted using wireless technologies, e.g., radio waves, infrared, Bluetooth, or any other wireless medium, then the wireless medium is included in the definition of medium. The machine-readable medium can also include a combination of

[0076] The present disclosure also relates to an apparatus for performing the operations herein. This apparatus can be specially constructed for the required purposes, or it can include a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can 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 magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

[0077] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct a more specialized apparatus to perform the method. The structure for a variety of these systems will appear as described in the description below. In addition, the present disclosure is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the disclosure as described herein.

[0078] The present disclosure can be provided as a computer program product, or software, that can include a machine-readable medium having stored thereon instructions that can be used to program a computer (or other electronic devices) to perform a process according to the present disclosure. A machine-readable medium includes any mechanism for storing information in a form accessible by a machine (e.g., a computer). For example, a machine-readable (e.g., computer-readable) medium includes a machine (e.g., a computer) readable storage medium (e.g., read only memory ("ROM"), random access memory ("RAM"), magnetic disk storage media, optical storage media, flash memory devices, etc.), a machine (e.g., computer) readable transmission medium, etc.

[0079] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific example embodiments thereof. It will be evident that various modifications can be made to the disclosure without departing from the broader spirit and scope of embodiments of the present disclosure as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Claims

1. A system comprising: Memory devices; and A processing device operatively coupled to the memory device to perform operations including the following: Receive the first memory access command; In response to detecting that the first memory access command meets the triggering condition, first data associated with a plurality of events executed by processing the first memory access command is recorded in a first set of registers; In response to detecting that the first set of the registers includes the first data, write operations on the first set of the registers are disabled; Receive second memory access commands; and In response to detecting that the second memory access command satisfies the triggering condition, second data associated with a plurality of events executed by processing the second memory access command is recorded in a second set of registers.

2. The system of claim 1, wherein the processing device further performs operations including the following: The first data from the first set of the registers is appended to the data retrieved via the memory access command.

3. The system of claim 1, wherein the processing device further performs operations including the following: Generate a data structure that includes the first data from the first set of the registers.

4. The system according to claim 1, wherein the triggering condition includes at least one of logical address information, memory access command type, periodic command, firmware-based trigger, or hardware-based trigger.

5. The system of claim 1, wherein the processing device further performs operations including the following: In response to detecting that the first memory access command meets the triggering condition, write operations are enabled in the first set of registers.

6. The system of claim 1, wherein the processing device further performs operations including the following: Set an indication for the first set of the registers including the first data; and In response to the indication that the setting has been detected, the first data is retrieved from the first set of the registers.

7. The system of claim 1, wherein the first data includes at least one of time data, measurement data, error handling data, or queued data.

8. A method comprising: Receive memory access commands through the processing device; In response to detecting that the memory access command meets the trigger condition, a write operation is enabled in the register set; Data associated with multiple events executed by processing the memory access commands is recorded in the register set; and In response to the detection that the register set includes the data, write operations to the register set are disabled.

9. The method of claim 8, further comprising: The data from the register set is appended to the data retrieved via the memory access command.

10. The method of claim 8, further comprising: Generate a data structure that includes the data from the set of registers.

11. The method of claim 8, wherein the triggering condition includes at least one of logical address information, memory access command type, periodic command, firmware-based trigger, or hardware-based trigger.

12. The method of claim 8, further comprising: Set an indication for the data included in the register set; and In response to an indication that the setting has been detected, the data is retrieved from the register set.

13. The method of claim 8, wherein the data includes at least one of time data, measurement data, error handling data, or queued data.

14. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing means operatively coupled to a memory device, perform operations including: Receive the first memory access command; In response to detecting that the first memory access command meets the triggering condition, first data associated with a plurality of events executed by processing the first memory access command is recorded in a first set of registers; In response to detecting that the first set of the registers includes the first data, write operations on the first set of the registers are disabled; Receive second memory access commands; and In response to detecting that the second memory access command satisfies the triggering condition, second data associated with a plurality of events executed by processing the second memory access command is recorded in a second set of registers.

15. The non-transitory computer-readable storage medium of claim 14, wherein the processing means further performs operations including: The first data from the first set of the registers is appended to the data retrieved via the memory access command.

16. The non-transitory computer-readable storage medium of claim 14, wherein the processing means further performs operations including: Generate a data structure that includes the first data from the first set of the registers.

17. The non-transitory computer-readable storage medium of claim 14, wherein the processing means further performs operations including: In response to detecting that the first memory access command meets the triggering condition, write operations are enabled in the first set of registers.

18. The non-transitory computer-readable storage medium of claim 14, wherein the processing means further performs operations including: Set an indication for the first set of the registers including the first data; and In response to the indication that the setting has been detected, the first data is retrieved from the first set of the registers.

Images