Dynamic buffer cache of storage device

Abstract

Various embodiments described herein relate to systems and methods for dynamic buffer caching for storage devices, including receiving, by a controller of the storage device, information from a host indicating a frequency of accessing data stored in the storage device, and in response to receiving the information, determining, by the controller, an order in which to allocate read buffers of the storage device for a next read command. NAND read counts for virtual word lines WL are also used to cache more frequently accessed WLs, thereby proactively reducing read disturb and thus increasing NAND reliability and NAND lifetime.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to systems, methods, and non-transitory processor-readable media for implementing a buffer in a data storage device. BACKGROUND

[0002] In conventional read disturb algorithms for non-volatile memory (NVM) devices, a read disturb counter is maintained for each memory page. Any page that exceeds a read threshold (e.g., 64K reads) becomes a candidate page for periodic read disturb checks of data integrity in the page. These checks involve reading data, which not only puts the die and channel in a busy state (thus reducing random read performance), but also causes more read disturb effects. For example, any memory page in the NVM that exceeds a certain threshold for integrity checks becomes a candidate for read disturb flushes, and the entire superblock can be moved to a new block, causing write amplification. Excessive write amplification in read-intensive workloads eventually reduces the lifetime of the NVM. This approach does not take into account the use of memory buffers in read operations to reduce read disturb. SUMMARY

[0003] In some arrangements, a method includes receiving, by a controller of a storage device, information from a host indicating a frequency of accessing data stored in the storage device, and determining, by the controller, an order in which to allocate read buffers of the storage device for a next read command in response to receiving the information.

[0004] In some arrangements, a method includes at least partially determining an order in which read buffers of the storage device are arranged for allocation to a next read command using a total read counter of the read buffers calculated by the controller of the storage device.

[0005] In some arrangements, a method for calculating a total read count includes calculating a sum of a hit count of the read buffers, an actual read count of the memory pages in the NVM, and a high read count assigned by the controller of the storage device to frequently read data (as informed by the host) to determine an order in which to allocate read buffers of the storage device for a next read command.

[0006] In some arrangements, a non-transitory computer-readable medium comprising computer-readable instructions such that, when the instructions are executed, cause a processor to receive information from a host indicating a frequency of accessing data stored in the storage device, and determine, in response to receiving the information, an order in which to allocate read buffers of the storage device for a next read command. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1A block diagram illustrating an example storage device according to some arrangements.

[0008] Figure 2 A block diagram of an architecture to support low latency operations according to some embodiments.

[0009] Figure 3 A block diagram illustrating in-use lists and free lists according to some arrangements.

[0010] Figure 4 A table illustrating example access frequency values according to the NVMe protocol.

[0011] Figure 5 A block diagram illustrating a free list according to some arrangements.

[0012] Figure 6 A flow diagram illustrating an example method for executing a read command according to various arrangements.

[0013] Figure 7 A flow diagram illustrating an example method for executing a read command (no read hit on read buffer) according to various arrangements.

[0014] Figure 8 A flow diagram illustrating an example method for executing a read command (no read hit on read buffer) according to various arrangements.

[0015] Figure 9A And 9B An example read buffer table to maintain a total read count for read buffers according to various arrangements.

[0016] Figure 10 A block diagram illustrating an example method for managing read buffers in in-use lists and free lists according to various arrangements.

[0017] Figure 11 A block diagram illustrating an example method for managing read buffers in in-use lists and free lists when overlapping write or deallocate commands invalidate buffer identifiers (IDs) according to various arrangements.

[0018] Figure 12 A block diagram illustrating an example wait read command ID list maintained for each buffer in an in-use list according to various arrangements.

[0019] Figure 13 A flow diagram illustrating an example method for managing read buffers according to various arrangements. DETAILED DESCRIPTION

[0020] In conventional read disturb algorithms for NVM devices, a read disturb counter is maintained for each virtual word line (WL) group. Any WL group that exceeds a read threshold (e.g., 64K reads) is a candidate for a scan read. A scan read not only puts the die and channel in a busy state (thus reducing random read performance), but also causes more read disturbs and triggers shift read retries, and ultimately Vth recovery.

[0021] For example, at an input / output operation (IOPS) random read target performance of 600K per second, a scan read can be triggered every 107ms. If a virtual word line (WL) exceeds the threshold of 15 scan reads, a read disturb can be triggered and the entire superblock is moved to a new block of the NVM device, causing write amplification. Read disturb refresh or Vth recovery can additionally cause a group of input / output determinism (IOD) devices to experience an autonomous transition to a non-deterministic window.

[0022] Conventional read only checks for sequential read prefetching. This increases the processing of sequential reads, not random reads or localized reads. Additionally, read buffers are typically deallocated immediately after a read is completed. In other words, if the current read buffer does not cache hot data considering read disturb WLs in a NAND block, NAND reliability is not improved for a centralized workload using the current read buffer design. The current mechanism to avoid read disturb errors is to use scan reads and read disturb recovery. Read disturb recovery generally refers to any anticipatory preventative process to avoid data corruption caused by read disturb errors. In this context, read disturb recovery refers to moving data to a new superblock when the number of scan reads in a virtual WL reaches a threshold. This method of using scan reads degrades random read performance by putting the die and channel in a busy state. Further reads and scan reads on those WLs cause read disturb recovery, increasing write amplification for the drive.

[0023] Conventional read buffers do not use access frequency information provided by the host to cache hot data, and thus do not leverage metadata to improve management of NVM memory and increase read processing.

[0024] Accordingly, the read buffer design described herein leverages read counters of memory pages in NVM and access frequency information provided by the host to cache hot data. This not only reduces read disturbs in NVM, increasing the life of NVM, but also increases the processing of centralized random read workloads.

[0025] The arrangements disclosed herein relate to systems, methods, and non-transitory processor-readable media for memory storage read buffers that proactively increase the throughput of concentrated workloads and reduce read disturb scan reads and superblock recycling, thus increasing the lifetime of NVM storage (e.g., NAND devices) by reducing background activity. In some examples, read buffers falling into a virtual WL group with a high read count are avoided from being prematurely released. The read buffers disclosed herein can be managed in a decentralized - centralized manner, combining the most frequently used and recently used buffer policy for caching, thus increasing the read throughput and reliability of non-volatile memory storage devices by efficiently releasing read buffers.

[0026] In some arrangements, read buffers are not released immediately upon completion of a read command, but rather are queued in a free list in an appropriate order, such that these read buffers are available for caching before allocating read buffers for new non-overlapping logical addresses to improve latency for frequently read data and avoid long tail read latency, especially for random and localized read commands. In fact, certain data / metadata is read very frequently. This data is typically read directly from NAND after a host buffer cache (if any) miss, which causes read disturb. Without any mechanism to avoid further reads to WLs that have already been disturbed, further reads and scanning of such WLs causes read level shifting, and thus reduces read determinism even in deterministic mode by triggering a shift read. Frequent shift read retries eventually trigger Vth error recovery, thus causing an automatic transition to non-deterministic mode in the IOD driver.

[0027] To help illustrate the present embodiments, Figure 1 A block diagram of a system including a storage device 100 coupled to a host 101 according to some embodiments is shown. In some examples, the host 101 can be a user device operated by a user. The host 101 can include an operating system (OS) configured to provide a file system and applications that use the file system. The file system communicates with the storage device 100 (e.g., a controller 120 of the storage device 100) over a suitable wired or wireless communication link or network to manage data storage in the storage device 100.

[0028] In this regard, the file system of the host 101 sends and receives data to and from the storage device 100 using the appropriate host interface 110. The host interface 110 allows software of the host 101 (e.g., the file system) to communicate with the storage device 100 (e.g., the controller 120). While the host interface 110 is conceptually shown as a block between the host 101 and the storage device 100, the host interface 110 can include one or more controllers, one or more namespaces, ports, transport mechanisms, and connectivity thereto. To send and receive data, the software or file system of the host 101 communicates with the storage device 100 using a storage data transfer protocol running over the host interface 110. Examples of protocols include, but are not limited to, Serial Attached Small Computer System Interface (SAS), Serial AT Attachment (SATA), and Non-Volatile Memory Express (NVMe) protocols. The host interface 110 includes hardware (e.g., a controller) implemented on the host 101, the storage device 100 (e.g., the controller 120), or another device operably coupled to the host 101 and / or the storage device 100 via one or more suitable networks. The host interface 110 and the storage protocol running thereon also include software and / or firmware executing on the hardware.

