SYSTEM, METHOD, AND MEDIUM FOR IMPROVING READ COMMAND PROCESSING TIME IN SOLID-STATE DRIVES - Patent application

Abstract

A mechanism for improving read command processing time in a solid-state drive (SSD) is provided, the mechanism comprising: determining a workload type of the SSD; and in response to determining that the workload type is a pure read workload type, using at least one hardware processor, determining at least one command size into which the original background write will be split; and splitting the background write into a plurality of split background writes, each having one of the determined at least one command size. In some embodiments, the at least one command size constitutes one page of a physical medium of the SSD. In some embodiments, the at least one command size includes at least two different sizes. In some embodiments, the mechanism further comprises combining two or more split background writes. In some embodiments, the original background write is split before being placed in a channel queue.

Description

[Background technology]

[0001] [CROSS-REFERENCE TO RELATED APPLICATIONS] This application claims the benefit of U.S. Patent Application No. 18 / 090,358, filed December 28, 2022, which is incorporated herein by reference in its entirety.

[0002] Solid-state drives (SSDs) are widely used in general-purpose and special-purpose computers such as desktop computers, laptop computers, tablet computers, servers, mobile phones, Internet of Things (IoT) devices, among others.

[0003] Usually, all writes to SSD are mainly done using an optimal data size for better write performance. For background writes as well, the same size is usually used. For example, in some cases, writes are done using an optimal data size of 128kB (e.g., writes are done to two quad planes, where each quad plane is 4 pages, and each page is 16kB of data, so 2*4*16kB=128kB).

[0004] Certain SSDs (e.g., NAND SSDs) allow only one of a write command (also called a program command) and a read command to be sent from the SSD's controller to the SSD's physical media (e.g., the NAND device of a NAND SSD) at a time. A background write (a type of write command) sent to the SSD's physical media (e.g., for garbage collection, read disturb relocation, and metadata) that was initiated earlier must be completed before a subsequently received read command can be sent to the NAND SSD's physical media. This can have a negative impact on the SSD's host read latency.

[0005] Therefore, a new mechanism for improving read command processing time in solid-state drives is desirable. Summary of the Invention

[0006] According to some embodiments, a mechanism (which may include a system, a method, and a medium) is provided for improving read command processing time in a solid-state drive.

[0007] In some embodiments, a system for improving read command processing time in a solid-state drive (SSD) is provided, the system comprising: a memory; and at least one hardware processor collectively configured to: determine a workload type of the SSD; and, in response to determining that the workload type is a pure read workload type, determine at least one command size into which an original background write will be split; and split the background write into a plurality of split background writes, each having one of the determined at least one command size. In some of these embodiments, the at least one command size constitutes a page of the physical medium of the SSD. In some of these embodiments, the at least one command size includes at least two different sizes. In some of these embodiments, the at least one hardware processor is also collectively configured to combine at least two or more split background writes. In some of these embodiments, the original background write is split before being placed in a channel queue. In some of these embodiments, the background write is split after being placed in a channel queue.

[0008] In some embodiments, a method for improving read command processing time in a solid-state drive (SSD) is provided, the method comprising: determining a workload type of the SSD; and in response to determining that the workload type is a pure read workload type, determining, using at least one hardware processor, at least one command size into which an original background write will be split; and splitting the background write into a plurality of split background writes, each having one of the determined at least one command size. In some of these embodiments, the at least one command size constitutes a page of the physical medium of the SSD. In some of these embodiments, the at least one command size includes at least two different sizes. In some of these embodiments, the method further comprises combining two or more split background writes. In some of these embodiments, the original background write is split before being placed in a channel queue. In some of these embodiments, the background write is split after being placed in a channel queue.

[0009] In some embodiments, a non-transitory computer-readable medium is provided that includes computer-executable instructions that, when executed by a processor, cause the processor to perform a method for improving read command processing time in a solid-state drive (SSD), the method including: determining a workload type of an SSD; and, in response to determining that the workload type is a pure read workload type, determining at least one command size into which an original background write is split; and splitting the background write into a plurality of split background writes, each having one of the determined at least one command size. In some of these embodiments, the at least one command size constitutes a page of the physical medium of the SSD. In some of these embodiments, the at least one command size includes at least two different sizes. In some of these embodiments, the method further comprises combining two or more split background writes. In some of these embodiments, the original background write is split before being placed in a channel queue. In some of these embodiments, the background write is split after being placed in a channel queue. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example block diagram of an SSD coupled to a host device via a bus, according to some embodiments.

