Write merging via HMB to optimize write performance

Abstract

The present disclosure generally relates to improved processing of write commands. A host memory buffer (HMB) or other storage space may be utilized to delay execution of host write commands, which will improve write performance in different use cases and will also allow for more concurrent streams than open blocks without affecting write or read performance. Typically, upon receipt of a write command, the write command is revised to a new write command that is logically equivalent to the original write command. The revised write command is moved to the HMB along with the data. In doing so, write commands are merged and write command processing is improved.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. non-provisional application No. 17 / 885,265, filed on August 10, 2022, and entitled “Write Coalescing Via HMB To Optimize Write Performance,” and is hereby incorporated by reference in its entirety for all purposes. Background Art Technical Field

[0003] Embodiments of the present disclosure are generally directed to improved processing of write commands.

[0004] Description of Related Art

[0005] Write performance is important for both client and server storage applications and is one of the most important metrics for clients. Write performance may be hampered in different use cases where system resources are limited. For example, data storage devices typically maintain open blocks for each stream ID currently used by the host, so that data written from the stream ID is written to the corresponding open blocks.

[0006] When the number of open blocks in the data storage device is less than the number of different streams, there is a problem that may cause excessive writing and reading to reduce write performance. When the host writes data to the data storage device, it may be useful to temporarily store the data in the intermediate space to perform some operations before the data is actually written to the storage medium. The intermediate storage space can be a dedicated buffer in the storage space of the data storage device, but in order to save space, it can be a host memory buffer (HMB) located in the host instead. HMB is a host storage space dedicated to the needs of the storage controller. Typically, HMB stores management tables or other management data according to the configuration of the controller.

[0007] In the existing architecture, once the corresponding write command is interpreted, the write data is directly passed from the data buffer of the host to the controller of the data storage device by the hardware (HW) module. Information about the command interpretation is passed to the completion queue. The write data itself does not have to be written to the memory device immediately, but can be stored in a cache. The cache can be in the data storage device or on the host side in the HMB.

[0008] When the number of concurrent streams is higher than the number of open blocks, data from the streams may be written to the same open blocks, thereby impairing later read throughput. Data from those additional streams may also be relocated later when write amplification is caused. Alternatively, the host may be limited to the number of streams dictated by the number of open blocks.

[0009] Therefore, there is a need in the art for improved processing of write commands. Summary of the invention

[0010] The present disclosure generally relates to improved processing of write commands. A host memory buffer (HMB) or other storage space can be utilized to delay the execution of a host write command, which will improve write performance under different use cases and will also allow for more concurrent streams than open blocks without affecting write or read performance. Typically, once a write command is received, the write command is revised to a new write command that is logically equivalent to the original write command. The revised write command is moved to the HMB together with the data. In doing so, write commands are merged and write command processing is improved.

[0011] In one embodiment, a data storage device includes: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command; determine that the write command may be write-merged; allocate one or more buffers in a second memory device that is separate and different from the first memory device; generate a revised write command based on the write command; and move data associated with the write command to at least one of the allocated one or more buffers.

[0012] In another embodiment, a data storage device includes: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command; revise the write command to create a revised write command; store the revised write command in a second memory device different from the first memory device; determine that a predetermined time period has passed or a trigger mechanism has occurred; and execute the revised write command.

[0013] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: convert a write command from a physical region page (PRP) entry to a scatter-gather list (SGL) entry; store data associated with the PRP entry and the converted write command in a host device; notify the host device that the write command is completed; and execute the converted write command after the notification, wherein the execution includes writing the stored data to the memory device. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Thus, a detailed understanding of the manner in which the above-described features of the present disclosure are understood, a more particular description of the present disclosure, the above brief overview, may be obtained by reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the drawings illustrate only typical embodiments of the present disclosure and are therefore not to be considered limiting of its scope, as the present disclosure may admit to other equally effective embodiments.

[0015] Figure 1 is a schematic block diagram illustrating a storage system according to certain embodiments, in which a data storage device may be used as a storage device for a host device.

[0016] Figure 2 is a block diagram illustrating a method of operating a storage device to perform a read or write command according to certain embodiments.

