Memory sub-system event log management

A system includes a memory device and a processing device coupled to the memory device. The memory processing device can perform operations including receiving data indicative of occurrence of a plurality of events. The processing device can perform operations including determining an event log type for each of the plurality of events. The processing device can perform operations including storing an identifier associated with each of the determined event log types. The processing device can perform operations including updating a counter value associated with each identifier in response to occurrence of an event associated with the respective identifier.

TECHNICAL FIELD

Embodiments of the disclosure relate generally to memory sub-systems, and more specifically, relate to memory sub-system event log management.

BACKGROUND

DETAILED DESCRIPTION

Aspects of the present disclosure are directed to memory sub-system event log management, in particular to memory sub-systems that include an event log component. A memory sub-system can be a storage system, storage device, a memory module, or a combination of such. An example of a memory sub-system is a storage system is a solid-state drive (SSD). Examples of storage devices and memory modules are described below in conjunction withFIG. 1, et alibi. In general, a host system can utilize a memory sub-system that includes one or more components, such as memory devices that store data. The host system can provide data to be stored at the memory sub-system and can request data to be retrieved from the memory sub-system.

An SSD is a type of memory sub-system that uses integrated circuit assemblies to store data persistently, typically using flash memory. An SSD can include memory devices that include one or more arrays of memory cells. The performance and/or endurance of an SSD can be related to the type(s) of memory cells employed by the SSD. In general, as the quantity of bits stored per cell increases, the endurance of the SSD (e.g., the amount of program-erase (PE) cycles, which can correspond to the quantity of reads or writes that can be performed on any given cell before the cells become unreliable) tends to decrease. This decrease can lead to errors and can cause events that are performed by the SSD to fail or not occur correctly.

Monitoring and detecting occurrences of particular SSD events, particularly in response to when a request to perform the events has occurred, can be beneficial. Event logs can be generated that indicate a listing of the events that the SSD has performed. An event log is a detailed record of system, security, and application notifications stored and used to diagnose system problems and predict possible system issues. However, parsing an entire event log can take considerable resources when testing thousands of SSDs. In the case of larger drives, it may not be possible to parse all of the drives and some event log entries may be missing.

Aspects of the present disclosure address the above and other deficiencies by generating histogram data and an event log histogram to display in order to provide considerably more data than may be currently available. By generating an event log histogram, event logs can be more quickly and efficiently analyzed with more limited impact on quality of service (QoS) and can provide for additional resources to monitor the event logs. In addition, event log histograms can provide monitoring of a frequency of non-critical events that may occur to ensure that what is being requested to be performed by the SSD is actually occurring. Such analysis may be missed or have too large an impact on QoS if only a subset of the event logs were summarized or only a portion of the event logs were able to be analyzed during a particular period of time. An advantage of the present disclosure includes dynamically monitoring the event logs and adjusting characteristics of how the events are being performed in response to the monitoring. Embodiments described herein include an event log component resident on the memory sub-system (e.g., on the memory sub-system controller), to make it possible to perform monitoring and organizing of the event logs.

A memory device can be a non-volatile memory device. One example of non-volatile memory devices is a negative-and (NAND) memory device (also known as flash technology). Other examples of non-volatile memory devices are described below in conjunction withFIG. 1. A non-volatile memory device is a package of one or more dice. Each die can consist of one or more planes. Planes can be groups into logic units (LUN). For some types of non-volatile memory devices (e.g., NAND devices), each plane consists of a set of physical blocks. Each block consists of a set of pages. Each page consists of a set of memory cells (“cells”). A cell is an electronic circuit that stores information. A block hereinafter refers to a unit of the memory device used to store data and can include a group of memory cells, a word line group, a word line, or individual memory cells. For some memory devices, blocks (also hereinafter referred to as “memory blocks”) are the smallest area than can be erased. Pages cannot be erased individually, and only whole blocks can be erased.