[0011] [Figure 2] FIG. 1 is a diagram of a background write that delays a read command, as occurs in the prior art.

[0012] [Figure 3A]FIG. 10 is an example diagram of how the mechanisms described herein can split background writes to improve read command latency, and reassemble split background writes if they do not need to be split, according to some embodiments. [Figure 3B] FIG. 10 is an example diagram of how the mechanisms described herein can split background writes to improve read command latency, and reassemble split background writes if they do not need to be split, according to some embodiments. [Figure 3C] FIG. 10 is an example diagram of how the mechanisms described herein can split background writes to improve read command latency, and reassemble split background writes if they do not need to be split, according to some embodiments.

[0013] [Figure 4] FIG. 10 illustrates an example process for splitting background writes as they are received, according to some embodiments.

[0014] [Figure 5] FIG. 1 illustrates an example process for splitting background writes already in queue for transmission to physical media in an SSD, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] According to some embodiments, a mechanism (which may include a system, a method, and a medium) is provided for improving read command processing time in a solid-state drive (SSD).

[0016] In some embodiments, when it is detected that the SSD has entered a pure read workload type (which, in some embodiments, may include a pure read low queue depth workload type), the mechanisms described herein may split background writes into smaller background writes. As a result, when a subsequent read command is received and one of the smaller background writes is being sent to the SSD's physical medium, the read command does not need to wait for the larger, unsplit-up background write to be sent, but instead needs to wait for the smaller background write to be sent.

[0017] As used herein, an "original background write" refers to a background write in its original form before it was split; a "split background write" refers to a background write that results from splitting an original background write; and an "unsplit background write" refers to a background write that results from recombining any two or more split background writes, which can be the same size as or different from the corresponding original background write.

[0018] Referring to FIG. 1, an exemplary block diagram of a solid-state drive 102 coupled to a host device 124 via a bus 132 is shown, according to some embodiments.

[0019] As shown, in some embodiments, solid-state drive 102 may include a controller 104, physical media (e.g., NAND devices) 106, 108, and 110, channels 112, 114, and 116, random access memory (RAM) 118, firmware 120, and cache 122. In some embodiments, more or fewer components may be included than those shown in Figure 1. In some embodiments, two or more of the components shown in Figure 1 may be included in one component.

[0020] In some embodiments, controller 104 may be any suitable controller for a solid-state drive. In some embodiments, controller 104 may include any suitable hardware processor (e.g., a microprocessor, a digital signal processor, a microcontroller, a programmable gate array, etc.). In some embodiments, controller 104 may include any suitable memory (e.g., RAM, firmware, cache, buffers, latches, etc.), interface controllers, interface logic, drivers, etc. In some embodiments, controller 104 may be coupled to or include (as shown) channel queues 140, 142, and 144 for sending commands (which may include command data) to physical media 106, 108, and 110 via channels 140, 142, and 144, respectively.

[0021] In some embodiments, physical media 106, 108, and 110 may be any suitable physical media for storing information (which may include data, programs, and / or any other suitable information that may be stored in a solid-state drive). In some embodiments, for example, the physical media may be NAND devices.

[0022] In some embodiments, the physical media may include any suitable memory cells, hardware processors (e.g., microprocessors, digital signal processors, microcontrollers, programmable gate arrays, etc.), interface controllers, interface logic, drivers, etc. Although three physical media (106, 108, and 110) are shown in FIG. 1 , in some embodiments, any suitable number D of physical media (including only one) may be used. In some embodiments, any suitable type of physical media (e.g., single-level cell (SLC) NAND devices, multilevel cell (MLC) NAND devices, triple-level cell (TLC) NAND devices, quad-level cell (QLC) NAND devices, 3D NAND devices, etc.) may be used. In some embodiments, each physical medium may have any suitable size. Although physical media 106, 108, and 110 may be implemented using NAND devices, the devices may additionally or alternatively use any other suitable storage technology or technologies, such as NOR flash memory or any other suitable flash technology, phase change memory technology, and / or any other suitable non-volatile memory storage technology.

[0023] In some embodiments, channels 112, 114, and 116 may be any suitable mechanism for communicating information between controller 104 and physical media 106, 108, and 110. For example, in some embodiments, the channels may be implemented using conductors (lands) on a circuit board. Although three channels (112, 114, and 116) are shown in FIG. 1, in some embodiments, any suitable number C of channels may be used.