[0017] Figure 3 is a flow chart showing the execution of a write command.

[0018] Figure 4 is a schematic diagram of an architecture incorporating write command coalescing according to one embodiment.

[0019] Figure 5 is a flow chart illustrating write command merging according to one embodiment.

[0020] Figure 6 is a flow diagram illustrating delayed command stream execution according to one embodiment.

[0021] Figure 7 is a schematic diagram of a system incorporating write command coalescing according to one embodiment.

[0022] Figure 8 is a flow chart illustrating write command merging and execution according to one embodiment.

[0023] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0024] Hereinafter, reference is made to embodiments of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described embodiments. On the contrary, any combination of the following features and elements (whether or not related to different embodiments) is considered to realize and practice the present disclosure. In addition, although the embodiments of the present disclosure can achieve advantages that are superior to other possible solutions and / or superior to the prior art, whether a specific advantage is achieved by a given embodiment is not a limitation to the present disclosure. Therefore, the following aspects, features, embodiments and advantages are merely illustrative, and are not considered to be elements or limitations of the appended claims, unless explicitly stated in the claims. Similarly, reference to "the present disclosure" should not be interpreted as a summary of any inventive subject matter disclosed herein, and should not be considered to be elements or limitations of the appended claims, unless explicitly stated in the claims.

[0025] The present disclosure generally relates to improved processing of write commands. Host memory buffers (HMB) or other storage spaces can be utilized to delay the execution of host write commands, which will improve write performance under different use cases and will also allow more concurrent streams than open blocks without affecting write or read performance. Typically, once a write command is received, the write command is revised to a new write command that is logically equivalent to the original write command. The revised write command is moved to the HMB together with the data. In doing so, write commands are merged and write command processing is improved.

[0026] Figure 1 1 is a schematic block diagram of a storage system 100 according to certain embodiments, wherein a host device 104 communicates with a data storage device 106. For example, the host device 104 can utilize a non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes a host DRAM 138 and an optional host memory buffer 150. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, that can operate as a storage array. For example, the storage system 100 can include multiple data storage devices 106 that are configured as a redundant array of inexpensive / independent disks (RAID) that collectively function as a mass storage device for the host device 104.

[0027] Host device 104 may store data to and / or retrieve data from one or more storage devices, such as data storage device 106. Figure 1As shown, host device 104 can communicate with data storage device 106 via interface 114. Host device 104 can include any of a variety of devices, including a computer server, a network attached storage (NAS) unit, a desktop computer, a notebook (i.e., laptop) computer, a tablet computer, a set-top box, a telephone handset such as a so-called "smart" phone, a so-called "smart" tablet computer, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, or other device capable of sending or receiving data from a data storage device.

[0028] Data storage device 106 includes controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, and write buffer 116. In some examples, for clarity, data storage device 106 may include Figure 1 150. The controller 108 may include volatile memory such as DRAM 152 and a controller memory buffer (CMB) dedicated for use by the host device 104. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed board includes conductive traces that electrically interconnect the components of the data storage device 106, etc. In some examples, the physical size and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some exemplary standard form factors include, but are not limited to, a 3.5" data storage device (e.g., an HDD or SSD), a 2.5" data storage device, a 1.8" data storage device, a peripheral component interconnect (PCI), a PCI extension (PCI-X), a PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini card, MiniPCI, etc.). In some examples, the data storage device 106 may be directly coupled (e.g., directly soldered or plugged into a connector) to a motherboard of the host device 104.

[0029] The interface 114 may include one or both of a data bus for exchanging data with the host device 104 and a control bus for exchanging commands with the host device 104. The interface 114 may operate according to any suitable protocol. For example, the interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), etc. The interface 114 (e.g., a data bus, a control bus, or both) is electrically connected to the controller 108, thereby providing an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of the interface 114 may also allow the data storage device 106 to receive power from the host device 104. For example, as Figure 1 As shown, power supply 111 may receive power from host device 104 via interface 114 .