[0029] In some examples, the storage device 100 is positioned in a data center (not shown for brevity). The data center can include one or more platforms, each supporting one or more storage devices such as, but not limited to, the storage device 100. In some embodiments, the storage devices within a platform are connected to a Top-of-Rack (TOR) switch and can communicate with each other via the TOR switch or another appropriate intra-platform communication mechanism. In some embodiments, at least one router can facilitate communication between storage devices in different platforms, racks, or cabinets via a suitable network fabric. Examples of the storage device 100 include non-volatile devices such as, but not limited to, solid-state drives (SSDs), Non-Volatile Dual In-Line Memory Modules (NVDIMMs), Universal Flash Storage (UFS), Secure Digital (SD) devices, and the like.

[0030] The storage device 100 includes at least a controller 120 and a non-volatile memory (NVM) 140. Other components of the storage device 100 are not shown for the sake of brevity. The NVM 140 includes NAND flash devices. Each NAND flash device includes one or more NAND flash dies 142a-d, 144a-d, 146a-d, and 148a-d, which are NVM capable of holding data without power. Thus, a NAND flash device refers to a plurality of NAND flash devices or dies within the NVM 140. Thus, the NVM 140 can be referred to as a memory array of dies, as shown. Each die 142a-d, 144a-d, 146a-d, and 148a-d has one or more planes. Each plane has a plurality of blocks, and each block has a plurality of pages.

[0031] The dies 142a-d, 144a-d, 146a-d, and 148a-d can be arranged in one or more memory communication channels connected to the controller 120. For example, the dies 142a-d can be configured on one memory channel, the dies 144a-d on another memory channel, and so on. While sixteen dies 142a-d, 144a-d, 146a-d, and 148a-d are shown in the example implementation of the NVM 140, the NVM 140 can include any suitable number of NVM dies arranged in one or more channels in communication with the controller 120. Figure 1

[0032] While the dies 142a-d, 144a-d, 146a-d, and 148a-d are shown as an example implementation of the NVM 140, other examples of NVM technology used to implement the NVM 140 include, but are not limited to, magnetic random access memory (MRAM), phase change memory (PCM), ferroelectric RAM (FeRAM), resistive RAM (ReRAM), etc. The buffer mechanisms described herein can equally be implemented on memory systems using such memory technologies and other suitable memory technologies.

[0033] Examples of the controller 120 include, but are not limited to, an SSD controller (e.g., a client SSD controller, a data center SSD controller, an enterprise SSD controller, etc.), a UFS controller, or an SD controller, etc.

[0034] ​Controller 120 can combine the raw data storage in dies 142a-142d, 144a-144d, 146a-146d, and 148a-148d so that the dies 142a-142d, 144a-144d, 146a-146d, and 148a-148d function as a single storage device. Controller 120 can include a processor, microcontroller, central processing unit (CPU), cache 130, buffers (e.g., buffers 152, 154, and 156), error correction system, data encryption system, flash translation layer (FTL) 132, mapping table 134, flash interface 136, etc. Such functionality can be implemented in hardware, software, and firmware, or any combination thereof. In some arrangements, the software / firmware of controller 120 can be stored in NVM 140 or any other suitable computer-readable storage medium.

[0035] Controller 120 includes appropriate processing and memory capabilities for performing the functions described herein, as well as other functions. Controller 120 manages various features of NVM 140, including but not limited to I / O handling, read, write / program, erase, monitoring, logging, error handling, garbage collection, wear leveling, logical to physical address mapping, data protection (encryption / decryption), etc. Thus, controller 120 provides visibility for dies 142a-142d, 144a-144d, 146a-146d, and 148a-148d.

[0036] Each of cache 130, read buffer 152, and write buffer 156 is a local memory of controller 120. In some examples, each of cache 130, read buffer 152, and write buffer 156 is one or more volatile memories. In some examples, each of cache 130, read buffer 152, and write buffer 156 is a non-volatile persistent storage device. Examples of each of cache 130, read buffer 152, and write buffer 156 include, but are not limited to, RAM, DRAM, static RAM (SRAM), MRAM, PCM, etc.

[0037] The read buffer 152 stores data read from the NVM 140 in response to read commands from the host 101. The controller 120 can transfer data from the read buffer 152 to the host 101 via the host interface 110. In some examples, the data for each logical address range is stored in one of the read buffers 152. After the data is transferred to the host 101, each read buffer 152 can exist for a period of time before being used to cache data for another logical address range. During the period of time, a hit to the read buffer occurs in response to receiving another read command for the same logical address range, and the controller 120 can transfer the same data from the read buffer to the host 101 without having to read from the NVM 140. The arrangements disclosed herein involve dynamically managing the read buffers 152, as disclosed in further detail herein.

[0038] The read buffer table 154 is used by the buffer manager 125 to manage the dynamic allocation of the read buffers 152, as described in further detail herein. The read buffer table 154 can contain various types of information for the read buffers, including but not limited to a range of logical addresses, a read buffer identifier (ID), a list or buffer type, a total read count, a timestamp, etc.

[0039] The write buffer 156 stores data received from the host 101 (via the host interface 110). The controller 120 can write the data stored in the write buffer 156 to the NVM 140 (e.g., dies 142a-d, 144a-d, 146a-d, and 148a-d).

[0040] The buffer manager 125 includes appropriate hardware (e.g., one or more CPUs), software, and / or firmware configured for managing the cache 130, the read buffers 152, the read buffer table 154, and the write buffer 156. In some examples, the buffer manager 125 is implemented using dedicated hardware (e.g., a dedicated processor, CPU, and memory).

[0041] The mapping table 134 is an address mapping table (e.g., a logical-to-physical (L2P) mapping table). The FTL 132 (e.g., an FTL processor, an FTL interface module, etc.) can process the mapping table 134. The mapping table 134 is a mapping table that keeps a record of the correspondence between logical addresses and physical addresses. For example, the mapping table 134 can convert read and write commands (received from the host 101) regarding logical blocks / addresses into low-level commands that reference physical blocks / addresses. In some instances, a read or write command received from the host 101 includes a logical address, such as but not limited to a logical block address (LBA). An LBA is a logical address that identifies a logical block, which can be a region or sector. In certain instances, a logical address range refers to a range of LBAs or a logical cluster address (LCA). The mapping table 134 stores a mapping between each logical address and one or more physical addresses (e.g., pages of memory dies) that store the data of the logical address.

[0042] The FTL 132 can perform L2P operations based on the mapping table 134. For example, the FTL 132 can convert a logical address to a physical address, resolving the physical address that corresponds to the logical address. In response to receiving a write or read command from the host 101 that includes an LCA, the FTL 132 can look up the physical address (e.g., a media cluster address (MCA)) that corresponds to the LCA by using the mapping table 132 in order to write to or read from the physical address. The mapping table 134 can be stored in one or more of the NVM 140, the cache 130, or a suitable memory of the controller 120.

[0043] The flash interface 136 (e.g., a flash interface layer (FIL)) processes incoming flash commands from the FTL 132 in a command queue to schedule those commands for their destination physical memory dies in an optimal manner.

[0044] In some instances, the controller 120 (e.g., the host interface 110) receives a read command from the host 101 and forwards the read command to the cache 130. The cache 130 sends a logical address range to the buffer manager 125. The buffer manager 125 determines whether the logical address range overlaps with a logical address range corresponding to one of the read buffer 152 or the write buffer 156 (a hit buffer). In response to determining whether a hit to one of the read buffer 152 or the write buffer 156 has occurred, the buffer manager 125 reports the hit result back to the cache 130. As described herein, the buffer manager 125 manages the free list and the in-use list.