[0024] In some embodiments, random access memory (RAM) 118 may include any suitable type of RAM, such as, for example, dynamic RAM, static RAM, etc. In some embodiments, any suitable number of RAMs 118 may be included, and each RAM 118 may have any suitable size.

[0025] In some embodiments, firmware 120 may include any suitable combination of software and hardware. For example, in some embodiments, firmware 120 may include software programmed in any suitable programmable read only memory (PROM). In some embodiments, any suitable number of firmware 120 may be used, each having any suitable size.

[0026] In some embodiments, cache 122 may be any suitable device for temporarily storing information (which may include data and programs in some embodiments). In some embodiments, cache 122 may be implemented using any suitable type of device, such as RAM (e.g., static RAM, dynamic RAM, etc.). In some embodiments, any suitable number of caches 122 may be used, each having any suitable size.

[0027] In some embodiments, host device 124 may be any suitable device that accesses stored information. For example, in some embodiments, host device 124 may be a general-purpose computer, a special-purpose computer, a desktop computer, a laptop computer, a tablet computer, a server, a database, a router, a gateway, a switch, a mobile phone, a communication device, an entertainment system (e.g., an automobile entertainment system, a television, a set-top box, a music player, etc.), a navigation system, etc. Although only one host device 124 is shown in FIG. 1 , in some embodiments, any suitable number of host devices may be included.

[0028] In some embodiments, host device 124 may include workers 126, 128, and 130. Although three workers (126, 128, and 130) are shown in FIG. 1 , in some embodiments, any suitable number of workers W may be included. In some embodiments, at least two workers may be included. A worker may be any suitable hardware and / or software that reads and / or writes data from and / or to solid-state drive 102.