[0030] NVM 110 may include multiple memory devices or memory cells. NVM 110 may be configured to store and / or retrieve data. For example, a memory cell of NVM 110 may receive data and a message from controller 108 indicating that the memory cell stores the data. Similarly, the memory cell may receive a message from controller 108 indicating that the memory cell retrieves data. In some examples, each of the memory cells may be referred to as a die. In some examples, NVM 110 may include multiple dies (e.g., multiple memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128MB, 256MB, 512MB, 1GB, 2GB, 4GB, 8GB, 16GB, 32GB, 64GB, 128GB, 256GB, 512GB, 1TB, etc.).

[0031] In some examples, each memory cell may include any type of non-volatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of non-volatile memory device.

[0032] NVM 110 may include multiple flash memory devices or memory cells. NVM flash memory devices may include NAND or NOR-based flash memory devices, and may store data based on the charge contained in the floating gate of the transistor for each flash memory cell. In NVM flash memory devices, the flash memory device may be divided into multiple dies, wherein each of the multiple dies includes multiple physical or logical blocks, which may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of NVM cells may be electrically connected using word lines to define pages in multiple pages. The corresponding cells in each of the multiple pages may be electrically connected to the corresponding bit lines. In addition, the NVM flash memory device may be a 2D or 3D device, and may be a single-level cell (SLC), a multi-level cell (MLC), a three-level cell (TLC), or a four-level cell (QLC). The controller 108 may write data to and read data from the NVM flash memory device at the page level, and erase data from the NVM flash memory device at the block level.

[0033] The power supply 111 can provide power to one or more components of the data storage device 106. When operating in standard mode, the power supply 111 can use power provided by an external device such as the host device 104 to power one or more components. For example, the power supply 111 can use power received from the host device 104 via the interface 114 to power one or more components. In some examples, the power supply 111 may include one or more power storage components that are configured to power one or more components when operating in a shutdown mode, such as when power is stopped from being received from an external device. In this way, the power supply 111 can be used as an onboard backup power supply. Some examples of one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, and the like. In some examples, the amount of power that can be stored by one or more power storage components can be a function of the cost and / or size (e.g., area / volume) of such one or more power storage components. In other words, as the amount of power stored by one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0034] Volatile memory 112 may be used by controller 108 to store information. Volatile memory 112 may include one or more volatile memory devices. In some examples, controller 108 may use volatile memory 112 as a cache. For example, controller 108 may store cached information in volatile memory 112 until the cached information is written to NVM 110. Figure 1As shown, the volatile memory 112 may consume power received from the power supply 111. Examples of the volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.)).

[0035] The controller 108 can manage one or more operations of the data storage device 106. For example, the controller 108 can manage reading data from the NVM 110 and / or writing data to the NVM. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 can initiate a data storage command to store data to the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data associated with the write command in an internal memory (i.e., a second volatile memory) of the controller 108 before sending the data to the NVM 110, which internal memory can be an SRAM memory.

[0036] Figure 2 2 is a block diagram illustrating a method 200 of operating a storage device to execute a read or write command according to one embodiment. The method 200 may be used with a host device 104 and a data storage device 106. Figure 1 The storage system 100 is used in conjunction with the storage system 100 , wherein the data storage device includes a controller 108 .

[0037] Method 200 begins at operation 250, where the host device writes a command as an entry into an SQ. At operation 250, the host device may write one or more commands into the SQ. The command may be a read command or a write command. The host device may include one or more SQs.

[0038] In operation 252, the host device writes one or more updated SQ tail pointers and rings a doorbell or sends an interrupt signal to notify or signal the storage device that a new command is ready for execution. If there is more than one SQ, the host can write an updated SQ tail pointer and send a doorbell or interrupt signal for each of the SQs. In operation 254, in response to receiving the doorbell or interrupt signal, the controller of the storage device obtains a command from the one or more SQs, and the controller receives the command.

[0039] In operation 256, the controller processes the command and writes or transfers data associated with the command to the host device memory. The controller may process more than one command at a time. The controller may process one or more commands in a submission order or in sequence. Processing a write command may include identifying a partition to write data associated with the command, writing the data to one or more logical block addresses (LBAs) of the partition, and advancing a write pointer of the partition to identify the next available LBA within the partition.