[0045] For a hit on one of the read buffers 152, data is transferred from the read buffer to the host 101 and the read command is completed. In response to determining that no hit on the read buffer 152 and the write buffer 156 occurred, the FTL 132 determines the physical address corresponding to the logical address range from the mapping table 134 and submits the read request to the NVM 140 via the flash interface 136. The flash interface 136 reads the data from the physical address of the NVM 140 and sends the data, the read count, and the scan read count to the cache 130. The cache 130 transfers the data to the host 101 (e.g., to a buffer of the host 101), determines and updates the total read count.

[0046] While NVM 140 is presented herein as an example, the disclosed schemes can be implemented on any storage system or device connected to the host 101 through an interface, where such system temporarily or permanently stores data for the host 101 for later retrieval.

[0047] Figure 2 is a block diagram of an architecture 200 that supports low-latency operations in accordance with some embodiments. Referring to Figure 1 and 2 , the architecture 200 can be configured from non-volatile memory of a storage device such as, but not limited to, the NVM 140. As shown in Figure 2 , the architecture 200 includes an array of 32 non-volatile memory dies arranged across 8 channels (CH0 to CH7), with 4 NVM dies coupled to each channel. In other words, the architecture 200 includes an array of NAND flash devices. Each NVM die has one or more planes. Any suitable number of dies can be operatively coupled to any suitable number of channels. Each non-volatile memory die in the architecture 200 can be one of the non-volatile memory dies 142a to 142d, 144a to 144d, 146a to 146d, and 148a to 148d. The channels CH0 to CH7 can be physical channels or logical channels.

[0048] Architecture 200 includes superblocks (indicated by same shading) formed by selecting all physical blocks from each NVM die on the same channel and adjacent channels, rather than superblocks formed by selecting physical blocks from each NVM die across all 8 channels. Assuming each region is accessed via channels that are not shared with other regions, each of these superblocks forms an isolated region (e.g., a region isolated from other regions) within NVM 140 that is not affected by channel I / O activity of other regions of NVM 140. Each isolated region can be referred to as an NVM group. Thus, in architecture 200, isolated region 202 includes physical blocks of non-volatile memory dies on two channels CH0 and CH1. Isolated region 204 includes physical blocks of non-volatile memory dies on two channels CH2 and CH3. Isolated region 206 includes physical blocks of non-volatile memory dies on two channels CH4 and CH5. Isolated region 208 includes physical blocks of non-volatile memory dies on two channels CH6 and CH7.

[0049] By configuring superblocks to form isolated regions using only physical blocks from NVM dies in a fixed number of separate channels, for example Figure 2 As shown in architecture 200, I / O operation conflicts at NVM dies and channel controllers can be minimized or completely avoided, allowing for lower latency, greater predictability, and more consistent I / O performance of the storage device. As shown, each isolated region 202-208 includes NVM dies coupled to multiple (e.g., two) channels, thus utilizing multiple channel controllers for each isolated region to handle host I / O operations to improve throughput of each isolated region. Alternatively, an isolated region can include NVM dies coupled to one channel. Thus, the dies of architecture 200 can be selected and arranged to form isolated regions 202-208, but in principle, any number of channels can be used to form isolated regions, where separate isolated regions do not share channels.

[0050] In this regard, an IOD driver refers to an SSD that implements IOD features as described herein. Each NVM group is managed logically as independent of the logic of other NVM groups of the IOD driver. That is, each physical request of the IOD device is mapped to a logical request of the IOD device. The IOD device can independently manage the logic performed on each NVM group and allocate appropriate storage space and bandwidth to each NVM group. Independent of other NVM groups, a certain level of bandwidth is guaranteed with respect to I / O operations of the NVM group from the NVM group, thus allowing latency to be predictable to the host when the host is aware of the guaranteed bandwidth. Thus, the host 101 can perform storage and computing functions using the IOD driver in cases where the guaranteed bandwidth is desired, and due to the characteristics of the IOD driver, the guaranteed bandwidth can be met consistently. An example architecture of the IOD device can be found in U.S. Pub. No. 2019 / 0042150, entitled “SSD ARCHITECTURE SUPPORTING LOW LATENCY OPERATION,” filed on November 1, 2017, the entirety of which is incorporated by reference herein.

[0051] In some arrangements, in addition to the NAND read count and read buffer (cache) hit count, the read buffer 152 can use the “access frequency” field in the read command of the host interface 110 (e.g., NVMe transport layer) to determine the age of the read buffer 152 to increase the hit rate. The hit rate refers to the ratio of incoming read commands that hit an existing read buffer. In some arrangements, the host 101 can inform whether data is frequently read, and the read buffer cache can scale based on memory resource availability.

[0052] In an IOD driver implementing the read buffer system disclosed herein, read determinism can be improved by reducing autonomous transitions to non-deterministic windows (NDWINs). In particular, last releases are determined to be frequently read data.

[0053] In one example, a 1 terabyte (TB) drive using NVM with a NAND die size of 512 gigabytes (Gb) includes 16 parallel dies. Assuming 4 WLs in one WL group, the total capacity of one virtual WL group is:

[0054] Virtual size WL*4 = 16 KB*3 (LMU)*2 (planes)*4 = 384 KB

[0055] In the case where all data in the WL groups are hot data, a 6 megabyte (MB) read buffer size can reduce read disturb scan reads and avoid recycling of at least 16 virtual WL groups (e.g., 6MB / 384KB), i.e., 1 virtual WL group per die in the worst case.

[0056] However, in some cases (e.g., FTL implementation of SSDs to increase read throughput), at least the lower pages (L) for a bank (herein, a die across all channels is referred to as a bank) are sequentially written (programmed) before the middle page (M), and after sequentially writing the middle page, all the upper pages (U) for the bank are sequentially written. Thus, only one double plane page (e.g., 32 kilobyte (KB)) in the virtual WL is hot data. Thus, a read buffer with a 6MB size can reduce scan reads and recycling of 192 virtual WLs (e.g., 6MB / 32KB). This read buffer can cover 192 / 16 = 12 virtual WLs per die.

[0057] From a performance perspective, a multi-plane read across 2 dies at a rate of 400MB / s per channel is sufficient to keep the channels busy with an effective channel rate of 640MB / s. Thus, a 3MB (e.g., 16KB page size * 2 planes * 16 channels * 3) read buffer is sufficient to saturate the channel bandwidth of all channels in a 16 channel configuration.

[0058] Thus, if a total of 6MB is allocated for read buffers in a 16 channel drive, the run-time read buffer allocation can be limited to 3MB at higher queue depths without any read performance loss, such that at any point in time, a 3MB frequent read data buffer can be dedicated solely for use as a read cache, as described herein. With a total size of the read buffer of 36MB, a total of 1152 (192*6) read disturb WL groups can be cached at any point in time.

[0059] As described herein, by determining the read buffer size based on the number of WL groups to cache, a tradeoff between memory for read buffer 152 and tail read latency / write amplification can be achieved.

[0060] In some arrangements, the read buffer size can be defined based on the number of WL groups to cache. In particular, the read buffer size can be defined according to the available memory and the number of read disturb WL groups to cache.

[0061] Some arrangements are directed to a scattered cache system, where a used list and a free list are maintained. Figure 3 is a block diagram illustrating a used list 300 and a free list 320 according to some arrangements. Reference is made to Figure 3In response to receiving a new read command from the host 101, the read buffer manager 125 can allocate a read buffer from the free list 320. The read buffer manager 125 can then store data read from the NVM device in the allocated read buffer. The read buffer manager 125 can then send the data stored in the allocated read buffer to the host 101. The read buffer manager 125 can then update the in-use list 300 to indicate that the allocated read buffer is now in use. The read buffer manager 125 can then update the free list 320 to indicate that the allocated read buffer is no longer available for allocation. The read buffer manager 125 can then repeat the process of allocating a read buffer from the free list 320, storing data read from the NVM device in the allocated read buffer, sending the data stored in the allocated read buffer to the host 101, updating the in-use list 300, and updating the free list 320 in response to receiving a new read command from the host 101.