[0029] In some embodiments, bus 132 may be any suitable bus for communicating information (which may include data and / or programs in some embodiments. For example, in some embodiments, bus 132 may be a PCIE bus, a SATA bus, or any other suitable bus.

[0030] 2, an example of a pure read command waiting for a background write to be sent according to the prior art is illustrated. As shown, SSD controller 204 has a channel queue 205. At some point, a background write 242 of a given size begins sending across channel 212 to latch 240 of physical medium 206. After background write 242 begins sending, read command 244 must enter queue 205 and wait for the background write to finish sending before it can be sent to physical medium 206. For example, if the background write is 128 kB (or any other size), the read command will need to wait for all 128 kB (or other size) to be sent over the channel before the read command can be sent over the channel.

[0031] 3A-3C, an exemplary diagram of splitting and reassembling background writes (BGWs) is shown, according to some embodiments.

[0032] 3A , in some embodiments, when a pure read workload is detected and a read command is expected, the mechanisms described herein may split the original BGW into components of any suitable size. For example, as shown, in some embodiments, the original BGW may be split into a first split BGW 342 and another split BGW 346. Once formed, the first split BGW 342 may be sent to a latch 340 of the physical medium 306 via channel 312. While the first split BGW is being sent, the other split BGWs wait in a channel queue 305 of the controller 304.

[0033] In some embodiments, the original BGW that is split may be any suitable size, for example, in some embodiments, the original BGW that is split may be 128 kB.

[0034] In some embodiments, the split BGW may be any suitable size. For example, the split BGW may have a size equal to the minimum page write size for the physical medium (e.g., NAND device) to which the command is destined. More specifically, for example, if the minimum page write size for the physical medium (e.g., physical medium 306) to which the original BGW is destined is 16 kB, the original BGW may be split into a split BGW having 16 kB of data.

[0035] 3B, read command 348 is received after the original BGW has been split into first split BGW 342 and another split BGW 346, and the first split BGW has begun transmitting as described in connection with FIG. 3A. This read command is then moved to the front of queue 305 and becomes read command 350. Read command 350 still waits for first split BGW 342 to complete transmission before it can be sent to latch 340 of physical medium 306, but because the first split BGW is smaller than the original BGW, the read command only needs to wait a shorter period of time than it would if the original BGW had not been split.

[0036] 3C, in some embodiments, if the mechanism detects that the pure read workload is no longer valid, the newly arriving BGW may not be split, as shown by BGW 358, while already split BGWs 352 (being sent) and 356 (still in queue 305) remain in their current form. In some embodiments, if the mechanism detects that the pure read workload is no longer valid, any suitable number of already split BGWs may be combined together to form one or more unsplit BGWs.

[0037] Referring to FIG. 4, an example process 400 for splitting background writes (BGWs) as they are received is shown, according to some embodiments. This process may be performed on any suitable device. For example, in some embodiments, this process may be performed on a controller of an SSD (e.g., controller 104 of FIG. 1). In some embodiments, a different instance of this process may be performed for each physical medium i of the SSD (e.g., each NAND device 106, 108, and 110 on solid-state drive 102).

[0038] As shown, process 400 may begin by receiving an original BGW at 402. In some embodiments, any suitable original BGW may be received, and the BGW may be received in any suitable manner. For example, in some embodiments, the received original BGW may be a garbage collection / defragmentation BGW. As another example, in some embodiments, the BGW may be received from a garbage collection / defragmentation process running in controller 104 of FIG. 1. In some embodiments, process 400 may be modified, for example, by having steps rearranged, changed, added, and / or removed.

[0039] Next, at 404, process 400 may determine a workload type of the SSD. In some embodiments, this determination may be made in any suitable manner. For example, in some embodiments, this determination may be made by tracking all command types passing through the firmware per unit time before they are inserted into the physical media command queue, and a determination of the workload type may be made based on the distribution of command types per unit time (e.g., all commands are of type host read for 100 ms).

[0040] Next, at 406, process 400 may determine whether the workload type is a pure read workload type. If it is determined that the workload type is a pure read workload type, the process may branch to 408, where it selects a write size for the BGWs into which it was split. In some embodiments, any suitable size or sizes may be selected. For example, in some embodiments, all of the split BGWs may be of the same size, which may be equal to the size required to contain one page's worth of data. As another example, the original BGW may be split into two or more different sizes.

[0041] At 410, process 400 may split the original BGW into split BGWs of the sizes determined at 408. In some embodiments, this split may be performed in any suitable manner. For example, in some embodiments, this split may be performed by splitting the default write dispatch size of background writes (64 kB) into four separate 16 kB sized background writes.

[0042] After splitting the original BGW at 410 or determining that the workload is not a pure read workload 406, the split BGW (if coming from 410) or the original BGW (if coming from 406) may be inserted into a channel queue at 412. In some embodiments, the insertion may be to any suitable channel queue. In some embodiments, the insertion may be performed in any suitable manner. For example, in some embodiments, the insertion may be performed by separately sending the split background writes to the channel queue, or, if the workload is not a pure read workload, by sending background writes of the default write dispatch size to the channel queue.

[0043] Referring to FIG. 5, an example process 500 for splitting background writes (BGWs) in a channel queue (such as channel queue 305 described above in connection with FIGS. 3A-3C) is shown, according to some embodiments. This process may be performed on any suitable device. For example, in some embodiments, this process may be performed on a controller of an SSD (e.g., controller 104 of FIG. 1). In some embodiments, a different instance of this process may be performed for each physical medium i of the SSD (e.g., each physical medium 106, 108, and 110 on SSD 102). In some embodiments, process 500 may be modified, for example, by rearranging, changing, adding, and / or removing steps.

[0044] As shown, process 500 may begin at 502 by detecting a change in workload type. In some embodiments, detecting a change in workload type may be performed in any suitable manner. For example, in some embodiments, detecting a change in workload type may be performed by tracking all command types passing through the firmware per unit of time before they are inserted into the physical media command queue, and a determination of a change in workload type may be made based on the distribution of command types per unit of time (e.g., all commands are of type host read for 100 ms).

[0045] Next, at 504, process 500 may determine a workload type of the SSD. In some embodiments, this determination may be made in any suitable manner. For example, in some embodiments, this determination may be made by tracking all command types passing through the firmware per unit of time before they are inserted into the physical media command queue, and a determination of the workload type may be made based on the distribution of command types per unit of time (e.g., all commands are of type host read for 100 ms).

[0046] Next, at 506, process 500 may determine whether the workload type is a pure read workload. If it is determined that the workload type is a pure read workload, the process may branch to 508, where it selects a write size for the BGWs into which it has been split. In some embodiments, any suitable size or sizes may be selected. For example, in some embodiments, all of the split BGWs may be of the same size, which may be equal to the size required to contain one page's worth of data. As another example, the original BGW may be split into two or more different sizes.

[0047] At 510, process 500 may split the original BGW into split BGWs of the sizes determined at 508. In some embodiments, this splitting may be performed in any suitable manner. For example, in some embodiments, this splitting may be performed by splitting the default write dispatch size of the background write (64 kB) into four separate 16 kB sized background writes and sending them separately to the channel queue.

[0048] After splitting the original BGW at 510 or after determining at 506 that the workload is not a pure read workload, process 500 may end at 512.

[0049] In some embodiments, at least some of the above-described blocks of the processes of Figures 4 and 5 may be performed or executed in any order or sequence, including but not limited to the order and sequence shown in and described with respect to the figures. Also, in some embodiments, some of the above-described blocks of the processes of Figures 4 and 5 may be performed or executed substantially simultaneously or in parallel, where appropriate, to reduce latency and processing time. Additionally or alternatively, in some embodiments, some of the above-described blocks of the processes of Figures 4 and 5 may be omitted.

[0050] In some embodiments, any suitable computer-readable medium may be used to store instructions for performing the functions and / or processes described herein. For example, in some embodiments, the computer-readable medium may be transitory or non-transitory. For example, a non-transitory computer-readable medium may include a medium such as a non-transitory form of magnetic media (such as a hard disk, a floppy disk, and / or any other suitable magnetic medium), a non-transitory form of optical media (such as a compact disc, a digital video disc, a Blu-ray disc, and / or any other suitable optical medium), a non-transitory form of semiconductor media (such as flash memory, electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and / or any other suitable semiconductor medium), any suitable medium that is neither transitory in transmission nor lacks any appearance of permanence, and / or any suitable tangible medium. As another example, a transitory computer-readable medium may include signals on a network, in wires, in conductors, in optical fibers, in circuits, in any suitable medium that is transient in transmission and lacks any appearance of permanence, and / or in any suitable intangible medium.

[0051] As can be seen from the above description, new mechanisms (which may include systems, methods, and media) are provided for improving read command processing times in SSDs. These mechanisms improve read latency in pure read workloads by splitting background writes so that read commands can be sent to the SSD's physical media more quickly.

[0052] While the present invention has been described and illustrated in the foregoing exemplary embodiments, it will be understood that the present disclosure has been made by way of example only, and that numerous changes in the details of the implementation of the invention may be made without departing from the spirit and scope of the invention, which is limited only by the claims that follow. Features of the disclosed embodiments can be combined and rearranged in various ways.

Claims

1. memory; and at least: Determine a workload type of a solid-state drive (SSD); In response to determining that the workload type is a pure read workload type: determining at least one command size into which the original background write is split; splitting the background write into a plurality of split background writes, each having one of the determined at least one command size; at least one hardware processor collectively configured as Equipped with A system for improving read command processing time in an SSD.

2. 10. The system of claim 1, wherein the at least one command size constitutes one page of physical media of the SSD.

3. The system of claim 1 , wherein the at least one command size includes at least two different sizes.

4. The system of claim 1 , wherein the at least one hardware processor is also collectively configured to combine at least two or more split background writes.

5. The system of claim 1 , wherein the original background write is split before being placed in a channel queue.

6. The system of claim 1 , wherein the background write is split after being placed in a channel queue.

7. determining a workload type of a solid-state drive (SSD); In response to determining that the workload type is a pure read workload type: determining, using at least one hardware processor, at least one command size into which the original background write is to be split; and splitting the background write into a plurality of split background writes, each having one of the determined at least one command size; Equipped with A method for improving read command processing time in an SSD.

8. The method of claim 7 , wherein the at least one command size constitutes one page of physical media of the SSD.

9. The method of claim 7 , wherein the at least one command size includes at least two different sizes.

10. The method of claim 7 further comprising combining two or more split background writes.

11. The method of claim 7 , wherein the original background write is split before being placed in a channel queue.

12. The method of claim 7 , wherein the background write is split after being placed in a channel queue.

13. 1. A computer program product for improving read command processing time in a solid state drive (SSD), the computer program product comprising: A procedure for determining the workload type of the SSD; In response to determining that the workload type is a pure read workload type: determining at least one command size into which the original background write is split; and splitting the background write into a plurality of split background writes, each having one of the determined at least one command size; A computer program for executing

14. 14. The computer program product of claim 13, wherein the at least one command size constitutes one page of physical media of the SSD.

15. The computer program product of claim 13 , wherein the at least one command size includes at least two different sizes.

16. 14. The computer program product of claim 13, further causing the processor to perform the step of combining two or more split background writes.

17. The computer program product of claim 13 , wherein the original background write is split before being placed in a channel queue.

18. The computer program product of claim 13 , wherein the background write is split after being placed in a channel queue.

Images