[0040] In operation 258, once the command has been fully processed, the controller writes a completion entry corresponding to the executed command to a completion queue (CQ) of the host device and moves or updates the CQ head pointer to point to the newly written completion entry.

[0041] In operation 260, the controller generates an interrupt signal or doorbell and sends it to the host device. The interrupt signal indicates that the command has been executed and the data associated with the command is available in the memory device. The interrupt signal further notifies the host device that the CQ is ready to be read or processed.

[0042] In operation 262, the host device processes the completion entry. In operation 264, the host device writes the updated CQ head pointer to the storage device and rings a doorbell or sends an interrupt signal to the storage device to release the completion entry.

[0043] Figure 3 300 is a flow chart illustrating the execution of a write command. Initially, a write command is received. The write command is then processed at 302. At 304, corresponding data for the write command is obtained from the host device. The data is typically in a host device data buffer. The data is then processed and stored in a cache. The cache may be a HMB, CMB, controller DRAM, or NVM of a data storage device. Once the data is in the cache, the completion queue is updated at 306.

[0044] As will be discussed herein, the write sequence is modified so that data can be stored in the HMB (or any similar host-based memory space) or CMB to delay the execution of the host write command to improve the overall write performance of the system. Like this, more concurrent streams than open blocks are possible without negatively affecting write performance.

[0045] The method is based on analyzing the write workflow and determining that temporarily delaying the actual write to the memory device will benefit the overall write performance. The decision can be based on host-specified or device-specified write alignment / granularity considerations. For example, writes that do not meet the stream write granularity or namespace write granularity guidance can be merged. In another example, if urgent foreground maintenance is required to release open blocks, writes can be temporarily merged, allowing the host to release the write buffer when the device cannot write new data to the memory device (i.e., NAND) at the same time.

[0046] The write coalescing feature will involve hardware (HW) modifications such that the host device pointer will be revised and written to point to the HMB space. The HW will automatically direct the memory access (DMA) of the original payload to the new HMB location before automatically completing the command. After the DMA, the firmware (FW) or HW can release the write and then resubmit the write as if it was a new write command, but without the additional completion.

[0047] Figure 4 is a schematic diagram of an architecture incorporating write command merging according to one embodiment, and uses an example to depict the concept. An original NVMe write command 406 in host memory 402 is queued by the host in a submission queue 404. Command 406 holds pointers to data buffers. PRP1 holds a pointer to the first buffer. PRP2 holds pointers to PRP lists 408, each of which is a pointer to a data buffer 410. The device controller first obtains the original write command, classifies the original write command, and decides whether to execute the write command now or postpone it. The decision is based on the classification result (e.g., stream ID) and the current state of open blocks in the device. If the write command is postponed, the content of the write command is copied to HMB 412 with some adaptation. In Figure 4 In the embodiment of the present invention, the revised command 416 uses a scatter-gather list (SGL) method instead of a physical region page (PRP). The revised command 416 containing the SGL section is stored in the internal submission queue 404 implemented in the HMB 412. The device prepares an SGL list 418 in the HMB 412, and each entry points to a data buffer 420 in the HMB. The data from the original data buffer 410 is copied to the data buffer 420 allocated in the HMB 412. The completion entry is issued to the host device. Later, the revised command 416 is executed by the data storage device, and all relevant information is obtained from the HMB 412. The completion entry is not issued to the host device, because the completion entry has been issued when the original data is copied from the data buffer 410 to the data buffer 420.

[0048] After command interpretation is complete, a new "write merge module" can analyze the current write given the status of the last command, the HMB contents, and memory-related characteristics. The module can then decide whether to use the HMB delayed command, write data directly to the storage device (regular write), or execute the previously delayed command from the HMB and write the delayed command data to the data storage device together with the current write data.