[0062] Similarly, the in-use list 320 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, the free list 320 includes buffer ID 330a, buffer ID 330b, …, buffer ID 330n. Each buffer ID is linked to the next buffer ID. For example, the first buffer ID (buffer ID 330a) is linked to the second buffer ID 330b, and so on. The last buffer ID 330n is linked to NULL, indicating that buffer ID 330n is the last buffer ID in the free list 320. Read buffers are allocated from the head of the free list 320 (e.g., buffer ID 330a). For example, in response to receiving a new read command for a non-overlapping logical address range, the controller 120 (e.g., the buffer manager 125) allocates a read buffer that is the current head of the free list 320 and stores data read from the NVM device in the read buffer. A non-overlapping logical address range refers to a range that does not overlap (is different from) a range corresponding to read buffers in the free list 320 and the in-use list 300. Thus, a non-overlapping logical address range does not result in a hit to an existing buffer.

[0063] In some arrangements, frequently read data is dynamically cached in the read buffers 152 using a field (e.g., an “access frequency” field) and a total read count of a read command via the host interface 110 (e.g., the NVMe specification). This ensures that more frequently read data buffers are allocated for new non-overlapping reads only after less frequently used and unallocated data buffers are consumed.

[0064] The host 101 can indicate the frequency of access to any given range of logical addresses, for example, by sending information to the controller 120. This information includes access frequency values that indicate the frequency of access to a range of logical addresses. Figure 4 Table 400 illustrates example access frequency values according to the NVMe standard protocol. The access frequency values can be defined by the host interface 110. The access frequency values are provided in the "access frequency" field in a read command. Each access frequency value maps to a corresponding definition of access frequency (e.g., the frequency of reading and / or writing to a range of logical addresses, otherwise referred to as the expected read frequency and / or the expected write frequency).

[0065] In response to receiving an access frequency value of 0 ("0000") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that the host 101 did not provide frequency information for the range of logical addresses. In response to receiving an access frequency value of 1 ("0001") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that typical (moderate) read and write frequencies are expected for the range of logical addresses.

[0066] In response to receiving an access frequency value of 2 ("0010") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that lower read and write frequencies (e.g., infrequent writes and infrequent reads) are expected for the range of logical addresses. In response to receiving an access frequency value of 3 ("0011") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that lower write frequencies (e.g., infrequent writes) and higher read frequencies (e.g., frequent reads) are expected for the range of logical addresses.

[0067] In response to receiving an access frequency value of 4 ("0100") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that lower read frequencies (e.g., infrequent reads) and higher write frequencies (e.g., frequent writes) are expected for the range of logical addresses. In response to receiving an access frequency value of 5 ("0101") for a range of logical addresses from the host 101, the controller 120 (e.g., the buffer manager 125) determines that higher read and write frequencies (e.g., frequent reads and writes) are expected for the range of logical addresses.

[0068] In response to receiving an access frequency value of 6 ("0110") for a logical address range from host 101, controller 120 (e.g., buffer manager 125) determines that the command corresponding to the logical address range is a one-time read command (e.g., the command was issued by host 101 due to a virus scan, backup, file copy, archive, etc.). In response to receiving an access frequency value of 7 ("0111") for a logical address range from host 101, controller 120 (e.g., buffer manager 125) determines that the command corresponding to the logical address range is a speculative read command (e.g., the command was issued by host 101 for a pre-fetch operation). In response to receiving an access frequency value of 8 ("1000") for a logical address range from host 101, controller 120 (e.g., buffer manager 125) determines that the logical range will be overwritten in the near future.

[0069] In some instances, in response to determining that a read buffer for the logical address range has an access frequency value corresponding to frequent reads and infrequent writes (e.g., access frequency value 3), buffer manager 125 assigns a high read count to the read buffer when the read buffer (identified by buffer ID) is first issued. In some instances, the high read count is a read count of 64K, which is considered a high read count from a read disturbance perspective. The read buffer is linked to the free list 320 according to total read count.

[0070] On the other hand, in response to determining that a read buffer for the logical address range (1) has an access frequency value corresponding to infrequent reads (e.g., access frequency values 2, 4, 6, or 7); (2) has an access frequency value corresponding to frequent writes (frequent updates) (e.g., access frequency values 5 or 8); or (3) is invalidated by a write or deallocation command, buffer manager 125 places the read buffer corresponding to the logical address range at the head of the free list 320 (e.g., buffer ID 330a). In this aspect, data corresponding to the logical address range is cached for a short amount of time. The remaining read buffers in the free list 320 are linked in ascending order of total read count, with the buffer having the least total read count (buffer ID 330b) immediately following buffer ID 330a, and the buffer having the most total read count (buffer ID 330n) immediately preceding NULL.

[0071] This mechanism allows a more frequently read data buffer to be allocated by a new non-overlapping read only after less frequently read, frequently written, and / or unallocated data buffers are consumed in the free list 320.

[0072] In some arrangements, the controller 120 can save a timestamp corresponding to a read command. In one example, the controller 120 receives a timestamp with a read command from the host 101. In this case, the timestamp indicates a time at which the host 101 issued the read command (e.g., a read command generation timestamp). In another example, the controller 120 determines a timestamp corresponding to a read command in response to receiving the read command from the host 101. In this case, the timestamp indicates a time at which the controller 120 received the read command. In some examples, the controller 120 can store a timestamp corresponding to each received read command in a read buffer table.

[0073] In some arrangements, once a predetermined number of read buffer allocations, the oldest read buffer is allocated instead of the head of the free list 320. For example, assuming a total number of buffer counts of N, after every (N / 4) reads, the oldest buffer entry in the free list 320 (e.g., a read buffer corresponding to the earliest timestamp) is allocated for the next non-overlapping read instead of allocating a buffer from the head of the free list 320. This allows the controller 120 to gradually evict read buffers with high read counts from the free list 320 before evicting other read buffers that are currently being frequently read, assuming those read buffers can have been frequently read in the past but have not been accessed for a period of time.

[0074] In this regard, Figure 5 is a block diagram illustrating a free list 500 according to some arrangements. Referring to Figures 1 to 5 , the free list 500 can be a list of buffers (buffer IDs), such as but not limited to the free list 320. The free list 500 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, the free list 500 includes buffer ID 501, buffer ID 510, buffer ID 511, buffer ID 520, buffer ID 521, and buffer ID 530. Each buffer ID is linked to the next buffer ID. The last buffer ID 530 is linked to NULL, indicating that the buffer ID 530 is the last buffer ID and tail of the free list 500. Read buffers are allocated from the head of the free list 500 (e.g., buffer ID 501). For example, in response to receiving a read command for a non-overlapping logical address range, the controller 120 allocates a read buffer that is the current head of the free list 500 and stores data read from the NVM 140 in the read buffer. Thus, read buffers with buffer IDs closer to the head of the free list 500 are allocated for new read commands before buffer IDs closer to the tail (NULL) of the free list 500.

[0075] In one example, the free list 500 contains read buffers belonging to three groups (e.g., a first group 541, a second group 542, and a third group 543). The first group 541 of buffer IDs 501-510 is closer to the head of the free list 500 than the second group 542 and the third group 543, and thus, buffer IDs 501-510 are allocated to new read commands before buffer IDs 511-530 are allocated to new read commands. Each of the buffer IDs 501-510 in the first group 541 identifies a read buffer containing data that is no longer valid. For example, the host 101 can issue a write or deallocate command for a logical address range, and as a result of executing the command, the data in the read buffer corresponding to the logical address range is outdated and / or no longer needed. In this regard, such read buffers can be allocated first to new read commands, and thus, are located at the head of the free list 500.

[0076] The second group 542 of buffer IDs 511-520 is closer to the head of the free list 500 than the third group 543, and thus, buffer IDs 511-520 are allocated to new read commands before buffer IDs 521-530 are allocated to new read commands. Each of the buffer IDs 511-520 in the second group 542 identifies a read buffer corresponding to a logical address range that is considered to be associated with frequent writes and infrequent reads (e.g., has an access frequency value of 2, 4, 5, 6, 7, or 8 in the table 400). Frequent writes cause the data in the read buffer to become outdated. Thus, data corresponding to logical address ranges that are expected to experience both frequent writes and infrequent reads can not need to be kept for long, and thus, can be allocated to new read commands after the buffers in the first group 541 have been allocated to new read commands.