Each of the memory devices can include one or more arrays of memory cells. Depending on the cell type, a cell can store one or more bits of binary information, and has various logic states that correlate to the number of bits being stored. The logic states can be represented by binary values, such as “0” and “1”, or combinations of such values. There are various types of cells, such as single level cells (SLCs), multi-level cells (MLCs), triple level cells (TLCs), and quad-level cells (QLCs). For example, a SLC can store one bit of information and has two logic states.

Data operations can be performed by the memory sub-system. The data operations can be host-initiated operations. For example, the host system can initiate a data operation (e.g., write, read, erase, etc.) on a memory sub-system. The host system can send access requests (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.

The memory sub-system controller115includes an event log component113that can be configured to orchestrate and/or perform operations to manage events that are logged in association with data processing related to various components, data components, and/or interfaces of the memory sub-system110. As an example, the event log component113can monitor events including event frequency, event initiation, event completion, whether an event has been requested, etc. The memory sub-system controller115includes a counter114that is in communication with the event log component113and can be used to monitor and record a frequency of each of the events that occur. In some embodiments, the counter114can be storage in SRAM or DRAM that maintains a count of a particular event log occurrence.

The events can be logged as histogram data and/or structured into a histogram chart or graph in order to organize the event logs for analysis and processing. Event logs can be used to record important hardware and software actions that can be used to troubleshoot issues with the operating system. The event logs can track specific events in its log files, such as application installations, security management, system setup operations on initial startup, and problems or errors within the system. An event log can include a date, time, user information, computer information, an event identification (ID), a source (indicating a program or component that caused the event), a type of event (including information, warning, error, security success audit, or security failure audit), etc.

Events can be categorized into different types including application, security, setup, system, and forwarded events, among others. Application events can refer to incidents with installed software on a local computer. A security event can refer to events based on audit policies such as login attempts and resource access. Setup events can refer to events that include enterprise-focused events relating to the control of domains, such as the location of logs after a disk configuration. System events can refer to incidents that are system specific, such as the status of device drivers. Forwarded events can refer to events that are received from external devices on a same network in a situation where a system gathers multiple logs that are not all associated with system itself.

Although not shown inFIG. 1so as to not obfuscate the drawings, the event log component113can include various circuitry to facilitate grading and allocation of the sets of memory cells. For example, the event log component113can include a special purpose circuitry in the form of an ASIC, FPGA, state machine, and/or other logic circuitry that can allow the event log component113to orchestrate and/or perform operations to manage the occurrence of events associated with various components, data elements, and/or interfaces of the memory sub-system110and transfer the event log information and/or the event log histogram to other various components of the memory sub-system110. The event log component113can sense and/or monitor the occurrence of multiple events over a period of time or at different time intervals and feed back the event log data into the event log histogram and other event log data structures.

As described below, the event log component113can be communicatively coupled to the memory devices130and can access the memory device130, the memory device140, internal data paths of the memory sub-system110, and/or interfaces of the memory sub-system110to perform the operations described herein and/or to monitor events associated with such elements. In some embodiments, the operations performed by the event log component113can be performed during an initialization or pre-initialization stage of data transfer within the memory sub-system110and/or the memory sub-system controller115. Accordingly, in some embodiments, the event log component113can perform the operations described herein prior to data transfer in order to determine a size of data to transfer (e.g., an amount of events that may occur) or a data transfer speed (e.g., a frequency of events) to initially monitor. During the initial data transfer, additional event log entries can be obtained and the size of the data transferred or the data transfer speed can be adjusted in order to adjust the event log data.

FIG. 2illustrates an example of a memory sub-system event log counter table250in accordance with some embodiments of the present disclosure. The event log counter table250can include a plurality of entries251-1to251-12(hereinafter referred to collectively as plurality of entries251) and can be used to generate an event log histogram. The event log counter table250can be stored in non-volatile memory, such as memory device130inFIG. 1, which can include NAND, 3D cross-point, NOR, etc. Each of the plurality of entries251can include an event identification (“Event ID”)234, a count value (“Count”)233, a group number (“Group”)235, and a description237. For example, a first entry251-1has an event ID234of “0x108,” a count value of “1,” a group number of “0,” and a description of “An 11format command has been issued.” In this example, the event ID234is an hexadecimal code that indicates an identification for that particular event in the entry. The count value233indicates the quantity of times, or frequency, that the event has occurred. The count value233can be determined and/or adjusted by a counter (e.g., counter114inFIG. 1) that monitors a frequency of an event. The group number235indicates the type of group that the event is within. The description237indicates which event has occurred in more detail.

Each event log type can be defined as a unique event log entry. As one example, the event log type can be a media error. A unique event log entry type can be defined as a 16-bit identifier (as was described as the hexadecimal code above and illustrated inFIG. 2). As one example, a log entry, such as entries251, would be generated for storing a number of event log types as an 8-, 16-, or 32-bit unsigned value, however examples are not limited to these bit sizes and can include additional bit sizes. In some embodiments, firmware could determine a counter length based on a frequency and amount of time that the event would be displayed in the field. The types of events that can be logged and counted include media-related events and error-related events (e.g., DRAM ECC, etc.). In addition, counters of particular events can be given priority such that certain counts of events can be more critical to a response than others. As an example, a count of a first set of events occurring can be prioritized with a particular response over a count of a second set of events occurring. In this example, if a certain count of the first set occurs and the same count of the second set occurs, if a response is required to both, the response to the first set of events may be prioritized over the response to the second set of events.

Each time a particular event occurs again, and therefore would have been entered into a general event log, a count value233of an event is updated (e.g., incremented by a quantity of one). For example, in response to an additional occurrence of an event with an event ID234of “0x108” (as in the first entry251-1), the count value233associated with event ID234of “0x108” would be incremented from “1” (as is currently illustrated inFIG. 2) to “2.” In this way, an additional entry is not entered into the log but rather the count is incremented, thereby saving storage space and providing more efficient access to the event log data. As an example, a seventh entry251-7has a count233of “12” which would occupy twelve entry locations in a general event log. That is, the event indicated by the seventh entry251-7has occurred 12 times and that quantity is represented by the count233of “12.” By using that general event log information and organizing it in such a way, as is illustrated inFIG. 2, a larger amount of data can be organized and processed with a more limited storage footprint. The table generated from the histogram data can be used to generate a histogram chart or graph. The histogram graph can be more efficiently analyzed and/or processed in order to evaluate a larger volume of data in a more efficient and faster amount of time based on the organization and ease of access of the data. In addition, an event log pareto can be accessed in order to generate the histogram data.

In some embodiments, a per hour time period event log can be generated in which the events that have occurred within a particular hour-long time period are logged and indicated for that time period. The time period data can be logged based on the counts accrued during that time period and flushed every hour to the main event log histogram. In some embodiments, firmware can be customized and a data decoder for each firmware can be built in order to decode that data associated with that firmware. In addition, software and/or a script may be generated to decode the data into relevant fields into structured data that could be illustrated to a user. As used herein, a “user” can refer to a human user (e.g., a person) or machine (e.g., a sub-system, process, host system, etc.) that provides instructions to the memory sub-system to cause the memory sub-system to perform a task or action.

Flushing of the data can include storing the event log data into non-volatile memory and also into the event log count data. Flushing of the events can occur on a periodic basis. For example, event log data can be flushed with each event log entry added to the event log and/or at every power down of the system. This event log flushing frequency for the event log count table can be based on a clean power cycle. Further, the counters can be reloaded on a reboot. In one example, the counters can be permanent for the life of the system from shipment. In one example, the counters can be saturated at a max value threshold. In one example, the count values could be flushed on a per hour time basis along with the event log data. As the frequency of the flush increases, the likelihood that event log data is lost is decreased.

In some embodiments, the event log histogram and corresponding counter (such as counter114inFIG. 1) would be limited in size from 4 k to 8 k of data and maintain the amount of data transferred in a log read to as small an amount of possible. As an example, for 1,700 events at 32 bits per event, there would be about 54,400 bits of data to store. However, each of the events may not use all 32 bits. In order to determine the best bit to event ratio, an architecture or firmware can be generated to estimate an estimated number of times an event would occur during a system's lifetime and a recommended amount of storage space for each associated counter. This can be an architecture design decision prior to operation or a number of operations can be performed to determine this estimate.

In some embodiments, an event log histogram generated from the event log count table250can be retrieved and analyzed to determine which critical and/or non-critical events have occurred, whether the events are occurring at a frequency and quantity that is expected, and whether adjustments to the system should be made based on a comparison of the expected and actual results.

FIG. 3is a flow diagram corresponding to a method360for performing memory sub-system operations to monitor events in accordance with some embodiments of the present disclosure. The method360can 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. The method360can be triggered by an occurrence of a plurality of events. The memory sub-system can perform the plurality of events and these events can include system, security, and application events related to important software and hardware actions. The events can be recorded in log files and include such scenarios as application installations, security management, system setup operations on initial setup, and problems and/or errors.

At operation362, the method360can include receiving, from a memory device, data indicative of occurrence of the plurality of events. The memory device can be analogous to the memory device130and/or the memory device140ofFIG. 1. The received data can include an indication that a particular event has occurred and/or whether the particular event occurred when expected. The received data can include a portion of an event log or multiple event logs each corresponding to different portions of the system or different time periods that the system has been performing. The data can be received in response to a flushing of the data at a particular time interval, in response to a particular event occurring, etc.

At operation363, the method360can include determining an event log type for each of the plurality of events. In some example, the event log type may have already occurred at least once. The determination can include an indication that the event log type has already occurred. At operation364, the method360can include storing an identifier associated with each of the determined event log types in an event log within the memory device. The identifier can be an 8-bit, a 16-bit, or a 32-bit identifier and can include hexadecimal notation (as was described and illustrated inFIG. 2). The identifier can be associated with a count value, a group number, a description, and so forth, within the event log count table, as is illustrated inFIG. 2.

At operation365, the method360can include updating a counter associated with each identifier in the event log in response to performance of an event associated with the respective identifier. As an example, in response to a determination that the event log type has not occurred before, the count value of the counter can be incremented from a “0” to a “1.” In response to a determination that the event log type has occurred previously, the previous count value (“2” for the sake of this example) can be incremented by one (which would result in a “3”, in this example).

In some embodiments, the memory device can be a volatile memory device and the memory device different than the memory device can be a non-volatile memory device (or vice versa). For example, the memory device can be a system memory device, such as a DRAM (e.g., a dual-ported RAM) memory device, and the memory device different than the memory device can be a storage device, such as a NAND memory device, a three-dimensional cross-point memory device, or other non-volatile memory device.

The method360can further include generating a histogram of a plurality of identifiers. The histogram can be generated using the data from the event log count table including the plurality of identifiers. The histogram can be generated including a corresponding plurality of counters indicating a quantity of times each event log type associated with each of the respective plurality of identifiers has occurred. Generating the histogram can include generating a histogram that indicates the quantity of times each event log type has occurred per period of time. The method360can further include determining that the event log type includes an error event. The method360can further include determining that the event log type include a non-critical event. The method360can further include storing the counters in a location of memory separate from a location of the identifiers. In one example, the counters can be stored in a header of an existing event log. As an example, The method360can further include determining a priority of the counters and corresponding event log types.

The processing device402represents 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. The processing device402can 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 device402is configured to execute instructions426for performing the operations and steps discussed herein. The computer system400can further include a network interface device408to communicate over the network420. In some embodiments, the main memory404or system418can be an SSD such as is described in association withFIGS. 1-2.

The data storage system418can include a machine-readable storage medium424(also known as a computer-readable medium) on which is stored one or more sets of instructions426or software embodying any one or more of the methodologies or functions described herein. The instructions426can also reside, completely or at least partially, within the main memory404and/or within the processing device402during execution thereof by the computer system400, the main memory404and the processing device402also constituting machine-readable storage media. The machine-readable storage medium424, data storage system418, and/or main memory404can correspond to the memory sub-system110ofFIG. 1.