[0049] In the case where the host device issues a refresh command indicating that the data storage device writes all data not yet written to the memory device, the data storage device will execute all previously delayed commands and write the data to the memory device. In one embodiment, the data storage device generally has a limited number of reserved open blocks. An open block is a block that is not fully written, wherein different protection mechanisms are applied due to the elasticity of the reduction of different factors. When a block is fully written, the block is closed, and another block is opened. In the host device supporting streams, an open block can be associated with a stream so that the data written sequentially are written to the same physical block (metablock). However, the number of streams supported by the host device can be greater than the number of available open blocks in the storage device. As discussed herein, it is proposed to use the write merging of the stack data related to the specific stream in the HMB (which is not supported by the open block in the storage controller). Data based on HMB can be written to the memory device when merging the entire block or at another time determined by the controller, which allows effective support for any number of concurrent streams without the need to be specifically for task-specific space in the controller.

[0050] Figure 5 500 is a flowchart showing the write command merge according to an embodiment, which shows the write process. Initially, a write command is received, and the classification of the write command (such as stream ID) and the current state of the system (such as open block count) is performed at 502 in the write merge module, and a determination is made at 504 whether the command should be merged. In the affirmative result, HMB space will be allocated at 506. At 508, a revised write command with a pointer list pointing to HMB is generated in the HMB. At 510, the write command data content is copied to the allocated position, and at 512, the completion entry is issued to the host device. If the write merge to the write command should not be applied at 504, the corresponding data is obtained from the data buffer, processed and stored in the cache at 514, and then the completion queue is updated at 512.

[0051] Figure 6600 is a flow chart illustrating execution of a delayed command flow according to one embodiment, and describes a decision to write delayed write command contents from an HMB to a data storage device. The decision to execute a delayed command may be caused by a "refresh" command sent by a host device, or by a number of open blocks changed by a data storage device (some blocks are closed). When a decision is made to write a delayed write command from an HMB, the data will be written to the storage device and no additional overhead associated with publishing a completion entry to the host device is required.

[0052] In one embodiment, the device controller implements a reserved SQ that is invisible to the host device. The data storage device queues revised write commands in the reserved SQ. In the event that there is a trigger to execute some revised commands, the data storage device simply rings the doorbell of the associated, reserved SQ. The revised write commands in the reserved SQ are then executed normally, with the exception that there is no release to the CQ. In other words, when there is a reserved SQ, there is no corresponding reserved CQ, and therefore there is no place to post any completions. Completions do not need to be posted to normal CQs because completions should have been posted previously. The number of reserved SQs can be a function of the supported streams and open blocks.

[0053] When cache operations are disabled by the host device globally or command-specifically, the same flow will work, with the only difference being that completion will be sent only after execution of the revised command is complete and only after the data is stored in the memory device (e.g., NAND).

[0054] In flow chart 600, once a triggering event occurs or a predetermined time has passed, a determination is made at 602 as to whether it is time to execute a delayed command. For example, the triggering event may be a refresh command. If it is not time to execute a delayed write command, the process continues to wait. If it is time to execute a delayed write command, the HW is activated at 604 to execute the delayed write command, and the delayed write command is executed at 606. The delayed write command is executed using the HMB as a data buffer rather than a host data buffer as in the original write command. After the delayed write command is completed, the completion queue is not updated at 608 because the completion queue was previously updated after creating the delayed write command and storing the data in the HMB buffer.

[0055] In another embodiment, a CMB-based write delay for merging small write commands may be employed. A CMB is a memory buffer located in a data storage device controller that can be used for different host device applications. In this case, the CMB can be used as a memory space (although typically a much smaller memory space) to delay shorter write commands.

[0056] Figure 7 7 is a schematic diagram of a system 700 incorporating write command merging according to one embodiment and depicts a high-level block diagram of a system for write command merging. System 700 includes a host device 702 having a DRAM 704 and an HMB 706. System 700 also includes a memory device 710 and a data storage device controller 708.