[0077] The third group 543 of buffer IDs 521-530 is ordered according to total read counts. In some examples, the buffers are arranged according to increasing total read counts, with the buffer having the lowest total read count (e.g., buffer ID 521) closest to the head of the free list 500, and the buffer having the highest total read count (e.g., buffer ID 530) closest to the tail of the free list 500. As described, given that the likelihood of a hit for a read buffer corresponding to a logical address range expected to have a higher total read count (e.g., has an access frequency value of 3 in the table 400) is high due to frequent reads, such a read buffer is allocated to new read commands.

[0078] As described, in some examples, assuming a total number of buffer IDs 501-530 is N, after every (N / 4) read, the buffer ID corresponding to the earliest timestamp in the free list 500 is assigned for the next non-overlapping read command, instead of assigning a buffer from the head of the free list 500.

[0079] Figure 6 is a flowchart illustrating an example method 600 for executing a read command, according to various arrangements. According to Figures 1 to 6 The method 600 can be performed by the controller 120. At 610, the controller 120 receives a read command from the host 101 via the host interface 110. At 620, the controller 120 determines whether the read command hits a read buffer. Hitting a read buffer refers to a logical address range in the read command corresponding to a read buffer in which the latest data for the logical address range has been stored, such that the controller 120 can transfer data from the read buffer instead of reading data from the NVM 140.

[0080] In some arrangements, in response to the controller 120 determining that the read command hits a read buffer (620: YES), the controller 120 processes the read command from the read buffer at 640. On the other hand, in response to the controller 120 determining that the read command does not hit a read buffer (620: NO), the controller 120 processes the read command from the NVM 140 at 630.

[0081] Figure 7 is a flowchart illustrating an example method 700 for executing a read command, according to various arrangements. According to Figures 1 to 7 The method 700 can be performed by the controller 120, and is an example implementation of block 630. For example, in response to determining that the logical address range does not result in a hit to any read buffer (620: NO), the controller 120 allocates a read buffer from the head of the free list 320 at 701.

[0082] At 702, the controller 120 determines one or more physical addresses corresponding to the logical address range. For example, the controller 120 can obtain MCAs mapped to the logical address range from an address mapping table (e.g., L2P mapping table), and issue a request to read data from the NVM 140 via a flash interface layer (FIL). At 703, the controller 120 (e.g., FIL) returns data from the NVM 140 together with a read count and a scan read count (e.g., 0 to 15) of the corresponding virtual WL in the NVM 140.

[0083] At 704, the controller 120 returns the data to the host 101 and stores the NAND read count of the read buffer. For example, the controller 120 can transfer the data from the read buffer to a buffer (e.g., DRAM) of the host 101 via the host interface 110. In some instances, the NAND read count (N NAND ) on the virtual WL can be determined using expression (1):

[0084] N NAND = N read_count + N scan_read_count * 64K (1);

[0085] where N read_count refers to the read count on the virtual WL, and N scan_read_count refers to the scan read count on the virtual WL.

[0086] At 705, the controller 120 determines whether the access frequency value is a first value (e.g., 3). As shown in the table 400, an access frequency value indicative of an access frequency (e.g., a read frequency and a write frequency) can be received from the host 101. The access frequency value of 3 for a logical address range corresponds to a lower number of writes (e.g., infrequent writes) and a higher number of reads (e.g., frequent reads) expected for the logical address range.

[0087] In response to determining that the access frequency value is 3 (705: YES), the controller 120 determines an assigned read count for the logical address range at 706. In one instance, in response to determining that the assigned read count for the logical address range is currently 0, the controller 120 assigns a predetermined number (e.g., 64K) as the assigned read count. On the other hand, in response to determining that the access frequency value is not 3 (705: NO), the controller 120 determines whether the access frequency value is a second value (e.g., 2, 4, 5, 6, 7, or 8) at 707.

[0088] In response to determining that the access frequency value is the second value (707: YES), the controller 120 moves the read buffer to the head of the free list 320 or moves the read buffer into the second group 542 at 708. For example, the buffer ID 330a identifies the read buffer allocated at 703. On the other hand, in response to determining that the access frequency value is not the second value (707: NO), the controller 120 determines a total read count of the read buffer allocated at 703 at 709. In some instances, the total read count (N Total ) of the read buffer can be determined using expression (2):

[0089] N Total = N hit_count + N NAND + N assigned (2);

[0090] where N hit_count is the read hit count, and N assigned is the assigned read count. The total read count is stored in the read buffer table.

[0091] At 710, the controller 120 links the read buffers (e.g., their buffer IDs) in the free list 320 according to their total read counts. In other words, the buffers in the free list 320 whose access frequency values are not 2, 4, 5, 6, 7, and 8 are arranged by total read count such that the buffers with lower total read count numbers are closer to the head of the free list 320 (and are allocated for next use first).

[0092] The buffer ID corresponding to the read buffer is linked or inserted between the first buffer ID and the second buffer ID such that the first buffer ID with a total read count less than the total read count of the read buffer is closer to the head of the free list 320, and the second buffer ID with a total read count greater than the total read count of the read buffer is closer to the tail of the free list 320. This allows the read buffers with lower total read counts to be closer to the head of the free list 320.

[0093] The method 700 avoids further read disturb to the WLs corresponding to data corresponding to logical addresses with higher read counts, and avoids future scan reads and read disturb recycling to the superblocks corresponding to those virtual WLs.

[0094] Figure 8 is a flowchart illustrating an example method 800 for performing a read command according to various arrangements. According to Figures 1 to 8 , the method 800 can be performed by the controller 120, and is an example implementation of block 640. For example, in response to determining that the logical address range results in hitting any read buffer (620: YES), the controller 120 increments the read hit count (N hit_count ) of the read buffer at 801. The controller 120 can thus maintain a read hit count for each buffer of the cache.

[0095] At 802, the controller 120 moves the read buffer from the free list 320 to the in-use list 300. At 803, the controller 120 transfers the data stored in the read buffer to a buffer (e.g., DRAM) of the host 101 via the host interface 110. At 804, the controller 120 determines whether the access frequency value is a predetermined value (e.g., 2, 4, 5, 6, 7, or 8).

[0096] In response to determining that the access frequency value is the predetermined value (804: YES), at 805, the controller 120 moves the read buffer to the head of the free list 320. For example, the buffer ID 330a identifies the read buffer. On the other hand, in response to determining that the access frequency value is not the predetermined value (804: NO), at 806, the controller 120 determines a total read count for the read buffer. In some instances, the total read count (N Total ) for the read buffer can be determined using expression (2), where the read hit count (N hit_count ) is incremented at 801. The total read count is stored in the read buffer table.

[0097] At 807, the controller 120 links the read buffers (e.g., their buffer IDs) in the free list 320 according to their total read counts, such that the buffers in the free list 320 are arranged by total read count, such that buffers with lower total read count numbers are closer to the head of the free list 320 (and are allocated for next use first).

[0098] In some instances where two or more read buffers have the same total read count, the read buffer with the later timestamp is used to cache read data, and the read buffer with the earlier timestamp is linked closer to the head of the free list 320 (and is allocated for next use before the read buffer with the later timestamp).

[0099] Figure 9A and 9B are example read buffer tables 900a and 900b for maintaining total read counts for read buffers according to various arrangements. Referring to Figures 1 to 9B , the read buffer tables 900a and 900B maintain a correspondence between a range of logical addresses (e.g., LCAs), a read buffer ID, a list type (in-use list 300 or free list 320), a total read count, and a timestamp. The read buffer table 900a is a snapshot of the read buffer table during operation of the storage device 100. The read buffer table 900b is a read buffer table initialized at boot time.