[0057] The controller 708 includes one or more processors 724, a flash interface module (FIM) 726 for interfacing with the memory device 710, a host interface module (HIM) 712 for interfacing with the host device 702, a command scheduler 722 coupled between the FIM 726 and the HIM 712, an encryption / decryption module 718 disposed between the FIM 726 and the HIM 712, and a data path and ECC and RAID disposed between the encryption / decryption module 718 and the FIM 726. The HIM 712 includes an HMB write command merge module 714 that decides when to execute a write command and simultaneously activates a DMA copy engine 716 to copy the command and all data structures with some modifications from the host device 702 memory to the HMB 706.

[0058] In one embodiment, the revised command maintained in the HMB may be a write scatter command that includes several LBA ranges instead of just one LBA range. In a write scatter command embodiment, several host device write commands may be compressed into a single revised write scatter command stored in the HMB. In another embodiment, the grouping of delayed write commands may be based on context attribute identifiers, or based on regions / partitions in a DPM / ZNS device.

[0059] Figure 8 800 is a flow chart illustrating write command coalescing and execution according to one embodiment. The process begins when a write command is received at 802, or more specifically, a write command is placed in a submission queue in the host and a doorbell is rung to notify the data storage device that there is a command to be acquired in the submission queue. A determination is made at 804 as to whether the write command can be coalesced. If the write command cannot be coalesced at 804, the write command is executed as usual and the completion queue is updated to indicate that the write command has been executed.

[0060] If the write command can be merged at 804, the write command is revised at 808 and stored in the new location together with the data. In one embodiment, the new location is the HMB. In another embodiment, the new location is the CMB. In yet another embodiment, the new location is in the host controller volatile memory. In any case, in any embodiment, the new location is not the NVM to which the data of the original write command will eventually be written. After revising the write command and storing the relevant data in the new location, the completion queue is updated by publishing the completion to the completion queue at 810 and ringing the doorbell to notify the host that the write command has been completed (even if the write command has not actually been completed). At this point, the write command has been revised, and the data has been moved to the new location. The revised write command will be executed at a later point in time, at which point in time, the original write command will be technically finally completed.

[0061] The revised write command may be executed after a predetermined time period has passed or a triggering event has occurred. If the time threshold has been exceeded at 812, the revised command is executed at 814 and completion is not issued to the completion queue at 816. If the time threshold has not been exceeded at 812, a determination is made at 818 as to whether a triggering event has occurred. If the triggering event has occurred at 818, the revised command is executed at 814 and completion is not issued to the host at 816. If the triggering event has not occurred at 818, the revised write command is still not executed and is simply waiting for execution. It should be noted that the checks for the triggering event and whether the time threshold has been exceeded can be performed in any order or simultaneously. An example of a triggering event is receiving a refresh command from the host. In any case, whenever the revised write command is executed, the host is not notified because the host believes that the write command has been completed and does not know or have not known the existence of the revised write command.

[0062] In any case, the host is informed that the original write command has been completed before the revised write command is completed. In other words, the host device believes that the original write command has been completed even though the original write command has not actually been completed and the data to be written to the NVM has not yet been written to the NVM. Completion of the revised write command (which technically completes the original write command by writing the data to the NVM) occurs later in time than the host believes, and therefore the write command is processed more effectively and efficiently. The location where the revised write command and associated data are stored while awaiting execution is in a memory location such as an HMB, CMB, or other storage location that is not the final, last storage location indicated by the original write command (i.e., NVM or NAND).

[0063] By utilizing write commands coalesced in an HMB (or CMB or other storage area), improved write performance occurs for different scenarios (such as having more concurrent streams than open blocks), and thus processing write commands more effectively and efficiently.

[0064] In one embodiment, a data storage device includes: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command; determine that the write command may be write-merged; allocate one or more buffers in a second memory device separate and different from the first memory device; generate a revised write command according to the write command; and move data associated with the write command to at least one buffer in the allocated one or more buffers. The controller is further configured to generate a pointer list pointing to at least one buffer. The controller is configured to update a completion queue for the write command. The update occurs before the write command is completed. The update occurs after the revised write command is executed. The second memory device is a host memory buffer (HMB). The second storage device is a controller memory buffer (CMB). The write command is a non-volatile memory express (NVMe) write command using one or more physical region page (PRP) entries. The revised write command uses a scatter-gather list (SGL) element. The controller is further configured to execute the revised write command in response to a trigger mechanism or a predetermined time period that has passed.