[0100] In arrangements where the storage device 100 is an IOD storage device, the storage device 100 is in a deterministic window (DTWIN) or an NDWIN. At boot time, all read buffers will be in the free list 320, as shown in the read buffer table 900b.

[0101] In some arrangements, read buffer table searching is enabled in both DTWIN and NDWIN. Assuming storage 100 is primarily writing, deallocating, and performing background operations in NDWIN, in response to determining that a write or deallocation command hits an LCA in read buffer table 900a, controller 120 can invalidate the entry corresponding to the LCA and remove the entry from read buffer table 900a.

[0102] In arrangements in which storage 100 is an IOD storage, DTWIN and NDWIN can alternate. At the beginning of DTWIN, controller 120 typically inserts an entry related to a read buffer corresponding to an LCA for a new, non-overlapping read command. At the beginning of NDWIN, controller 120 typically invalidates an entry related to a read buffer corresponding to an LCA for an overlapping write command.

[0103] At startup and in scenarios in which storage 100 is enabled for predictable latency mode, read buffer table 900b is initialized to invalid LCAs (e.g., “0xFFFFFFFF”). When a new read command is received from host 101 during DTWIN, read buffer table 900a can first be searched according to the range of logical addresses (e.g., LCAs) associated with the read command to determine whether a read buffer hit occurs. In response to determining that no read buffer hit occurs, controller 120 populates a new entry in read buffer table 900a with the range of logical addresses, read buffer ID, list type, total read count, and timestamp.

[0104] Further, in response to receiving a read command from host 101, controller 120 searches read buffer table 900a and determines a read buffer hit to an existing entry having the same range of logical addresses. If a read buffer hit is determined, controller 120 increments the read hit count (thus increasing the total read count), sets the list type from free to in-use, moves the read buffer to in-use list 300, and reads the existing data from the read buffer.

[0105] After the copy of the data is transferred to host 101, controller 120 repositions the read buffer back to free list 320 according to the new access frequency of the LCAs and updated total read count, and updates read buffer table 900a accordingly. This ensures that free list 320 is dynamically ordered according to the access frequency and total read count of read buffers, which can change during operation of storage 100.

[0106] Figure 10 is a block diagram illustrating an example method for managing read buffers in in-use list 1000 and free list 1020 according to various arrangements. Reference is made to Figures 1 to 10In-use list 1000 is an example implementation of in-use list 300, and free list 1020 is an example implementation of free list 320.

[0107] In-use list 1000 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, in-use list 1000 includes buffer ID 1010a, buffer ID 1010b, and buffer ID 1010c. Each buffer ID is linked to the next buffer ID. For example, the head of in-use list 1000 (buffer ID 1010a) is linked to second buffer ID 1010b, and second buffer ID 1010b is linked to last buffer ID 1010c. Last buffer ID 1010c is linked to NULL, indicating that buffer ID 1010c is the tail of in-use list 1000.

[0108] Free list 1020 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, free list 1020 includes buffer ID 1030a, buffer ID 1030b, and buffer ID 1030c. Each buffer ID is linked to the next buffer ID. For example, the head of free list 1020 (buffer ID 1030a) is linked to second buffer ID 1030b, and second buffer ID 1030b is linked to last buffer ID 1030c. Last buffer ID 1030c is linked to NULL, indicating that buffer ID 1030c is the tail of free list 1020.

[0109] In response to receiving a read command for a non-overlapping range of logical addresses (missing any buffer in free list 1020 or in-use list 1000), controller 120 allocates a read buffer that is the current head of free list 1020 (e.g., corresponding to buffer ID 1030a). As described, in some examples, once a predetermined number (e.g., N / 4) of read buffer allocations, the oldest read buffer (e.g., corresponding to the earliest timestamp) is allocated instead of the head of free list 1020.

[0110] After allocation, at 1041, the read buffer identified by buffer ID 1030a is moved from the free list 1020 to the in-use list 1000. As shown, buffer ID 1030a is moved to the tail of the in-use list 1000 as buffer ID 1010c. The controller 120 issues a read command to the NVM 140 and stores data read from the NVM 140 in the read buffer. After the controller 120 transfers the data from the read buffer (buffer ID 1010c) to the host 101, the controller 120 moves the read buffer (buffer ID 1010c) back to the free list 1020. In the example shown, in response to determining that the access frequency value is a predetermined number (e.g., the second value, 707: YES), the controller 120 moves the read buffer (buffer ID 1010c) to the head of the free list 1020 at 1042 (708), where the read buffer ID 1010c again corresponds to the read buffer ID 1030a. Alternatively, the controller 120 moves the read buffer (buffer ID 1010c) into the second group 542. In other examples, as described, the controller 120 can move the read buffer (buffer ID 1010c) to the free list 1020 according to the updated total read count of the read buffer (buffer ID 1010c).

[0111] Figure 11 is a block diagram illustrating an example method for managing read buffers in an in-use list 1100 and a free list 1120, according to various arrangements. Reference is made to Figures 1 to 11 , the in-use list 1100 is an example implementation of the in-use list 300, and the free list 1120 is an example implementation of the free list 320.

[0112] The in-use list 1100 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, the in-use list 1100 includes buffer ID 1110a, buffer ID 1110b, and buffer ID 1110c. Each buffer ID is linked to the next buffer ID. For example, the head of the in-use list 1100 (buffer ID 1110a) is linked to the second buffer ID 1110b, and the second buffer ID 1110b is linked to the last buffer ID 1110c. The last buffer ID 1110c is linked to NULL, indicating that buffer ID 1110c is the tail of the in-use list 1100.

[0113] The free list 1120 is a list of read buffers, each read buffer identified by a corresponding buffer ID. As shown, the free list 1120 includes buffer ID 1130a, buffer ID 1130b, and buffer ID 1130c. Each buffer ID is linked to the next buffer ID. For example, the head of the free list 1120 (buffer ID 1130a) is linked to the second buffer ID 1130b, and the second buffer ID 1130b is linked to the last buffer ID 1130c. The last buffer ID 1130c is linked to NULL, indicating that buffer ID 1130c is the tail of the free list 1120.

[0114] In some arrangements, in response to receiving a new write or deallocate command during NDTWIN, the controller 120 searches the read buffer table 900a for a read buffer hit. For example, the controller 120 can determine that the logical address (e.g., LCA) range of the received write or deallocate command is the same as the logical address range corresponding to buffer ID 1130b. In this case, the controller 120 writes data to the write buffer cache. Then, the controller 120 invalidates the overlapping range of logical addresses and moves the corresponding read buffer ID 1130b to the head of the free list 1120 (as buffer ID 1130a) at 1141 for consumption by the next non-overlapping read. The data in the write buffer will eventually be written to the NVM 140.

[0115] In some arrangements, in response to receiving a new read command in both DTWIN and NDTWIN, the read buffer table 900a can be populated and searched. Read hits on write buffers can be detected in parallel.

[0116] When a read buffer is allocated for a non-overlapping read from the beginning of the free list 320, the previous LCA entry (if any) for the buffer can be removed from the read buffer table 900a, and a new LCA entry is added to the read buffer table 900a along with the associated new total read count and timestamp.

[0117] In some arrangements in which multiple hits to a buffer in use have been determined, those in-use read command IDs can be queued using a linked list. Figure 12 is a block diagram illustrating an example wait read command ID list maintained for each buffer identified in the in-use list 1200 according to various arrangements. Reference is made to Figures 1 to 12The in-use list 1200 is a list of read buffers, including the read buffer IDs 1210a, 1210b,... and 1210n described herein. Each of the read buffer IDs 1210a, 1210b,... and 1210n is linked to or includes a corresponding one of the pending read command ID lists 1210a, 1210b,... and 1210n.