[0065] In another embodiment, a data storage device includes: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command; revise the write command to create a revised write command; store the revised write command in a second memory device different from the first memory device; determine that a predetermined time period has passed or a trigger mechanism has occurred; and execute the revised write command. The controller is further configured to activate hardware (HW) to execute the revised write command. Executing the revised write command includes retrieving data associated with the revised write command from the second memory device. Storing the revised write command in the second memory device includes storing the revised write command and the data associated with the write command in the second memory device. Executing the revised write command includes retrieving data associated with the write command from the second memory device and writing the data to the first memory device. A completion queue in a host device is updated before executing the revised write command. The completion queue is not updated after executing the revised write command.

[0066] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: convert a write command from a physical region page (PRP) entry to a scatter-gather list (SGL) entry; store data associated with the PRP entry and the converted write command in a host device; notify the host device that the write command is completed; and execute the converted write command after the notification, wherein the execution includes writing the stored data to the memory device. The controller is configured not to notify the host device that the converted write command is executed. The controller is configured to execute the converted write command after receiving a refresh command from the host device.

[0067] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be envisaged without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the appended claims.

Claims

1. A data storage device, comprising: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: Receive write command; determining that the write command may be write-merging; allocating one or more buffers in a second memory device separate and distinct from the first memory device; generating a revised write command according to the write command; as well as Data associated with the write command is moved to at least one buffer of the allocated one or more buffers. 2 . The data storage device of claim 1 , wherein the controller is further configured to generate a list of pointers to the at least one buffer. 3 . The data storage device of claim 1 , wherein the controller is configured to update a completion queue for the write command.

4. The data storage device of claim 3, wherein the updating occurs before completing the write command.

5. The data storage device of claim 4, wherein the updating occurs after execution of the revised write command.

6. The data storage device of claim 1, wherein the second memory device is a host memory buffer (HMB).

7. The data storage device of claim 1, wherein the second memory device is a controller memory buffer (CMB).

8. The data storage device of claim 1, wherein the write command is a Non-Volatile Memory Express (NVMe) write command using one or more Physical Region Page (PRP) entries.

9. The data storage device of claim 8, wherein the revised write command uses a scatter-gather list (SGL) element.

10. The data storage device of claim 1, wherein the controller is further configured to execute the revised write command in response to a trigger mechanism or a predetermined period of time having passed.

11. A data storage device, comprising: a first memory device; and a controller coupled to the memory device, wherein the controller is configured to: Receive write command; revising the write command to create a revised write command; storing the revised write command in a second memory device different from the first memory device; determining that a predetermined time period has elapsed or a triggering mechanism has occurred; as well as The revised write command is executed.

12. The data storage device of claim 11, wherein the controller is further configured to activate hardware (HW) to execute the revised write command.

13. The data storage device of claim 12, wherein executing the revised write command comprises retrieving data associated with the revised write command from the second memory device.

14. The data storage device of claim 13, wherein storing the revised write command in the second memory device comprises storing the revised write command and data associated with the write command in the second memory device.

15. The data storage device of claim 11, wherein executing the revised write command comprises retrieving data associated with the write command from the second memory device and writing the data to the first memory device.

16. The data storage device of claim 15, wherein a completion queue in a host device is updated prior to executing the revised write command.

17. The data storage device of claim 16, wherein the completion queue is not updated after executing the revised write command.

18. A data storage device, the data storage device comprising: Memory device; and a controller coupled to the memory device, wherein the controller is configured to: Convert write commands from physical region page (PRP) entries to scatter-gather list (SGL) entries; storing data associated with the PRP entry and the converted write command in a host device; Notifying the host device that the write command has been completed; as well as The converted write command is executed subsequent to the notifying, wherein the executing includes writing the stored data to the memory device.

19. The data storage device of claim 18, wherein the controller is configured not to notify the host device that the converted write command is executed.

20. The data storage device of claim 18, wherein the controller is configured to execute the converted write command after receiving a refresh command from the host device.

Images