[0118] Each read command ID (e.g., read command ID A, read command ID B,..., read command ID N) in the pending read command ID list 1210a corresponds to a read command received from the host 101 for a logical address (e.g., LCA) range of the buffer ID 1210a (e.g., a hit on the LCAs of the buffer ID 1210a). As shown, the pending read command ID list 1220a includes read command ID A, read command ID B,... and read command ID N. Each read command ID is linked to the next read command ID. For example, the head of the pending read command ID list 1220a (read command ID A) is linked to the second read command ID B, and so on. The last read command ID N is linked to NULL, indicating that the read command ID N is the tail of the pending read command list 1220a that has hit the LCAs corresponding to the particular read command ID. Each read command ID identifies a read command received by the controller 120 from the host 101. The read command IDs A to N in the pending read command ID list 1220a can be queued according to the timestamps of each read command A to N. A read command received at an earlier time (earlier timestamp) (e.g., read command ID A) is placed towards the head of the pending read command ID list 1220a. The other pending read command ID lists 1220b to 1220n are similarly configured, as shown.

[0119] After the controller 120 transfers data from the NVM to the read buffer corresponding to the buffer ID in the in-use list 300, all read commands (identified by the corresponding read command IDs) in the pending list 1200 for the same logical address range can be serviced using the same buffer.

[0120] Assuming that overlapping write commands for a logical address range invalidate entries corresponding to the same logical address range from the read buffer table 900a because the data is stale due to a write, the controller 120 can search the read buffer table 900a table while searching for read hits on the write buffer. This improves the overall read latency.

[0121] Accordingly, as described herein, the present arrangement involves a read buffer mechanism that uses the "access frequency" field of a read command to improve read performance. Accordingly, the access frequency value is metadata that can be used to improve performance and increase NAND longevity. The controller 120 can use the access frequency value in the "access frequency" field of a read command to manage the free list 320 such that read buffers that cache frequently read data can be maintained for longer periods of time and data that is frequently written and / or infrequently read is released more quickly, thereby increasing throughput and reducing latency for hot data.

[0122] Additionally, the read hit count of a cached buffer and the NAND read disturb read count of a WL group are used to determine the order of read buffers in the free list 320, and thus, to cache more frequently read data. This reduces read disturb scan reads and read disturb recycling, thereby reducing write amplification and increasing NAND longevity.

[0123] Implementing a free buffer list to order read buffers according to a most frequently used and recently used cache policy allows read buffers to be efficiently released such that the read buffers can simultaneously act as a dynamic read buffer cache. Accordingly, implementing an efficient buffer allocation and release policy and read command timeline as described herein can improve read determinism in a DTWIN and can reduce autonomous transitions to a NDWIN.

[0124] Figure 13 is a flowchart illustrating an example method 1300 for managing read buffers according to various arrangements. With reference to Figures 1 to 13 The method 1300 can be performed by the controller 120.

[0125] At 1310, the controller 120 receives information from the host 101 indicating a frequency of accessing data stored in the storage device 100 (e.g., NVM 140). At 1320, in response to receiving the information, the controller 120 (e.g., buffer manager 125) determines an order in which to allocate read buffers 152 of the storage device 100 for a next read command. In some examples, determining the order in which to allocate read buffers 152 refers to determining an order of read buffers 152 in a free list 320. Each read buffer in the free list 320 corresponds to a time-to-live, which is defined as a time period between completing a read command (completing a transfer of data from the read buffer to the host 101) and allocating to a next new read command having a different logical address range. A read buffer placed at or closer to a head of the free list 320 has a shorter time-to-live than another read buffer placed at or closer to a tail of the free list 320.

[0126] In some arrangements, each read buffer 152 stores data corresponding to a range of logical addresses. Information indicative of a frequency of accessing data includes an access frequency value (shown in table 400) for the range of logical addresses of each read buffer 152. The controller 120 (e.g., buffer manager 125) arranges the read buffers in the free list 320 based at least in part on the access frequency value corresponding to each read buffer 152.

[0127] In some examples, the access frequency value indicates one of an expected read frequency or a combination of an expected read frequency and an expected write frequency. A read command corresponding to a range of logical addresses received from the host 101 includes the access frequency value.

[0128] In some examples, the read buffers 152 in the free list 320 are arranged according to a total read count for each read buffer 152. After allocating a second read buffer of a read buffer 152 having a lower total read count, a first read buffer of a read buffer 152 having a higher total read count is allocated for a new read command. The total read count for each read buffer 152 is a sum of a read hit count, a NAND read count, and an allocated read count. In some examples, the read buffer table 900a stores one or more of a range of logical addresses, a read buffer ID, a buffer type, a total read count, and a timestamp for each read buffer 152.

[0129] In some examples, at least some of the read buffers 152 in the free list 320 are arranged according to a total read count for each read buffer 152. After allocating a second read buffer of a read buffer 152 having a lower total read count and a later timestamp, a first read buffer of a read buffer 152 having a higher total read count and an earlier timestamp is allocated for a new read command.

[0130] In some arrangements, the read buffers 152 in the free list 230 (500) include a first group 541, a second group 542, and a third group 543. The first group 541 includes first read buffers (corresponding to buffer IDs 501-510) each corresponding to invalid data. The second group 542 includes second read buffers (corresponding to buffer IDs 511-520) each having an access frequency value corresponding to frequent writes and infrequent reads (e.g., access frequency values 2, 4, 5, 6, 7, or 8 in table 400). The third group 543 includes third read buffers (corresponding to buffer IDs 521-530) arranged according to a total read count for each third read buffer. In some examples, after allocating the first read buffers and the second read buffers, the third read buffers are allocated for a new read command. After allocating the first read buffers, the second read buffers are allocated for a new read command.

[0131] In some arrangements, in response to determining that the logical address range of the new read command is different from the logical address range of any read buffer in the free list 320 (no hit buffer, ranges do not overlap), the controller 120 (buffer manager 125) allocates a first read buffer from the free list 320. The controller 120 reads data corresponding to the logical address range of the new read command from the NVM 140 into the first read buffer. The controller 120 transfers the data from the first read buffer to the host 10.

[0132] In some examples where the access frequency value (e.g., 3) in the new read command corresponds to frequent reads and infrequent writes, the controller 120 (buffer manager 125) assigns a higher assigned read count to the first read buffer. After transferring the data to the host 101, the controller 120 (buffer manager 125) adds the first read buffer back to the free list 320 according to a total read count for the first read buffer determined based at least in part on the high read count.

[0133] In some examples where the access frequency value (e.g., 2, 4, 5, 6, 7, or 8) in the new read command corresponds to one or more of infrequent reads or frequent writes, the controller 120 (buffer manager 125) adds the first read buffer back to the second group of the free list 320 after transferring the data to the host 101.

[0134] In some examples where the access frequency value (e.g., 0 or 1) in the new read command corresponds to no frequency information provided or typical read and write counts, the controller 120 (buffer manager 125) adds the first read buffer back to the free list 230 according to a total read count for the first read buffer after transferring the data to the host 101.

[0135] In some arrangements, in response to determining that the logical address range of the new read command is the same as the logical address range of a first read buffer of the read buffers in the free list, the controller 120 (buffer manager 125) increases a read hit count for the first read buffer.

[0136] In some examples where the access frequency value (e.g., 2, 4, 5, 6, 7, or 8) in the new read command corresponds to one or more of infrequent reads or frequent writes, the controller 120 (buffer manager 125) adds the first read buffer back to the second group of the free list 320 after transferring the data to the host 101.

[0137] In some instances where the access frequency value in the new read command (e.g., 0 or 1) corresponds to no frequency information being provided or typical read and write frequencies, the controller 120 (buffer manager 125) after transferring the data to the host 101, adds the first read buffer back to the free list 230 according to the total read count of the first read buffer.

[0138] In some instances where the access frequency value in the new read command (e.g., 3) corresponds to frequent reads and infrequent writes, the controller 120 (buffer manager 125) after transferring the data to the host 101, adds the first read buffer back to the free list 320 according to the total read count of the first read buffer.

[0139] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other aspects. Thus, the claims are not intended to be limited to the aspects presented herein, but are to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more." Unless specifically stated otherwise, the term "some" refers to one or more. All structural and functional equivalents to the elements of the various aspects described throughout this previous description that are known or later come to be known to one of ordinary skill in the art are expressly incorporated herein by reference and intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether these

[0140] It is to be understood that any particular order or hierarchy of steps in the processes disclosed is an example of illustrative approaches. Based upon design preferences, it is understood that the particular order or hierarchy of steps in the processes can be rearranged while remaining within the scope of the previous description. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[0141] The previous description of the disclosed implementations is provided to enable any person skilled in the art to make or use the disclosed subject matter. Various modifications to these implementations will be readily apparent to those skilled in the art, and the generic principles defined herein can be applied to other implementations without departing from the spirit or scope of the previous description. Thus, the previous description is not intended to be limited to the implementations shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0142] The various examples illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given example are not necessarily limited to the associated example and can be used or combined with other examples shown and described or in combination. Moreover, the claims are not intended to be limited by any one example.

[0143] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of ordinary skill in the art, the order of steps in the foregoing examples can be performed in any order. Words such as "thereafter," "then," "next," etc. are generally not intended to limit the order of steps; these words are simply used to guide the reader through the description of processes. Furthermore, any reference to claim elements in the singular, for example, using the articles "a," "an" or "the" is not to be construed as limiting the claim

[0144] The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the examples disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0145] The hardware used to implement various illustrative logics, logical blocks, modules, and circuits described in connection with the examples disclosed herein can be implemented or performed with a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods can be performed by circuitry that is specific to a given function.

[0146] In some demonstrative examples, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The steps of a method or algorithm disclosed herein can be embodied in a processor-executable software module which can reside on a non-transitory computer- or processor- readable storage medium. Non-transitory computer- or processor-readable storage media can be any storage media that can be accessed by a computer or a processor. By way of example, and not limitation, such non-transitory computer- or processor-readable media can include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer or processor. Disk and disc, as used herein, includes compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy disks and blu-ray discs where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above also are included within the scope of non-transitory computer- and processor-readable media. Additionally, the operations of a method or algorithm can reside in one or any combination or set of codes and / or instructions that can be resident on a non-transitory computer- and / or computer-readable storage medium, and can be incorporated into a computer program product.

[0147] The foregoing description of the disclosed examples has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed. Many modifications and variations will be apparent to practitioners skilled in the art. Embodiments were chosen and described in order to best explain the principles of the disclosure and its best mode of operation. It is intended that the disclosure be construed as including all such modifications and variations.

Claims

1. A method comprising: receiving, by a controller of a storage device, information from a host indicative of a frequency of accessing data stored in the storage device; and in response to receiving the information, determining, by the controller, an order in which read buffers of the storage device are to be allocated for next read commands, wherein each of the read buffers has a respective ID, and wherein determining the order comprises linking a next one of the read buffers to a previous one of the read buffers using the respective ID of the next one of the read buffers.

2. The method of claim 1, wherein each of the read buffers stores data corresponding to a range of logical addresses; the information indicative of the frequency of accessing the data comprises an access frequency value for the range of logical addresses of each of the read buffers; and the method further comprises arranging, by the controller, the read buffers in a free list based at least in part on the access frequency value corresponding to each of the read buffers.

3. The method of claim 2, wherein the access frequency value is indicative of one of an expected read frequency or a combination of the expected read frequency and an expected write frequency; and read commands corresponding to the range of logical addresses received from the host include the access frequency value.

4. The method of claim 2, wherein the read buffers in the free list are arranged according to a total read count of each of the read buffers; after allocating a second one of the read buffers having a lower total read count, a first one of the read buffers having a higher total read count is allocated for a new read command.

5. The method of claim 4, wherein the total read count of each of the read buffers is a sum of a read hit count, a NAND read count, and an allocated read count.

6. The method of claim 5, wherein a read buffer table stores one or more of a range of logical addresses, a read buffer identifier ID, a buffer type, a total read count, and a timestamp for each of the read buffers.

7. The method of claim 2, wherein at least some of the read buffers in the free list are arranged according to a total read count of each of the read buffers; after allocating a second one of the read buffers having a lower total read count and a later timestamp, a first one of the read buffers having a higher total read count and an earlier timestamp is allocated for a new read command.

8. The method of claim 2, wherein the read buffers in the free list comprise a first group, a second group, and a third group; the first group comprises first read buffers each corresponding to invalid data; the second group comprises second read buffers each having an access frequency value corresponding to frequent writes and infrequent reads; and the third group comprises third read buffers arranged according to a total read count of each of the third read buffers.

9. The method of claim 8, wherein the first read buffers each have a first buffer type; and the second read buffers each have a second buffer type. allocating the third read buffer for a new read command after allocating the first read buffer and the second read buffer; and allocating the second read buffer for a new read command after allocating the first read buffer.

10. The method of claim 2, further comprising, in response to determining that a logical address range of a new read command is different from a logical address range of any of the read buffers in the free list: allocating, by the controller, a first read buffer from the free list; reading, by the controller, the data corresponding to the logical address range of the new read command from a non-volatile memory of the storage device into the first read buffer; and transferring, by the controller, the data from the first read buffer to the host.

11. The method of claim 10, wherein the access frequency value in the new read command corresponds to frequent reads and infrequent writes; and the method further comprises: assigning, by the controller, a higher read count for the first read buffer; and after transferring the data to the host, adding, by the controller, the first read buffer back to the free list according to a total read count of the first read buffer determined based at least in part on the higher read count.

12. The method of claim 10, wherein the access frequency value in the new read command corresponds to one or more of infrequent reads or frequent writes; and the method further comprises: after transferring the data to the host, adding, by the controller, the first read buffer back to the free list at a position, wherein the position corresponds to a group of read buffers each having an access frequency value corresponding to frequent writes and infrequent reads.

13. The method of claim 10, wherein the access frequency value in the new read command corresponds to no frequency information provided or typical number of reads and writes; and the method further comprises: after transferring the data to the host, adding, by the controller, the first read buffer back to the free list according to a total read count of the first read buffer.

14. The method of claim 2, wherein in response to determining that the logical address range of a new read command is the same as a logical address range of a first read buffer of the read buffers in the free list, increasing a read hit count of the first read buffer.

15. The method of claim 14, wherein the access frequency value in the new read command corresponds to one or more of infrequent reads or frequent writes; and the method further comprises: after transferring the data to the host, adding, by the controller, the first read buffer back to the free list at a position, wherein the position corresponds to a group of read buffers each having an access frequency value corresponding to frequent writes and infrequent reads.

16. The method of claim 14, wherein the access frequency value in the new read command corresponds to no frequency information provided or typical number of reads and writes; and the method further comprises: after transferring the data to the host, adding, by the controller, the first read buffer back to the free list according to a total read count of the first read buffer. the access frequency value in the new read command corresponds to no frequency information provided or typical read and write frequency; and the method further comprises: after transferring the data to the host, adding the first read buffer back to the free list by the controller according to a total read count.

17. The method of claim 14, wherein the access frequency value in the new read command corresponds to frequent read and infrequent write; and the method further comprises: after transferring the data to the host, adding the first read buffer back to the free list by the controller according to a total read count.

18. A storage device, comprising: non-volatile memory; and a controller configured to: receive information from a host indicative of a frequency of accessing data stored in the storage device; and in response to receiving the information, determine an order in which to allocate read buffers of the storage device for a next read command, wherein each of the read buffers has a respective ID, and wherein determining the order comprises linking a next one of the read buffers to a previous one of the read buffers using the respective ID of the next one of the read buffers.

19. The storage device of claim 18, wherein each of the read buffers stores data corresponding to a range of logical addresses; the information indicative of the frequency of accessing the data comprises an access frequency value for the range of logical addresses of each of the read buffers; and the controller is further configured to arrange the read buffers in a free list based at least in part on the access frequency value corresponding to each of the read buffers.

20. A non-transitory computer-readable medium comprising computer-readable instructions such that when executed cause a processor to: receive information from a host indicative of a frequency of accessing data stored in a storage device; and in response to receiving the information, determine an order in which to allocate read buffers of the storage device for a next read command, wherein each of the read buffers has a respective ID, and wherein determining the order comprises linking a next one of the read buffers to a previous one of the read buffers using the respective ID of the next one of the read buffers.

Images