Command queue conditioning method and storage device

Abstract

The application relates to the technical field of storage control, and discloses a command queue adjusting method and a storage device, which comprises the following steps: associating a plurality of backend physical units to a plurality of command scheduling queues respectively, and each backend physical unit corresponds to one command scheduling queue; configuring high and low water level thresholds for the plurality of command scheduling queues respectively; periodically collecting the current queue depth of the command scheduling queue; determining the state of each command scheduling queue according to the relationship between the current queue depth and the high and low water level thresholds; if any command scheduling queue is in a high water level congestion state, performing a contraction operation to reduce the front-end concurrent depth threshold; if the command scheduling queues exceeding a preset value are in a low water level idle state and no command scheduling queue is in a high water level congestion state, performing an expansion operation to increase the front-end concurrent depth threshold. Therefore, the management of the command queue is optimized, and the read-write speed and performance stability of the storage device are improved.

Description

Technical Field

[0001] This application relates to the field of storage control technology, and in particular to a command queue adjustment method and storage device. Background Technology

[0002] Storage devices, such as Universal Flash Storage (UFS) and Solid State Drives (SSDs), perform data read and write operations by executing commands from the host.

[0003] In the UFS protocol, the host sends read and write commands to the UFS via a command queue. The UFS internally contains multiple Logical Units (LUNs), each capable of independently responding to host commands. Write commands sent by the host carry the data to be written. Upon receiving the data, the UFS first temporarily stores it in a buffer, and then writes the data to the memory module through backend programming. Read commands are initiated by the host; the UFS reads the data from the memory module and returns it to the host.

[0004] In an SSD running the NVMe protocol, the host creates a Submission Queue (SQ) and a Completion Queue (CQ). The host notifies the SSD of new commands by updating the Doorbell register of the Submission Queue. The SSD controller retrieves the commands from the Submission Queue, executes them, and writes the results to the Completion Queue upon completion.

[0005] To improve read and write speeds, storage devices typically allow a certain number of commands to be processed simultaneously within the device, maintaining a certain command concurrency depth. Effective queue management of these concurrent commands is crucial for improving the overall performance of the storage device. However, current technologies still suffer from issues such as significant response latency and insufficient performance stability when handling command queues.

[0006] Therefore, how to effectively manage the command queue of storage devices, especially how to adjust the concurrency of front-end commands according to the actual processing status of the back-end, is a problem that researchers in this field are studying. Summary of the Invention

[0007] Based on this, it is necessary to propose a command queue adjustment method and storage device to address the problems of existing command queue management technology.

[0008] In a first aspect, a command queue adjustment method is provided, applied to a storage device including a controller and a memory module. The storage device includes a controller and a memory module, the controller including a buffer memory. The method includes: associating multiple back-end physical units at the back end of the storage device with multiple command scheduling queues; associating the multiple back-end physical units with the multiple command scheduling queues respectively, with each back-end physical unit corresponding to at least one command scheduling queue; configuring high and low water level thresholds for each of the multiple command scheduling queues; periodically collecting a current queue depth of the multiple command scheduling queues; and determining the current queue depth of each of the multiple command scheduling queues based on the relationship between the current queue depth and the high and low water level thresholds. The system is configured to handle a high-water level congestion state, a normal water level state, or a low-water level idle state. The determination results are aggregated into a global state snapshot. Based on the global state snapshot, a front-end concurrency depth threshold of the storage device is dynamically adjusted, where the front-end concurrency depth threshold limits the maximum number of commands processed at the back end of the storage device. If the global state snapshot reflects that any command scheduling queue is in a high-water level congestion state, a shrinking operation is performed to lower the front-end concurrency depth threshold. If the global state snapshot reflects that more than a preset number of command scheduling queues are in a low-water level idle state and no command scheduling queues are in a high-water level congestion state, an expanding operation is performed to increase the front-end concurrency depth threshold.

[0009] Secondly, a storage device is provided, the device comprising: a connection interface for electrically connecting to a host; a memory module including multiple back-end physical units, wherein when the storage device is a UFS, the back-end physical units are logic units, and when the storage device is an SSD, the back-end physical units are channels; and a controller including error checking and correction circuitry, a buffer memory, and control circuitry, the controller being electrically connected to the connection interface and the memory module; wherein the control circuitry is configured to: associate the multiple back-end physical units of the storage device with multiple command scheduling queues, associate the multiple back-end physical units with the multiple command scheduling queues respectively, and each back-end physical unit corresponds to at least one command scheduling queue; configure a high-level and a low-level threshold for each of the multiple command scheduling queues; and periodically collect multiple... The current queue depth of each command scheduling queue is determined; based on the relationship between the current queue depth and high / low water level thresholds, each command scheduling queue is determined to be in a high-water level congested state, a normal water level state, or a low-water level idle state; the determination results are aggregated into a global state snapshot, and based on the global state snapshot, a front-end concurrency depth threshold of the storage device is dynamically adjusted, wherein the front-end concurrency depth threshold is used to limit the upper limit of the number of commands processed at the back end of the storage device; if the global state snapshot reflects that any command scheduling queue is in a high-water level congested state, a shrinking operation is performed to reduce the front-end concurrency depth threshold; and if the global state snapshot reflects that more than a preset value of command scheduling queues are in a low-water level idle state and no command scheduling queues are in a high-water level congested state, an expanding operation is performed to increase the front-end concurrency depth threshold.

[0010] The beneficial effects of this application are as follows: By periodically collecting the water level status of each command scheduling queue in the backend and aggregating it into a global state snapshot, the frontend concurrency depth threshold is dynamically adjusted accordingly, so that the command concurrency is dynamically matched with the actual processing capacity of the backend. When local congestion occurs in the backend, the command window is actively shrunk, and when the overall backend is idle, the window is appropriately expanded, thereby optimizing the management of the command queue and improving the read and write speed and performance stability of the storage device. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of a data storage system shown in one embodiment of this application; Figure 2This is a schematic diagram of the general architecture of the controller shown in one embodiment of this application; Figure 3 This is a schematic diagram of a UFS controller shown in one embodiment of this application; Figure 4 This is a schematic diagram of a solid-state drive controller according to an embodiment of this application; Figure 5 This is a schematic diagram of a memory management module shown in one embodiment of this application; Figure 6 This is a general flowchart of a command queue adjustment method shown in an embodiment of this application; Figure 7 This is a flowchart illustrating the command scheduling queue water level status determination in one embodiment of this application; Figure 8 This is a flowchart illustrating a threshold adjustment decision based on a global state snapshot, as shown in one embodiment of this application. Figure 9 This is a flowchart illustrating the determination of the contraction step size based on operational attributes, as shown in one embodiment of this application. Figure 10 This is a flowchart illustrating global congestion prevention and back-end operation suppression in one embodiment of this application; Figure 11 This is a flowchart illustrating water level gradient load balancing and write command redirection in one embodiment of this application; Figure 12 This is a flowchart illustrating the read / write concurrency threshold-linked freezing and orderly recovery process in one embodiment of this application; Figure 13 This is a flowchart illustrating the priority quota calculation and health adjustment process in one embodiment of this application; Figure 14 This is a flowchart illustrating the read / write quota lending mechanism and SLC folding detection process in one embodiment of this application; Figure 15 This is a flowchart illustrating a two-dimensional command hunger detection and processing method according to an embodiment of this application. Detailed Implementation

[0013] Reference will now be made in detail to exemplary embodiments of this application, examples of which are illustrated in the accompanying drawings. Wherever possible, the same element symbols are used in the drawings and description to denote the same or similar parts.

[0014] Figure 1 This is a schematic diagram of a data storage system according to an embodiment of this application. Please refer to... Figure 1The data storage system 10 includes a host 11 and a storage device 12. The storage device 12 can be connected to the host 11 and can be used to store data from the host 11. For example, the host 11 can be a smartphone, tablet computer, laptop computer, desktop computer, industrial computer, automotive infotainment system, advanced driver assistance system (ADAS), game console, server, or computer system installed in a specific carrier (e.g., vehicle, aircraft, or ship), and the type of host 11 is not limited to these. Furthermore, the storage device 12 can include a solid-state drive (SSD), universal flash storage (UFS), embedded multi-media card (eMMC), USB flash drive, memory card, or other types of non-volatile storage devices. It is particularly suitable for fields with stringent requirements for reliability, data integrity, environmental tolerance, and long-term stability, such as industrial control, edge computing, and automotive electronics.

[0015] Storage device 12 includes a connection interface 121, a memory module 122, and a controller 123. The connection interface 121 is used to connect storage device 12 to host 11. For example, connection interface 121 may support embedded multimedia cards, Universal Flash Storage (UFS), Peripheral Component Interconnect Express (PCIE), Non-Volatile Memory Express (NVME), Serial Advanced Technology Attachment (SATA), Universal Serial Bus (USB), or other types of connection interface standards. Therefore, storage device 12 can communicate with host 11 (e.g., exchange signals, instructions, and / or data) via connection interface 121.

[0016] Memory module 122 is used to store data. For example, memory module 122 may include one or more rewritable non-volatile memory modules. Each rewritable non-volatile memory module may include one or more memory cell arrays. The memory cells in the memory cell array store data in the form of voltage (also known as threshold voltage). For example, memory module 122 may include a Single Level Cell (SLC) NAND flash memory module, a Multi Level Cell (MLC) NAND flash memory module, a Triple Level Cell (TLC) NAND flash memory module, a Quad Level Cell (QLC) NAND flash memory module, and / or other memory modules with the same or similar characteristics. In one embodiment, the memory module 122 may be a specially screened and tested multi-level memory cell (MLC, TLC, QLC and PLC) flash memory module to meet the requirements of wide operating temperature (e.g. -40°C to 105°C or higher), high durability and data retention.

[0017] Controller 123 is connected to connection interface 121 and memory module 122. Controller 123 can be considered the control core of storage device 12 and used to control storage device 12. For example, controller 123 can be used to control or manage the overall or partial operation of storage device 12. For example, controller 123 may include a central processing unit (CPU), or other programmable general-purpose or special-purpose microprocessor, digital signal processor (DSP), programmable controller, application-specific integrated circuit (ASIC), programmable logic device (PLD), or other similar device or combination of these devices. In one embodiment, controller 123 may include a flash controller. In particular, for automotive functional safety requirements, the architecture of controller 123 may include safety islands, dual-core lockstep, or other redundancy and monitoring mechanisms to ensure the reliability of the control logic.

[0018] The controller 123 can send instruction sequences to the memory module 122 to access the memory module 122. For example, the controller 123 can send a write instruction sequence to the memory module 122 to instruct the memory module 122 to store data in a specific memory cell. For example, the controller 123 can send a read instruction sequence to the memory module 122 to instruct the memory module 122 to read data from a specific memory cell. For example, the controller 123 can send an erase instruction sequence to the memory module 122 to instruct the memory module 122 to erase the data stored in a specific memory cell. Furthermore, the controller 123 can also send other types of instruction sequences to the memory module 122 to instruct the memory module 122 to perform other types of operations, which are not limited in this application. The memory module 122 can receive instruction sequences from the controller 123 and access its internal memory cells according to these instruction sequences.

[0019] Figure 2 This is a schematic diagram of the general architecture of the controller shown in one embodiment of this application. Please refer to... Figure 1 and Figure 2 The controller 123 includes a host interface 21, a memory interface 22, and a control circuit 23. The host interface 21 is used to connect to the host 11 via the connection interface 121 for communication with the host 11. The memory interface 22 is used to connect to the memory module 122 for accessing the memory module 122.

[0020] Control circuitry 23 is connected to host interface 21 and memory interface 22. Control circuitry 23 can be used to control or manage the overall or partial operation of controller 123. For example, control circuitry 23 can communicate with host 11 via host interface 21 and access memory module 122 via memory interface 22. For example, control circuitry 23 may include control circuitry such as embedded controllers or microcontrollers. In the following embodiments, the description of control circuitry 23 is equivalent to the description of controller 123.

[0021] In one embodiment, the controller 123 may further include a buffer memory 24. The buffer memory 24 is connected to the control circuitry 23 and is used to cache data. For example, the buffer memory 24 may be used to cache instructions from the host 11, data from the host 11, and / or data from the memory module 122. To ensure the reliability and consistency of the mapping table data in the event of a power failure or other unforeseen circumstances, the buffer memory 24 may employ a storage medium with power loss protection (PLP) or incorporate a backup capacitor design to ensure that critical metadata has sufficient time to be written into the memory module 122.

[0022] In one embodiment, the controller 123 may further include an error checking and correction circuit 25. The error checking and correction circuit 25 is connected to the control circuit 23 and is used to encode and decode data to ensure data integrity. For example, the error checking and correction circuit 25 may support various encoding / decoding algorithms such as Low Density Parity Check code (LDPC code), BCH code, Reed-solomon code (RS code), and Exclusive OR (XOR) code.

[0023] In one embodiment, the controller 123 may also include other types of various circuit modules (such as power management circuits, etc.), which are not limited in this application.

[0024] In one embodiment, the controller 123 may further include a power management circuit 26. The power management circuit 26 is connected to the control circuit 23 and is used to control the power supply of the storage device 12. The power management circuit 26 not only manages conventional power consumption, but also meets the complex power sequences and low static power consumption requirements of automotive electronics, and can handle voltage fluctuations during vehicle start-stop processes, ensuring that the storage device 12 operates stably in harsh power environments.

[0025] Figure 2 This application demonstrates the general architecture of its controller, which is applicable to various storage device types, including eMMC, SD cards, UFS, and SSDs. The following... Figure 3 and Figure 4 Specific implementation variations for UFS and SSD devices will be described separately, with a focus on the protocol processing module closely related to the front-end queue adjustment method of this application.

[0026] Figure 3 This is a schematic diagram of a UFS controller according to an embodiment of this application. Please refer to... Figure 1 and Figure 3 When storage device 12 is a general purpose flash storage (UFS) device, its controller 123A includes a host interface 21, a memory interface 22, control circuitry 23, and a UTP protocol engine 27. It is understood that... Figure 3 The UFS controller 123A shown includes Figure 2 For the sake of brevity, all functional modules described in the general architecture (such as buffer memory 24, error checking and correction circuit 25, and power management circuit 26) are omitted. Figure 3 The document focuses on demonstrating modules directly related to UFS protocol processing and the methods described in this application.

[0027] The host interface 21 is used to connect to the host 11 via the connection interface 121 for communication with the host 11. In one embodiment, the host interface 21 is an M-PHY (M-type Physical Layer) interface to support physical layer communication between the UFS device and the host 11. The memory interface 22 is used to connect to the memory module 122 to access multiple logical units (LUNs) in the memory module 122.

[0028] The UTP protocol engine 27 is connected between the host interface 21 and the control circuit 23 to process data packets and commands from the UFS Transport Protocol (UTP) layer. In the UFS protocol, the UTP layer is responsible for receiving and distributing commands from the host 11 and transmitting them to the control circuit 23 for further processing, while also managing the command transmission rhythm between the host 11 and the storage device 12.

[0029] The virtual pass-through threshold proposed in this solution is implemented by the UTP protocol engine 27 in its command extraction logic unit. This virtual pass-through threshold is the specific implementation of the aforementioned front-end concurrency depth threshold in the UTP protocol engine 27; both have the same value and are used to limit the total number of active commands simultaneously flying in the back-end. Different logic units are configured with different initial virtual pass-through threshold values ​​based on their storage attributes. The initial virtual pass-through threshold value of logic units configured as enhanced storage areas is higher than that of logic units in ordinary storage areas.

[0030] Specifically, the UTP protocol engine 27 maintains an active command counter, and the control circuit 23 is responsible for dynamically calculating and setting the virtual pass threshold. When the active command count reaches the virtual pass threshold, the UTP protocol engine 27 temporarily suspends the extraction of new command transmission requests from the host 11, resulting in the inability to release the credit in the receive buffer in a timely manner. This naturally generates back pressure on the host 11 through the UFS interconnect (UniPro) layer and the M-PHY interface. The aforementioned UFS interconnect layer, namely the UniPro (Unified Protocol) layer, is located between the UTP layer and the M-PHY layer and is responsible for providing a reliable data transmission link. Each logical unit maintains its own command scheduling queue. The metadata of this queue (including the current queue depth, high / low water level thresholds, and average processing latency) is periodically collected by the control circuit 23 and transmitted back to the control circuit 23 to dynamically update the virtual pass threshold inside the UTP protocol engine 27, forming a closed-loop regulation loop.

[0031] It should be noted that the current free buffer memory capacity in this scheme refers to the amount of unoccupied available space in buffer memory 24. This capacity value is monitored in real time by control circuit 23 and used to dynamically adjust the minimum threshold value of the shrinkage operation.

[0032] Figure 4 This is a schematic diagram of a solid-state drive controller according to an embodiment of this application. Please refer to... Figure 1 and Figure 4 When the storage device 12 is a solid-state drive (SSD), its controller 123B includes a host interface 21, a memory interface 22, a control circuit 23, and a front-end protocol core 28. It is understandable that... Figure 4 The SSD controller 123B shown includes Figure 2 For the sake of brevity, all functional modules described in the general architecture (such as buffer memory 24, error checking and correction circuit 25, and power management circuit 26) are omitted. Figure 4 The document focuses on demonstrating modules directly related to NVMe protocol processing and the methods described in this application.

[0033] Host interface 21 is used to connect to host 11 via connection interface 121 for communication with host 11. In one embodiment, host interface 21 is a Peripheral Component Interconnect Express (PCIe) physical layer interface to support the Non-Volatile Memory Express (NVMe) protocol. Memory interface 22 is used to connect to memory module 122 to access multiple flash memory channels (CH) in memory module 122.

[0034] The front-end protocol core 28 connects the host interface 21 and the control circuit 23 to handle command and data interaction in the NVMe protocol. The front-end protocol core 28 includes a submission queue management unit, an active command counter, and a doorbell notification control logic unit. Specifically, in the NVMe protocol architecture, the host 11 notifies the device of new commands by updating the doorbell register at the tail of the Submission Queue (SQ). The front-end concurrency depth threshold proposed in this solution is specifically executed by the submission queue management unit within the front-end protocol core 28. This management unit maintains an active command counter and a dynamic upper limit value written by the control circuit 23 for each submission queue.

[0035] For any given channel, when the channel enters an internal busy state due to garbage collection, the dynamic upper limit is automatically reduced by a preset percentage. If the active command counter of the submission queue corresponding to the channel is higher than the reduced dynamic upper limit, the extraction of new commands from the submission queue is suspended, so as to form back pressure using the doorbell mechanism on the host 11 side. When the channel exits the internal busy state, the original dynamic upper limit is restored.

[0036] Control circuit 23 calculates the dynamic upper limit based on the global state snapshot and writes it into the front-end protocol core 28. When the active command counter inside the front-end protocol core 28 reaches this dynamic upper limit, the doorbell notification control logic unit of the front-end protocol core 28 will temporarily suspend the processing of the doorbell event in the corresponding submission queue, so that the new command remains in the memory submission queue on the host side. The suspended doorbell event will be processed by the doorbell notification control logic unit of the front-end protocol core 28 after the subsequent command is completed and the active command count decreases. In this way, the unretrieved commands will automatically remain in the submission queue on the host side, and the host 11 will not be able to submit more commands because it has not received a completion response, forming a closed-loop backpressure.

[0037] The control circuit 23 can integrate multiple processor cores to run front-end protocol processing and back-end flash channel management tasks respectively. Specifically, the control circuit 23 monitors the command completion rate based on the queue metadata and command completion rate returned by each back-end flash channel, calculates a new dynamic upper limit for each submission queue, and updates it to the front-end protocol core 28. When a continuous decline in the command completion rate is detected, even if the water level snapshot does not show congestion, a proactive contraction is still triggered to prevent write cache overflow.

[0038] In one embodiment, to address the issue of timestamp asynchrony among multiple cores, each processor core within the control circuit 23 shares a Global Time Counter (GTC) as a reference for cross-core time synchronization, and transmits the hardware timestamps of each flash memory channel to the front-end protocol core running this method to ensure the consistency of timestamps for delay calculation.

[0039] In one embodiment, the buffer memory 24 includes a write cache area for temporarily storing user data to be written to the storage module 122. The continuously monitored command completion rate in this scheme is used to indirectly sense changes in the pressure on the write cache. If the command completion rate continuously decreases, it indicates that the backend flash channel may experience a decrease in processing capacity due to internal operations such as garbage collection (GC), and there is a risk of write cache overflow. In this case, even if the water level snapshot does not show congestion, the controller 123B will still perform a shrinking operation to prevent write cache overflow.

[0040] Figure 5 This is a schematic diagram of a memory management module according to an embodiment of this application. Please refer to... Figure 5 The memory module 122 includes multiple physical units 501(0)-501(B). Each physical unit includes multiple storage cells for non-volatile data storage.

[0041] In one embodiment, an entity unit may include an entity programming unit. In one embodiment, an entity programming unit is also referred to as an entity programming unit. In one embodiment, an entity programming unit may be considered as an entity page.

[0042] In one embodiment, an entity programming unit may include multiple entity sectors. For example, the data capacity of an entity sector may be 512 bytes (B), and an entity programming unit may include 32 entity sectors. However, the data capacity of an entity sector and / or the total number of entity sectors included in an entity programming unit can be adjusted according to practical needs, and this application is not limited thereto. For example, the storage capacity of an entity programming unit may be 16 kilobytes, and this application is not limited thereto.

[0043] In one embodiment, a physical programming unit is the smallest unit of synchronously written data in memory module 122. For example, when performing a programming operation (also called a write operation) on a physical programming unit to write data to that physical programming unit, multiple memory cells in that physical programming unit can be synchronously programmed to store the corresponding data. For example, when programming a physical programming unit, a write voltage can be applied to that physical programming unit to change the threshold voltage of at least some of the memory cells in that physical programming unit. For example, the threshold voltage of a memory cell may reflect the bit data stored in that memory cell.

[0044] In one embodiment, an entity erasure unit may include multiple entity programmable units. In another embodiment, an entity erasure unit may be considered as an entity block.

[0045] In one embodiment, multiple programmed units in a physical erase unit can be erased simultaneously. For example, when performing an erase operation on a physical erase unit, an erase voltage can be applied to multiple programmed units in this physical erase unit to change the threshold voltage of at least some of the memory cells in these programmed units. By performing an erase operation on a physical erase unit, the data stored in this physical erase unit can be erased.

[0046] In one embodiment, the memory module 122 includes multiple planes, each plane includes multiple blocks, and each block includes multiple pages. The control circuit 23 performs multi-plane operations as needed, which means that multiple planes in the memory module 122 can perform the same type of operation (such as reading or programming) in parallel to improve command processing efficiency.

[0047] In one embodiment, the control circuit 23 can logically associate entity units 501(0)-501(A) and 501(A+1)-501(B) with the data area 51 and the idle area 52, respectively. Entity units 501(0)-501(A) in the data area 51 all store data (also referred to as user data) from the host 11. For example, any entity unit in the data area 51 can store valid data and / or invalid data. In addition, entity units 301(A+1)-301(B) in the idle area 52 do not store any data (e.g., valid data).

[0048] In one embodiment, if a physical unit does not store valid data, this physical unit can be associated with the free area 52. Furthermore, physical units in the free area 52 can be erased to clear the data within them. In one embodiment, physical units in the free area 52 are also referred to as idle physical units. In one embodiment, the free area 52 is also referred to as the free pool.

[0049] In one embodiment, in response to the requirements of predictable storage lifetime for industrial and automotive applications, the control circuit 23 can implement wear leveling and bad block management strategies, and monitor the number of erase / write cycles, read counts, and data retention time of each physical unit in real time, so as to provide the host 11 with a health status report and remaining lifetime prediction of the storage device 12, thereby meeting the diagnostic coverage requirements of relevant functional safety standards.

[0050] In one embodiment, when data needs to be stored, the control circuit 23 can select one or more physical units from the idle area 52 and instruct the memory module 122 to store the data into the selected physical units. After the data is stored into this physical unit, this physical unit can be associated with the data area 51. In other words, one or more physical units can be used cyclically between the data area 51 and the idle area 52.

[0051] In one embodiment, the control circuit 23 may be configured with multiple logic units 502(0)-502(C) to map entity units (i.e., entity units 501(0)-501(A)) in the data area 51. For example, a logic unit may correspond to a logical block address (LBA) or other logical management unit. A logic unit may be mapped to one or more entity units.

[0052] In one embodiment, if a certain entity unit is currently mapped by any logic unit, the control circuit 23 can determine that the data currently stored in this entity unit includes valid data. Conversely, if a certain entity unit is not currently mapped by any logic unit, the control circuit 23 can determine that this entity unit does not currently store any valid data.

[0053] In one embodiment, the control circuit 23 may record the mapping relationship between logical units and physical units in at least one management table (also known as a logical-to-physical (L2P) table). In one embodiment, the control circuit 23 may instruct the memory module 122 to perform data read, write, or erase operations based on the information in this management table (i.e., the logical address to physical address mapping table). In one embodiment, the mapping table update operation is the operation of writing the logical-to-physical address mapping table back from the buffer memory 24 to the memory module 122.

[0054] Figure 6 This is a general flowchart of a command queue adjustment method shown in an embodiment of this application. The method is applied to a storage device 12 including a memory module 122. A control circuit 23 is configured to execute this method. The method begins at step S601: S601: Associate multiple back-end physical units with multiple command queues (CQs) respectively, and each back-end physical unit corresponds to at least one command queue. The back-end physical unit is a physical or logical organization unit within the storage device 12 used for parallel command processing. For example, when the storage device is UFS, the back-end physical unit consists of multiple logical units (LUNs), and its controller is... Figure 3 The UFS controller 123A shown, along with the UTP protocol engine 27 and control circuit 23, works in conjunction to achieve front-end regulation through a virtual pass-through threshold within the UTP protocol engine 27. When the storage device 12 is an SSD, the back-end physical unit has multiple channels, and its controller is... Figure 4The SSD controller 123B shown has a front-end protocol core 28 that works in conjunction with the control circuit 23. The front-end controller monitors the doorbell register through the submission queue management unit inside the front-end protocol core 28 to achieve front-end adjustment, and performs non-uniform current limiting according to the weight value of each channel.

[0055] The aforementioned relationships are established by the firmware of controller 123 during the initialization phase, typically manifested as a one-to-one mapping, meaning each backend physical unit has its own dedicated command scheduling queue to avoid head-of-line congestion. However, under certain load characteristics, multiple backend physical units with lower access pressure can also be mapped to the same command scheduling queue. Each command scheduling queue is maintained in buffer memory 24 as a circular buffer or linked list structure to temporarily store command descriptors to be processed by that backend physical unit in sequence.

[0056] S602: Configure a high water level threshold and a low water level threshold for the above multiple command scheduling queues respectively.

[0057] The high-water mark threshold represents the critical depth at which the queue begins to face congestion risk, while the low-water mark threshold represents the critical depth at which the queue is in a relatively idle state. These thresholds can be fixed values ​​preset by the firmware or dynamically adjusted during operation based on the processing speed of the backend physical units. For example, for backend physical units with faster processing speeds (such as flash channels using multi-plane operations), the high-water mark threshold can be configured relatively high to fully utilize their processing capacity; for backend physical units with slower processing speeds or those currently busy with garbage collection, the high-water mark threshold should be configured relatively low to trigger flow control earlier.

[0058] In a specific example, storage device 12 is a UFS 3.1 compliant storage device containing two back-end physical units. Each physical unit is allocated a command scheduling queue, for a total of two queues. The maximum depth of each command scheduling queue is configured to 32. In this case, the high-water mark threshold can be configured to 24 (75% of the maximum depth), and the low-water mark threshold can be configured to 8 (25% of the maximum depth).

[0059] S603: Periodically collect the current queue depth of the above multiple command scheduling queues.

[0060] The acquisition period can be set to a fixed time interval, such as triggering acquisition every 500 microseconds, or it can be associated with a specific event, such as triggering acquisition after a certain number of commands have been processed. The current queue depth refers to the total number of commands backed up in the command scheduling queue at a certain moment, waiting to be extracted and processed by the backend physical unit. This acquisition action is executed by the control circuit 23, specifically through a timer interrupt service routine or a hook function in the backend command completion interrupt service routine. The acquired queue depth values ​​are temporarily stored in a global state array maintained by the control circuit 23 in the buffer memory 24 for use by subsequent decision logic.

[0061] S604: Based on the relationship between the current queue depth and the high and low water level thresholds, determine that each of the multiple command scheduling queues is in a high water level congestion state, a normal water level state, or a low water level idle state.

[0062] Figure 7 This is a flowchart illustrating the command scheduling queue water level status determination in one embodiment of this application, corresponding to the water level status determination logic of a single command scheduling queue by control circuit 23 in step S604. Control circuit 23 first obtains the current queue depth (Queue Depth, QD) of the queue and compares it with the high water level threshold. If QD reaches or exceeds the high water level threshold, it is directly determined to be in a high water level congestion state; otherwise, it continues to compare with the low water level threshold. If QD is lower than or equal to the low water level threshold, it is determined to be in a low water level idle state; if QD is between the high and low water level thresholds, it is determined to be in a normal water level state. This determination process is embodied in a simple comparison logic, polling the status of each command scheduling queue and encoding the result as a status value (e.g., 0 represents low water level idle, 1 represents normal water level, and 2 represents high water level congestion) and writing it to the corresponding position in the global status snapshot for global decision-making. The high water level threshold is greater than the low water level threshold. The aforementioned global state snapshot refers to the set of water level status codes of all command scheduling queues in storage device 12 at a certain acquisition time, which is used to reflect the overall health of the concurrent processing in the backend of storage device 12.

[0063] S605: Aggregate the determination results into a global state snapshot, and dynamically adjust a front-end concurrency depth threshold (FCDT) of the storage device 12 based on this global state snapshot.

[0064] A global state snapshot is a collection of the states of all command scheduling queues within a specific acquisition period, reflecting the overall health of concurrent processing at the backend of storage device 12. This global state snapshot can be represented as a bitmap or a byte array, with a length equal to the number of command scheduling queues, and each element storing the state code of the corresponding queue. The frontend concurrency depth threshold is used to limit the upper limit of the number of commands processed at the backend of storage device 12, i.e., to limit the total number of active commands flying simultaneously at the backend.

[0065] S606: If the above global state snapshot reflects that any command scheduling queue is in the above high-water congestion state, then perform a shrinkage operation to reduce the above front-end concurrency depth threshold.

[0066] If any local congestion point exists in the backend, regardless of how idle other queues are, the control circuit 23 will determine that there is a bottleneck risk in the backend, actively shrink the frontend window, reduce the injection of new commands, and prevent congestion spread and write cache overflow. This shrinkage strategy is based on the "barrel effect" common in data storage system 10—overall performance depends on the slowest backend physical unit. Protecting this bottleneck unit buys time for the entire storage device 12 to digest the backlog.

[0067] S607: If the above global state snapshot reflects that more than a preset value of the command scheduling queue is in the above low water level idle state and no command scheduling queue is in the above high water level congested state, then perform an expansion operation to increase the aforementioned front-end concurrency depth threshold.

[0068] Specifically, control circuit 23 will only gradually expand the front-end window, allowing more commands to enter the back-end, under the premise that the overall back-end idleness is high (more than half of the queues are idle) and absolutely safe (no queue congestion), so as to make full use of the back-end's parallel processing capabilities and improve overall throughput. The step size of the expansion operation is usually fixed or related to the magnitude of the previous contraction to achieve symmetrical or asymmetrical recovery. For example, each expansion step size is fixed at 1 to achieve slow recovery and prevent instantaneous congestion caused by sudden traffic.

[0069] For example, in an NVMe SSD controller with 8 backend physical units (e.g., 8 channels), a command scheduling queue is allocated to each channel, and the maximum depth of each queue is set to 64. The high-water mark threshold is configured to 48 (75% of the maximum depth), and the low-water mark threshold is configured to 16 (25% of the maximum depth). The above preset values ​​are configured to 4 (half of the total number of queues). At this time, if the current depth of any queue is greater than or equal to 48, front-end concurrent depth shrinking is triggered; if more than 4 queues have a current depth less than or equal to 16 and there are no congested queues, front-end concurrent depth expansion is triggered; otherwise, the current concurrent threshold remains unchanged.

[0070] For example, in a UFS 3.1 storage device, there are 2 backend physical units, each allocated a command scheduling queue, and each queue has a maximum depth of 32. The high-water mark threshold is configured as 24, and the low-water mark threshold is configured as 8. The preset values ​​are configured as 1 (half of the total number of queues, 2). Under this configuration, if the current depth of any queue is greater than or equal to 24, a shrinking operation is immediately triggered to lower the front-end concurrency depth threshold; if the current depth of both queues is less than or equal to 8, meaning there are 2 queues in the low-water mark idle state, exceeding the preset value of 1, and there are no high-water mark congested queues, an expansion operation is triggered to increase the front-end concurrency depth threshold; if only one queue is in the low-water mark idle state, the expansion adjustment is not satisfied, and the current threshold remains unchanged.

[0071] Figure 8 This is a flowchart illustrating a threshold adjustment decision based on a global state snapshot, as shown in one embodiment of this application. Figure 8 As shown, after acquiring a global state snapshot, control circuit 23 first checks whether any command scheduling queue is in a high-water mark congested state. If so, regardless of the states of other queues, it immediately performs a contraction operation to lower the front-end concurrency depth threshold. If there are no congested queues, it further checks whether any command scheduling queue exceeding a preset value is in a low-water mark idle state; if so, it performs an expansion operation to raise the threshold; otherwise, it maintains the current threshold unchanged. This decision logic embodies the core control principle of contraction when there is congestion at a single point and expansion only when the overall system is idle.

[0072] Through the closed-loop control mechanism described in S601 to S607, this method establishes a dynamic balance between the inflow of front-end commands and the actual processing capacity of the back-end, solves the defects of lag and blindness caused by static thresholds or control based solely on front-end load, and improves the quality of service (QoS) and performance stability of storage device 12 in complex scenarios such as mixed read and write and pressure fluctuations.

[0073] The following detailed description of the implementation details of the above-mentioned shrinkage operation, expansion operation, and various optimization measures, with reference to specific embodiments, is further illustrated.

[0074] In one embodiment, the contraction operation further combines the degree of congestion with the operational attributes of the backend physical units to perform asymmetric contraction.

[0075] During the contraction operation, the operational attributes of the backend physical units associated with command scheduling queues in a high-water congestion state are obtained. These attributes include whether the backend physical units are performing slow operations. These slow operations include wipe operations or cross-page boundary programming operations. First, a base contraction step size is determined based on the congestion level. If any backend physical unit associated with a congested command scheduling queue is performing this slow operation, the base contraction step size is multiplied by a first multiplier factor (greater than 1) to obtain the final contraction step size. Otherwise, the base contraction step size is used as the final contraction step size. Finally, the frontend concurrency depth threshold is reduced by this final contraction step size.

[0076] The control circuit 23 maintains an operation state machine for each back-end physical unit. This state machine contains a field called current_operation, which can take values ​​such as IDLE, READ, PROGRAM, ERASE, and MULTI_PLANE_PROGRAM.

[0077] When current_operation is ERASE or MULTI_PLANE_PROGRAM (cross-page boundary programming requires operation on multiple pages, which takes a long time), the unit is considered to be performing a slow operation.

[0078] The congestion level value, `congestion_ratio`, is calculated as: current queue depth / high watermark threshold. The base shrinkage step size, `base_step`, is calculated as: `floor(congestion_ratio × step size coefficient)`, where the step size coefficient can be preset to 4.

[0079] If the associated physical unit is performing a slow operation, then multiply base_step by the first multiplier factor 1.8 to get final_step = floor(base_step × 1.8); otherwise, final_step = base_step.

[0080] Finally, frontend_threshold = max(min_threshold, frontend_threshold - final_step), where min_threshold is the minimum threshold value.

[0081] For example, if the high water level threshold is 40 and the queue depth is 52, then `congestion_ratio` = 1.3 and `base_step` = floor(1.3 × 4) = 5. If the channel is being erased, then `final_step` = floor(5 × 1.8) = 9, and `frontend_threshold` decreases from 32 to 23. If there is no slow operation, it only decreases by 5, becoming 27.

[0082] The rationale behind this approach is that when queues are congested, queue depth alone is insufficient to distinguish whether the congestion is caused by a brief surge in traffic or by prolonged blocking of backend physical units (such as erase operations that can last for milliseconds). By sensing the type of backend physical operation, once it is confirmed that the congestion is caused by a slow operation, the frontend is contracted in larger steps to quickly slow down the issuance of new commands, preventing the backend commands from accumulating and avoiding command timeouts and write cache overflows. This effectively reduces the long-tail latency of the storage device 12 caused by the inherent slow operations of the storage module 122.

[0083] Figure 9 This is a flowchart illustrating the determination of the contraction step size based on operational attributes, as shown in one embodiment of this application. Figure 9 As shown, when any command scheduling queue enters a high-water congestion state, the control circuit 23 first determines the basic shrinkage step size based on the ratio of the current queue depth to the high-water threshold; then it checks the operation attributes of the back-end physical unit associated with the queue. If a slow operation such as erasure or cross-page programming is being performed, the step size is increased by a multiplier factor greater than 1; otherwise, the basic step size is used directly. Finally, the front-end concurrency depth threshold is reduced by this final step size to achieve differentiated shrinkage that matches the back-end physical operation time.

[0084] In one embodiment, a preventative tightening and background operation suppression method based on global congestion metrics is also proposed.

[0085] This method calculates a global congestion metric, which is the ratio of the number of high-water congested queues to the total number of command scheduling queues. When the global congestion metric exceeds a global contraction threshold, regardless of whether there are any low-water idle queues among the command scheduling queues, the expansion operation is paused. Simultaneously, background operation suppression instructions are sent to all backend physical units associated with command scheduling queues in a high-water congestion state to reduce the execution rate of garbage collection or wear leveling operations within the backend physical units. Then, depending on the degree to which the global congestion metric exceeds the global contraction threshold, the method chooses to maintain the frontend concurrency depth threshold at its current value or perform additional contraction. Additional contraction involves reducing the frontend concurrency depth threshold by a preset fixed step size.

[0086] In an example SSD, there are 8 backend physical units (channels). Specifically, the global congestion index is calculated as: global_congestion_index = number of congested queues / total number of queues. The global congestion threshold is set to 0.4 (i.e., 4 out of the 8 queues are congested).

[0087] When global_congestion_index > 0.4, firstly, the suppression flag suppress_gc = TRUE is set, and reduction instructions are sent to all physical units associated with the congestion queue. For example, the number of blocks processed by each garbage collection (GC) thread is reduced to 1 / 4 of the original number, or the GC rollback wait time is increased, thereby reducing the preemption of the command processing bandwidth of the host 11 by the internal operations of the storage device 12.

[0088] Then, determine the degree of excess: if global_congestion_index exceeds the threshold but is less than 0.6, only keep frontend_threshold unchanged; if it is greater than or equal to 0.6, perform an additional contraction while maintaining the current value, with a fixed step size such as 10.

[0089] For example, if 5 out of 8 queues are congested, and global_congestion_index=0.625>0.6, then a GC suppression command is sent to these 5 channels, and frontend_threshold is further reduced by 10. This can quickly release backend resources to handle the backlog of host commands. Simultaneous congestion of multiple queues usually indicates that the overall background operations of storage device 12 (such as GC, wear leveling) are overly active. Simply pausing expansion or shrinking the frontend cannot eradicate the problem of resources being heavily consumed by the background. By actively sending suppression commands to physical units, the rate of background operations is directly reduced, releasing backend processing capacity from the source. Combined with additional shrinking, storage device 12 can quickly return to normal operation.

[0090] Figure 10 This is a flowchart illustrating global congestion prevention and back-end operation suppression in one embodiment of this application. Figure 10 As shown, when the proportion of queues in high-water congestion exceeds the global contraction threshold, not only is expansion paused, but instructions to reduce background operations are also sent to the backend physical unit to release the processing resources of the control circuit 23; and the threshold is maintained or further contracted according to the degree of exceedance of the indicators, so as to realize the graded response to global overload.

[0091] In one embodiment, the shrink operation allows the front-end concurrency depth threshold to be reduced to a minimum threshold value. This minimum threshold value is not a fixed value, but is dynamically set based on the proportion of dirty data written to buffer memory 24 but not yet programmed into memory module 122, and the write amplification effect factor. The higher the proportion of dirty data and the larger the write amplification effect factor, the lower the minimum threshold value, ensuring that a basic flush rate is maintained and avoiding write cache overflow. Dirty data refers to data written to buffer memory 24 but not yet programmed into memory module 122.

[0092] Specifically, the control circuit 23 continuously monitors the ratio of dirty_size to total write buffer capacity write_buffer_size in the buffer memory 24, as well as the write amplification factor (WAF), which is calculated by dividing the cumulative amount of data written to flash memory by the amount of data written by the host 11.

[0093] The formula for calculating the minimum threshold (min_threshold) is: min_threshold=max(Min_Absolute,Default_Min-floor(α×dirty_ratio×WAF)); Where Min_Absolute is the absolute lower bound, for example, 4; Default_Min is the default minimum threshold, for example, 10; α is the scaling factor, set to 5.

[0094] When dirty_ratio=0.8 and WAF=2.5, min_threshold=max(4,10-floor(5×0.8×2.5))=max(4,10-10)=4, the threshold can be reduced to 4.

[0095] When dirty_ratio=0.3 and WAF=1.2, min_threshold=max(4,10-floor(5×0.3×1.2))=max(4,10-1)=9.

[0096] Traditional fixed minimum thresholds may still limit flush speed under high dirty data pressure, leading to write cache overflow. This embodiment dynamically binds the minimum threshold to the proportion of dirty data and write amplification. The more dirty data and the heavier the write amplification (meaning greater backend programming pressure), the lower the threshold can be, thereby ensuring a sufficient flush rate and preventing data loss caused by write cache overflow.

[0097] In one embodiment, a method for introducing a cooling-off period to prevent adjustment oscillations is also proposed. A cooling-off period is set after performing a contraction or expansion operation. The length of this cooling-off period is dynamically set based on the magnitude of the change in the front-end concurrency depth threshold caused by the current contraction or expansion operation and the write amplification factor of the storage device 12 within the most recent time window. The greater the change and the higher the write amplification factor, the longer the cooling-off period. During the cooling-off period, even if the global state snapshot meets the corresponding contraction or expansion conditions, the contraction or expansion operation is not performed again.

[0098] In detail, the magnitude of change delta = |new threshold - old threshold|. The scaling factor WAF is the average of the most recent statistical period (e.g., 1 minute).

[0099] Cooldown period (unit: number of status acquisition cycles) calculation: cooldown_period = Base_Cooldown + floor(delta / Delta_Scale) + floor(WAF×WAF_Scale). Base_Cooldown is set to 3, Delta_Scale is set to 5, and WAF_Scale is set to 2.

[0100] For example, if the threshold is reduced from 32 to 20, delta=12, and WAF=2.0, then cooldown_period=3+floor(12 / 5)=3+2=5+floor(2.0×2)=4, for a total of 9 cycles.

[0101] Even if the snapshot meets the expansion conditions within 9 acquisition cycles, expansion is not performed. When write amplification is high, frequent data migration occurs within memory module 122, leading to drastic performance fluctuations and potentially causing repeated adjustments to the front-end threshold. By linking the cooling period to write amplification and adjustment magnitude, a longer stabilization period is provided on the heavily worn memory device 12, preventing performance jitter caused by frequent adjustments when the media condition is unstable, thus helping to protect the lifespan of memory module 122.

[0102] In one embodiment, a queue load balancing method based on water level gradients is also proposed. This method calculates the water level gradient between command scheduling queues, reflecting the degree of difference in the current queue depths of multiple command scheduling queues. When calculating the gradient, a first weight is assigned to the queue depth corresponding to a write command, and a second weight is assigned to the queue depth corresponding to a read command, with the first weight being greater than the second weight. When the water level gradient exceeds a preset gradient threshold, the command to be forwarded is redirected from the original first command scheduling queue to a second command scheduling queue, where the current queue depth of the second command scheduling queue is lower than that of the first command scheduling queue. When the command to be forwarded is a write command, the second command scheduling queue selects the candidate command scheduling queue with the highest remaining erase count for the associated backend physical unit from among those with a current queue depth lower than that of the first command scheduling queue.

[0103] The queue depth is divided into read depth (RD) and write depth (WD). The control circuit 23 counts rd_cnt and wd_cnt in the queue structure respectively.

[0104] Weighted depth weighted_depth=wd_cnt×Wd_Weight+rd_cnt×Rd_Weight, where Wd_Weight=3, Rd_Weight=1.

[0105] The water level gradient is calculated as max(weighted_depth) - min(weighted_depth). The preset gradient threshold is set to 15. When gradient > 15, a command to be forwarded is selected from the tail of the queue with the highest weighted depth (the first queue). If it is a read command, a random queue with a weighted depth lower than the first queue is selected as the target redirection. If it is a write command, the remaining erase counts of the associated physical units of all candidate queues with weighted depths lower than the first queue are obtained (read from the wear leveling module), and the queue with the most remaining erase counts is selected as the target redirection.

[0106] In an SSD with multiple backend physical units (e.g., 8 channels), for example, queue E has a weighted depth of 80, queue F has a weighted depth of 60, and queue H has a weighted depth of 58, with a gradient 22 > 15. If the command to be forwarded is a write command, and the remaining erase counts for the associated channel of queue B are 2000 and those for the associated channel of queue C are 2500, then queue H is selected for redirection. Write commands are more likely to cause queue depth expansion and subsequent GC pressure than read commands. Assigning higher weights to write commands in gradient calculation can detect load imbalance more quickly. When redirecting write commands, the unit with the most remaining erase counts is prioritized, directing write pressure to healthier blocks, achieving wear leveling while balancing load, and extending the overall lifespan of memory module 122.

[0107] Figure 11 This is a flowchart illustrating water level gradient load balancing and write command redirection in one embodiment of this application. Write load unevenness is amplified by assigning higher weight to write command depth, and redirection is triggered when the gradient exceeds a threshold. For write commands, the physical unit with the most remaining erase cycles is further selected from the candidate idle queue, thus balancing the load while directing write pressure towards healthy blocks.

[0108] In one embodiment, to address the issue of load interference in mixed read / write scenarios, the front-end concurrency depth threshold is divided into a read concurrency threshold and a write concurrency threshold. The read concurrency threshold limits the number of concurrent commands in the read commit queue, while the write concurrency threshold limits the number of concurrent commands in the write commit queue. Read commands from host 11 are submitted to the read commit queue, and write commands are submitted to the write commit queue. The read and write commit queues operate independently. Furthermore, the number of back-end physical units in garbage collection is continuously monitored. Based on the proportion of this number to all back-end physical units, the ratio of the read and write concurrency thresholds is adjusted, reducing the read concurrency threshold by a preset offset to minimize the interference of read operations on programming bandwidth during garbage collection.

[0109] In NVMe SSD, control circuit 23 maintains read commit queue SQ_Read and write commit queue SQ_Write, each associated with a concurrency threshold, namely read_threshold and write_threshold, with the initial value of each being half of frontend_threshold.

[0110] The backend channel state machine indicates whether source block reclamation (GC read / write) is in progress. It counts the number of channels in the GC state (gc_count) and calculates gc_ratio = gc_count / total_channels. When gc_ratio > GC_Threshold (e.g., 0.25), it automatically lowers read_threshold by a preset offset, such as 5. That is, the new read_threshold = write_threshold (or the current read_threshold) - offset. Simultaneously, write_threshold remains unchanged or slightly increases to prioritize write command processing, as GC itself generates a large number of write operations, requiring more write bandwidth.

[0111] For example, initially, read_threshold=32 and write_threshold=32. When GC is detected in 3 channels (out of 8 channels, gc_ratio=0.375), read_threshold is adjusted to 27. This reduces the upper limit of concurrent read commands at the front end, minimizing interference from read commands on programming operations, allowing GC to complete faster, and enabling the overall performance of storage device 12 to recover more quickly.

[0112] Conventional read / write separation is static, while this embodiment dynamically adjusts the ratio based on the backend GC status, which better matches the actual working characteristics of the memory module 122.

[0113] In one embodiment, to address the issue of excessive resource contention between the controller 123 and the memory module 122 due to a continuous high-speed influx of read commands under excessive write pressure, a linked freezing mechanism is introduced. If a write command causes any command scheduling queue to enter a high-water congestion state and shrinks the write concurrency threshold, it is determined whether the backend physical unit pointed to by the write command is in a programming suspended state. If so, the read concurrency threshold is frozen, and the read concurrency threshold is forcibly reduced by an additional conservative offset, preventing it from expanding during the write concurrency threshold shrinkage. This continues until all command scheduling queues exit the high-water congestion state, at which point the freeze on the read concurrency threshold is lifted, and the conservative offset is restored.

[0114] Specifically, when the high-water congestion state is caused by a write command, and the specific channel status shows PROGRAM_SUSPEND (programming suspended, i.e., the read command interrupted the ongoing programming operation), control circuit 23 executes: shrink write_threshold (e.g., reduce by 8); simultaneously freeze read_threshold, and subtract conservative_offset (e.g., 5) from the frozen value. During the freeze period, even if the global snapshot shows read is idle, read_threshold does not increase. After all queues exit the high-water congestion, conservative_offset is restored first (read_threshold is added back to 5), and then the queue is unfrozen.

[0115] For example, `write_threshold` was originally 32, then shrunk to 24. `read_threshold` was originally 28, then frozen and further reduced by 5 to 23. During congestion, even if reads are idle, `read_threshold` will not return to 28. After exiting, `read_threshold` first becomes 28, and then can participate in normal expansion operations. When programming is suspended, the channel is occupied by read operations, and suspended write operations cannot be completed. If the read threshold is not frozen and further reduced at this time, new read commands will continue to interrupt programming, forming a vicious cycle of read-suspend-read again, and the latency of write commands will increase sharply. The freezing and reduction measures in this embodiment forcibly reduce read interference, allowing suspended programming to resume and complete as soon as possible, thereby resolving the deadlock.

[0116] Furthermore, the condition for lifting the read concurrency threshold freeze is: after all command scheduling queues exit the high-water mark congestion state, they continuously maintain a normal water mark state or a low-water mark idle state for a preset number of hysteresis cycles. This number of hysteresis cycles is dynamically extended based on the cumulative number of write commands that were temporarily delayed due to write congestion during the freeze period; the larger the cumulative number, the larger the number of hysteresis cycles.

[0117] In detail, during the freeze period, the control circuit 23 counts the pending write commands and records them as pending_wd_cnt. The default hysteresis cycle count Hysteresis_Base = 3. The dynamic hysteresis cycle count = Hysteresis_Base + floor(pending_wd_cnt / Pending_Scale), where Pending_Scale can be set to 20. For example, if 45 pending write commands accumulate during the freeze period, the cycle count = 3 + floor(45 / 20) = 3 + 2 = 5. After all queues exit the high watermark, the freeze is only lifted after 5 consecutive collection cycles without congestion or high watermarks. A simple fixed hysteresis might prematurely lift the freeze before the backend backlog is cleared, leading to repeated congestion. Linking the hysteresis cycle to the backlog of write commands ensures that the backend has sufficient time to clear the accumulated write operations, preventing premature read threshold recovery from triggering write congestion again.

[0118] Furthermore, to achieve a more rational scheduling order during the recovery phase, the triggering reason for the aforementioned shrinkage operation is recorded. This triggering reason indicates whether the high-water mark congestion state is caused by read command congestion or write command congestion. Once all command scheduling queues have exited the high-water mark congestion state, if the triggering reason is write command congestion, the shrunken write congestion threshold is restored first, followed by the unfreezing of the read congestion threshold. Before restoring the write congestion threshold, it is checked whether the backend physical unit related to the write command congestion is performing a mapping table update operation (i.e., L2P table write-back). If so, the restoration of the write congestion threshold is delayed until the mapping table update is complete.

[0119] When the contraction operation is triggered, control circuit 23 writes the cause flag `cause_flag` to a global variable, with a value of either `CAUSE_WR` or `CAUSE_RD`. After exiting the high-water mark, if `cause_flag` == `CAUSE_WR`, it first attempts to restore `write_threshold`. However, before restoring, it checks whether the mapping table of the associated channel is being written back (Map Update state). If it is being written back, it waits for the operation to complete (polling the status register or waiting for an interrupt) before restoring `write_threshold` (e.g., restoring it to its original value all at once or restoring it gradually). Then, it releases the freeze on `read_threshold` according to the above conditions.

[0120] For example, write congestion triggers contraction, and `write_threshold` drops from 32 to 16. After exiting the high-water mark, if the channel's mapping table is detected to be writing back, `write_threshold` remains unchanged at 16. After waiting 500μs for the write-back to complete, `write_threshold` is restored to 32, and then `read_threshold` is unfrozen. Mapping table updates are a critical background operation of storage device 12. During this time, the backend physical units are busy, and immediately restoring the write threshold may cause new write commands to compete for resources with the mapping table update, leading to congestion again. Delayed recovery avoids this competition, making the recovery process smoother.

[0121] Figure 12 This is a flowchart illustrating the read / write concurrency threshold linkage freezing and orderly recovery process in one embodiment of this application. The initial state is normal operation. When congestion occurs due to a write command, the control circuit 23 shrinks the write concurrency threshold and simultaneously freezes the read concurrency threshold. After all queues exit the high watermark, the congestion recovery check state is entered. If the number of consecutive normal or idle cycles is less than the preset hysteresis period, the freeze is maintained; if the hysteresis condition is met, the write threshold is restored first according to the triggering reason, and if a mapping table update is encountered, the process is delayed. Then, the freeze on the read concurrency threshold is lifted and the conservative offset is restored, finally returning to normal operation. This state machine ensures the orderliness and smoothness of the recovery process.

[0122] To ensure the quality of service for high-priority commands within limited front-end concurrent resources, a priority quota mechanism is proposed in one embodiment. This mechanism configures multiple priorities and assigns an initial weight to each priority. Based on the read concurrency threshold and the initial weight, the read concurrency quota for each priority in the read commit queue is calculated; similarly, based on the write concurrency threshold and the initial weight, the write concurrency quota for each priority in the write commit queue is calculated. For commands to be forwarded, their scheduling priority or token consumption coefficient within their respective priority range is adjusted according to the health index of the backend physical unit associated with the command. Backend physical units with lower health have a higher probability of their commands being deferred or require more tokens. Tokens are allocated to commands to be forwarded based on the adjusted scheduling order or token consumption. When the read or write concurrency quota corresponding to a certain priority is exhausted, the commands for that priority are deferred. The read commit queue and the write commit queue operate independently of each other.

[0123] Control circuit 23 defines three priorities: high, medium, and low, with weights of 3, 2, and 1 respectively. Each priority level has a quota counter on the read / write commit queue. For example, with write_threshold=32 and a total weight of 6, the high-priority write quota is 16, the medium-priority quota is 10, and the low-priority quota is 6, all rounded down, with the remainder allocated to the high-priority level. The health metric is calculated as: remaining erase count / maximum erase count.

[0124] When the command to be forwarded belongs to a certain priority level, but the channel health to which it is to be written is less than the Health_Threshold (such as 0.3), the scheduling order of this command within this priority level is shifted backward (for example, placed at the end of the queue with the same priority level), or the number of tokens it consumes is multiplied by a factor of 1.5 (i.e., occupying 1.5 quotas), so that the quotas are exhausted faster, thereby deferring more commands sent to this severely worn unit. This scheme incorporates the wear leveling idea into QoS scheduling. Units with poor health actively reduce the write traffic, allowing severely worn blocks to rest and extending the service life of the storage device 12.

[0125] When calculating the write concurrent quotas of each priority level in the write submission queue, multiply the write concurrent threshold by the weight corresponding to the priority level, then divide by the sum of the weights of all priority levels and round down. The remaining integers after rounding are preferentially allocated to the priority levels corresponding to the backend physical units with the highest health, one for each level, until the remainder is zero.

[0126] For example, write_threshold = 32, high weight = 3, medium = 2, low = 1, and the sum = 6. High quota = floor(32×3 / 6)=16, medium = 10, low = 5, remainder = 32 - 31 = 1. This remainder is allocated to the priority level with the highest health. Query the average health of the channels currently mainly written by each priority level: the health of the channels associated with the high priority level is 0.9, medium is 0.7, low is 0.5, then the remainder is allocated to the high priority level, making its final quota 17. In this way, each quota allocation slightly tilts towards the healthy blocks, and the cumulative effect is significant, which is beneficial to the overall life of the memory module 122.

[0127] Figure 13 It is a flowchart of priority quota calculation and health adjustment shown in an embodiment of the present application. In the quota allocation stage, the remaining integers are preferentially allocated to the priority levels corresponding to the physical units with high health, making the quota allocation conform to the wear leveling design. When the command is actually distributed, the effective priority level or token consumption is dynamically adjusted according to the health of the target physical unit, protecting the aging blocks from two aspects: quotas and scheduling.

[0128] To improve the utilization rate of quota resources, a dynamic borrowing relationship is established between the read concurrent quotas of the read submission queue and the write concurrent quotas of the write submission queue within the same priority level.

[0129] When read concurrency quota is exhausted while write concurrency quota remains, monitor the target backend physical units currently being written to by the write concurrency quota to see if any unit is in a state of SLC cache exhaustion and folding towards TLC / QLC storage area. If so, reduce the borrowing limit of the lending relationship by a first percentage and set the lending rate to be greater than 1, so that the next cycle of the read commit queue must return more tokens than the actual borrowed amount. Otherwise, return the original lending limit and the equivalent amount, and the borrowed tokens will be deducted from the next cycle quota of the read commit queue after the monitoring period ends.

[0130] Specifically, when write quota is available but read quota is exhausted, read quota is generally allowed to borrow tokens from write quota, with a borrowing limit of 30% of write quota. Control circuit 23 monitors the SLC cache status variable in memory module 122. If the SLC cache of a certain channel is full and folding is underway (data is being moved from the SLC area to the TLC area), and the current write quota is primarily allocated to that channel, the borrowing limit is temporarily reduced to 15%, and the borrowing rate is set to 1.2, meaning that if 10 tokens are borrowed, 12 must be returned in the next cycle. This makes read operation borrowing expensive, effectively protecting write bandwidth during the folding process. SLC folding is a performance-sensitive period for memory module 122, where write bandwidth is extremely valuable. If a large amount of reads are borrowed at this time, it will severely affect the folding speed and delay write cache release. This embodiment ensures the smooth operation of critical background processes in memory module 122 by sensing the folding status and dynamically adjusting the borrowing conditions.

[0131] Figure 14 This is a flowchart illustrating the read / write quota lending mechanism and SLC folding detection process in one embodiment of this application. When a read quota needs to be borrowed from a write quota, it monitors whether the primary target unit of the write operation is in an SLC cache folding state. If so, the lending limit is tightened and a repayment condition is applied, causing read operations to incur a higher cost during the folding period, thereby protecting programming bandwidth and ensuring efficient completion of background operations. SLC cache folding refers to the process of migrating data from the SLC area to the TLC / QLC high-density storage area after the SLC cache space is exhausted.

[0132] In one embodiment, a position dimension is introduced to address the problem that traditional hunger detection based solely on absolute time may fail when the queue depth changes drastically.

[0133] This method assigns a position number and an enqueue timestamp to each command. During each scheduling iteration, it retrieves the position number and enqueue timestamp of the command at the head of the target command scheduling queue; it calculates the position difference between the current position number and the head command's position number, as well as the time difference between the current time and the head command's enqueue timestamp. The position and time thresholds are dynamically set based on the average number of erases of the backend physical units associated with the target command scheduling queue; the higher the average number of erases, the smaller the position and time thresholds. If both the position difference and time difference are greater than the position and time thresholds, the head command is determined to be in a starved state.

[0134] Specifically, each command is assigned a globally incrementing cmd_seq_num upon enqueueing, and its enqueue timestamp enqueue_time is recorded. For the command at the head of the target queue, the position difference pos_diff = current_seq - head_seq, and the time difference time_diff = current_time - head_enqueue_time.

[0135] The position threshold Pos_Thr and the time threshold Time_Thr are given by the formula: Pos_Thr = Base_Pos / (1 + avg_erase_cnt / Erase_Ref); where Base_Pos is set to 100 and Erase_Ref is set to 10000; Time_Thr = Base_Time / (1 + avg_erase_cnt / Erase_Ref), where Base_Time is set to 50ms.

[0136] If the average number of erases per channel is 3000, then Pos_Thr = 100 / (1+3000 / 10000) ≈ 77, and Time_Thr ≈ 38ms. If pos_diff > 77 and time_diff > 38ms, then starvation is determined. After the channels of memory module 122 age, the erase and write operations become slower, and commands are more likely to starve. Linking the threshold to the number of erases allows aging units to trigger starvation protection earlier, enabling early intervention and avoiding command timeouts and lag in storage device 12 caused by hardware degradation.

[0137] Once it is determined that the head command is in a starved state, the starvation handling action is executed.

[0138] One fast processing method is to retrieve the header command from the target command scheduling queue and insert it into a dedicated fast-track queue. This fast-track queue has a higher scheduling priority than the target command scheduling queue, and commands inserted into the fast-track queue are marked with a high operation priority flag, ensuring that the backend physical unit executes the command first during internal command arbitration.

[0139] The Fast Path Queue (FPQ) is a queue with limited capacity (e.g., depth 8) and higher priority than all regular command scheduling queues. During each round of command selection, control circuit 23 first checks if the FPQ queue is empty and processes it accordingly. Simultaneously, when constructing the command descriptor, the priority flag (e.g., the CMD_PRIORITY field) for that command is set to HIGH, prioritizing this command when multiple commands are waiting. This ensures that hungry commands are executed as quickly as possible.

[0140] Another, more thorough approach is to pause adding new commands to the target command scheduling queue when a header command is determined to be starved, forcing the target command scheduling queue to process all starved commands only in the order they were enqueued. If the backend physical unit associated with the target command scheduling queue supports multi-plane operations and the current multi-plane queue is not full, and the physical addresses accessed by the first two starved commands processed sequentially meet the address alignment conditions for multi-plane operations, then these two starved commands are grouped together and issued simultaneously. This process continues until no commands in the target command scheduling queue meet the starvation criteria.

[0141] During the forced sequential processing phase, starvation commands are retrieved and executed only sequentially from the head of the queue. Control circuit 23 checks whether the LBA addresses of the next two commands in the queue correspond to different planes of the same LUN, and whether their page offsets are within the allowed alignment range (e.g., different planes of the same block with the same page number). If these conditions are met, they are merged into a single multi-plane programming or reading command to speed up the processing of starvation commands. This utilizes the multi-plane parallelism capability of memory module 122, improving efficiency while resolving starvation.

[0142] Figure 15 This is a flowchart illustrating a two-dimensional command hunger detection and processing method according to an embodiment of this application. Control circuit 23 acquires the position number and enqueue timestamp of the command at the head of the target queue, and calculates the position difference and time difference. If both differences exceed the corresponding thresholds, the command is determined to be in a hungry state. Then, a processing method is selected based on the severity of hunger: for mild hunger, the command is moved to the fast-channel queue and marked with high operation priority to accelerate execution; for severe hunger, adding new commands to the target queue is paused, and all commands meeting the hunger conditions are forcibly processed in the enqueue order. If the backend physical unit supports multi-plane operations and address alignment, the two hungry commands can be grouped into a multi-plane command group and issued in parallel, utilizing the parallel characteristics of memory module 122 to accelerate the elimination of hunger. The position threshold and time threshold are dynamically adjusted according to the average number of erases of the physical unit, with blocks with higher aging triggering protection earlier.

[0143] The location threshold is not a fixed value; it can be dynamically set based on the average command processing latency of the command scheduling queue and the average raw bit error rate (RBER) of the backend physical units associated with that queue. The higher the average command processing latency and the higher the average raw bit error rate, the smaller the location threshold.

[0144] The specific formula can be: Pos_Thr=Base_Pos / (1+avg_latency / Latency_Ref+avg_RBER / RBER_Ref); Where avg_RBER is the average raw bit error rate of the physical unit, and RBER_Ref is the reference bit error rate, such as 1e-3. A high bit error rate means that the unit has more data errors, requiring a longer error correction time, and is more prone to command starvation. Incorporating the bit error rate into the threshold adjustment makes starvation detection more accurately reflect the physical health status of memory module 122, providing earlier intervention for high-risk units.

[0145] In one embodiment, to ensure the consistency of timestamps under the control circuit 23 as a multi-core processor, the processors within the control circuit 23 perform cross-core time synchronization through a global clock counter, and use the flip edge of the ready / busy signal output by the back-end physical unit when the operation is completed as a synchronization reference to perform phase calibration on the global clock counter. The hardware timestamps of each channel are transmitted to the front-end protocol core 28, and the front-end protocol core 28 adjusts the front-end queue according to the back-end status awareness to ensure the consistency of timestamps in the delay calculation.

[0146] The storage device 12 contains a global clock counter, global_timer, accessible to all processor cores in the control circuit 23. Upon completion of the operation, the R / B# signal output by the memory module 122 generates a rising edge. The control circuit 23 captures this edge and generates a synchronization pulse to latch the global_timer value and distribute it to each processor core, thereby correcting the phase offset of each processor core's local timestamp. The hardware timestamp recorded by each channel is based on the calibrated global_timer, ensuring accurate time difference when the front-end protocol core 28 calculates command delays, providing precise delay data for state awareness.

[0147] In one embodiment, the control circuit 23 continuously monitors the read command completion rate, the write command completion rate, and the dirty data level of the buffer memory 24. When the write command completion rate continuously decreases and the dirty data level exceeds the warning threshold, even if the global state snapshot does not reflect that any command scheduling queue is in a high-water congestion state, a shrinkage operation is still performed on the write concurrency threshold to prevent write cache overflow.

[0148] The control circuit 23 calculates the write command completion rate wr_rate, which is the number of write commands completed per millisecond, and compares the rate over three consecutive cycles. If the rate decreases in each cycle compared to the previous cycle, and the dirty data level dirty_ratio > the warning threshold (e.g., 80%), it triggers a contraction of the write concurrency threshold, for example, a reduction of 20%. Even if the global queue depth has not reached the high water level, it can preemptively reduce write pressure and prevent data loss caused by write cache overflow. This is a predictive protection based on rate trends and cache pressure.

[0149] In one embodiment, the control circuit 23 maintains a weight value for each channel, which is calculated based on the channel's historical load intensity, average processing latency, and the number of remaining free blocks. The fewer the remaining free blocks, the greater the reduction in the weight value. When the front-end concurrency depth threshold is reduced, the control circuit 23 does not apply equal current limiting to all channels. Instead, it prioritizes limiting channels with lower weights from receiving new commands, while channels with higher weights maintain a relatively higher command allocation.

[0150] The formula for calculating the channel weight W_ch is: W_ch=α×Norm(load)+β×Norm(1 / latency)+γ×(free_block_ratio); Where free_block_ratio = the proportion of remaining free blocks to the total number of blocks, γ is a positive coefficient, and Norm represents normalization.

[0151] The smaller the free_block_ratio of a channel, the more significant the reduction in W_ch. When the threshold shrinks, for example, when the total concurrency limit decreases from 32 to 20, requiring a limit of 12 commands, the control circuit 23 calculates the number of commands each channel should receive based on its weight, with lower-weighted channels receiving more reductions. This encourages write loads to stay away from channels that are about to be filled, avoiding frequent garbage collection and maintaining stable performance of the storage device 12.

[0152] Figures 6 to 15 Each step has been explained in detail above and will not be repeated here. It is worth noting that... Figures 6 to 15 Each step can be implemented as multiple program codes or circuits, applied to the storage device 12 including the memory module 122, and the control circuit 23 is configured to execute this method. This application is not limited thereto. Furthermore, Figures 6 to 15 The method can be used in conjunction with the above examples and embodiments, or it can be used alone; this application does not impose any restrictions.

[0153] In summary, the core of the command queue adjustment method and storage device provided in the embodiments of this application lies in associating multiple back-end physical units of the storage device with multiple command scheduling queues, configuring high and low watermark thresholds for each command scheduling queue, periodically collecting the current queue depth of each queue, determining the watermark status of each queue based on the relationship between queue depth and threshold, aggregating the determination results into a global state snapshot, and then adjusting the front-end concurrency depth threshold based on this global state snapshot. If any queue is in a high-watermark congested state, a shrinking operation is performed to lower the threshold; if more than half of the queues are in a low-watermark idle state without congestion, an expanding operation is performed to raise the threshold. Through real-time perception and closed-loop feedback of the back-end status, a dynamic balance between the inflow of front-end commands and the actual processing capacity of the back-end is achieved, thereby optimizing the management of command queues and improving the read / write speed and performance stability of the storage device.

[0154] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A command queue adjustment method, characterized in that, For a storage device, the storage device including a controller and a memory module, the controller including a buffer memory, the method includes: Multiple backend physical units are associated with multiple command scheduling queues, and each backend physical unit corresponds to at least one command scheduling queue. Configure a high-water threshold and a low-water threshold for each of the multiple command scheduling queues; The current queue depth of the multiple command scheduling queues is periodically collected; Based on the relationship between the current queue depth and the high and low water level thresholds, it is determined that each of the multiple command scheduling queues is in a high water level congestion state, a normal water level state, or a low water level idle state. The determination results are aggregated into a global state snapshot, and a front-end concurrency depth threshold of the storage device is dynamically adjusted based on the global state snapshot, wherein the front-end concurrency depth threshold is used to limit the upper limit of the number of commands processed in the back-end of the storage device. If the global state snapshot reflects that any command scheduling queue is in the high-water congestion state, then a shrinkage operation is performed to reduce the front-end concurrency depth threshold; and If the global state snapshot reflects that more than a preset value of command scheduling queues are in the low-water level idle state and no command scheduling queues are in the high-water level congested state, then an expansion operation is performed to increase the front-end concurrency depth threshold.

2. The command queue adjustment method according to claim 1, characterized in that, The contraction operation includes: Obtain an operational attribute of the backend physical unit associated with the command scheduling queue that is in the high water level congestion state, the operational attribute including whether the backend physical unit is performing a slow operation, the slow operation including an erase operation or a cross-page boundary programming operation; A base contraction step size is determined based on the congestion level value; If any backend physical unit associated with a congested command scheduling queue is performing the slow operation, the base shrink step size is multiplied by a first multiplier factor to obtain the final shrink step size, wherein the first multiplier factor is greater than 1. Otherwise, the base contraction step size is used as the final contraction step size, and the front-end concurrency depth threshold is reduced to decrease the final contraction step size.

3. The command queue adjustment method according to claim 1, characterized in that, Also includes: Calculate a global congestion index, which is the ratio of the number of queues in the high-water congestion state among the plurality of command scheduling queues to the total number of the plurality of command scheduling queues; When the global congestion index exceeds a global contraction threshold, regardless of whether there are queues in the low-water idle state among the multiple command scheduling queues, the expansion operation is suspended. At the same time, a background operation suppression instruction is sent to the backend physical units associated with all command scheduling queues in the high-water congestion state to reduce the execution rate of garbage collection or wear leveling operations within the backend physical units. Then, depending on the degree to which the global congestion index exceeds the global contraction threshold, the option is to maintain the front-end concurrency depth threshold at its current value or to perform an additional contraction. The additional contraction is to reduce the front-end concurrency depth threshold by a preset fixed step size.

4. The command queue adjustment method according to claim 1, characterized in that, Also includes: After performing the contraction or expansion operation, a cooling period is set. The length of the cooling period is dynamically set based on the magnitude of the change in the front-end concurrency depth threshold caused by the current shrinkage or expansion operation and the write amplification factor of the storage device in the most recent time window. The greater the magnitude of the change and the higher the write amplification factor, the longer the cooling period. During the cooling-off period, even if the global state snapshot meets the corresponding shrinkage or expansion condition, the shrinkage operation or the expansion operation will not be performed again.

5. The command queue adjustment method according to claim 1, characterized in that, Also includes: Calculate a water level gradient among the plurality of command scheduling queues, the water level gradient reflecting the degree of difference in the current queue depth of the plurality of command scheduling queues, and when calculating the gradient, assign a first weight to the queue depth corresponding to the write command and assign a second weight to the queue depth corresponding to the read command, wherein the first weight is greater than the second weight. When the water level gradient exceeds a preset gradient threshold, a command to be forwarded is redirected from a first command scheduling queue to a second command scheduling queue, wherein the current queue depth of the second command scheduling queue is lower than the current queue depth of the first command scheduling queue; and When the command to be forwarded is a write command, the second command scheduling queue selects the candidate command scheduling queue with the most remaining erase counts from the associated backend physical unit from the candidate command scheduling queues whose current queue depth is lower than that of the first command scheduling queue.

6. The command queue adjustment method according to claim 1, characterized in that, The shrink operation allows the front-end concurrency depth threshold to be reduced to a minimum threshold value, which is not a fixed value, but is dynamically set based on the proportion of dirty data written to the buffer memory but not yet programmed into the memory module and a write amplification effect factor. The higher the proportion of dirty data, the larger the write amplification impact factor, and the lower the minimum threshold value, the better to ensure that at least a basic flush rate is maintained and to avoid write cache overflow.

7. The command queue adjustment method according to claim 1, characterized in that, Also includes: The front-end concurrency depth threshold is divided into a read concurrency threshold and a write concurrency threshold. The read concurrency threshold is used to limit the number of concurrent commands in a read commit queue, and the write concurrency threshold is used to limit the number of concurrent commands in a write commit queue. as well as A read command from the host is posted to the read commit queue, and a write command from the host is posted to the write commit queue. The read commit queue and the write commit queue operate independently of each other. as well as The number of backend physical units in garbage collection is continuously monitored. Based on the proportion of this number to all backend physical units, the ratio of the read concurrency threshold to the write concurrency threshold is adjusted so that the read concurrency threshold is reduced by a preset offset to reduce the interference of read operations on programming bandwidth during garbage collection.

8. The command queue adjustment method according to claim 7, characterized in that, Also includes: If a write command causes any command scheduling queue to enter the high-water congestion state and the write concurrency threshold is reduced, it is determined whether the backend physical unit pointed to by the write command is in a programming suspended state. If so, the read concurrency threshold is frozen and the read concurrency threshold is forcibly reduced by an additional conservative offset so that it cannot expand during the write concurrency threshold contraction. After all command scheduling queues exit the high-water congestion state, the freeze on the read concurrency threshold is lifted and the conservative offset is restored.

9. The command queue adjustment method according to claim 8, characterized in that, The condition for lifting the freeze on the read concurrency threshold is: After all command scheduling queues exit the high water level congestion state, they continuously maintain the normal water level state or the low water level idle state for a preset number of hysteresis cycles. The preset hysteresis cycle number is dynamically extended based on the cumulative number of write commands that are delayed due to write congestion during the freeze period. The larger the cumulative number, the larger the hysteresis cycle number.

10. The command queue adjustment method according to claim 8, characterized in that, Also includes: Record a triggering reason that triggers the contraction operation, the triggering reason indicating whether the high water level congestion state is caused by a read command congestion or a write command congestion; After all command scheduling queues exit the high-water congestion state, if the triggering reason is write command congestion, the shrinking write concurrency threshold is restored first, and then the freeze on the read concurrency threshold is lifted. as well as Before restoring the write concurrency threshold, it is detected whether the backend physical unit related to the write command congestion is performing a mapping table update operation. If so, the restoration of the write concurrency threshold is delayed until the mapping table update is completed.

11. The command queue adjustment method according to claim 7, characterized in that, Also includes: Configure multiple priorities and assign an initial weight to each of the multiple priorities; Based on the read concurrency threshold and the initial weight, calculate the read concurrency quota for each priority in the read submission queue; Based on the write concurrency threshold and the initial weight, calculate a write concurrency quota for each priority in the write submission queue; For a command to be forwarded, the scheduling priority or token consumption coefficient of the command within its priority range is adjusted according to the health index of the backend physical unit associated with the command. The lower the health index of the backend physical unit, the higher the probability that its command will be suspended or the more tokens it needs to consume. Based on the adjusted scheduling order or token consumption, tokens are allocated to commands to be forwarded. When the read concurrency quota or write concurrency quota corresponding to a priority is exhausted, the command of that priority is temporarily suspended from forwarding. The read commit queue and the write commit queue operate independently of each other.

12. The command queue adjustment method according to claim 11, characterized in that, The calculation of the write concurrency quota for each priority in the write commit queue includes: Multiply the write concurrency threshold by the weight corresponding to the priority, divide by the sum of all priority weights, and then round down. The remainder after rounding is preferentially allocated to the priority corresponding to the backend physical unit with the highest health, one for each level, until the remainder is zero.

13. The command queue adjustment method according to claim 11, characterized in that, Also includes: Within the same priority, a dynamic lending relationship is established between the read concurrency quota of the read commit queue and the write concurrency quota of the write commit queue; When the read concurrency quota of the read commit queue is exhausted while the write concurrency quota of the write commit queue is remaining, monitor whether there is a unit in the target backend physical unit that the write concurrency quota is currently being written to that is in a state of SLC cache exhaustion and folding into TLC / QLC storage area. If so, the borrowing limit of the lending relationship will be reduced by a first percentage, and the lending interest rate will be set to be greater than 1, so that the next cycle of the read submission queue must return more tokens than the actual number of tokens borrowed. Otherwise, the borrowed tokens will be returned at the original borrowing limit and in equal amounts, and will be deducted from the next cycle quota of the read submission queue after the monitoring period ends.

14. The command queue adjustment method according to claim 1, characterized in that, Also includes: Assign a position number and an enqueue timestamp to each command in the plurality of command scheduling queues; During each scheduling, the position number and enqueue timestamp of the head command of a target command scheduling queue are obtained; Calculate a position difference between a current position number and the position number of the header command, and a time difference between a current time and the enqueue timestamp of the header command. The position threshold and the time threshold are dynamically set based on the average number of erases of the backend physical units associated with the target command scheduling queue. The higher the average number of erases, the smaller the position threshold and the time threshold. If the position difference is greater than the position threshold and the time difference is greater than the time threshold, then the header command is determined to be in a starvation state.

15. The command queue adjustment method according to claim 14, characterized in that, The determination that the head command is in a starvation state includes: The header command is retrieved from the target command scheduling queue and inserted into a dedicated fast-track queue, which has a higher scheduling priority than the target command scheduling queue; and A high operation priority flag is assigned to the command to be inserted into the fast channel queue, so that the back-end physical unit executes the command first during internal command arbitration.

16. The command queue adjustment method according to claim 14, characterized in that, Also includes: When it is determined that the head command is in the starvation state, the addition of new commands to the target command scheduling queue is paused, and the target command scheduling queue is forced to process all commands in the starvation state only in the order of enqueueing. If the backend physical unit associated with the target command scheduling queue supports multi-plane operation and the current multi-plane queue is not full, and the physical addresses accessed by the first two hunger commands processed in sequence meet the address alignment conditions of multi-plane operation, then it is allowed to combine the two hunger commands into a multi-plane command group and issue them simultaneously. The process continues until no command in the target command scheduling queue satisfies the condition that the position difference is greater than the position threshold and the time difference is greater than the time threshold.

17. The command queue adjustment method according to claim 14, characterized in that, The location threshold is not a fixed value, but is dynamically set based on the average command processing latency of the command scheduling queue and the average raw bit error rate of the backend physical unit associated with the queue. The higher the average command processing latency, the smaller the location threshold.

18. The command queue adjustment method according to claim 1, characterized in that, When the storage device is a general-purpose flash memory storage device, the back-end physical unit is a logical unit; The front-end concurrency depth threshold is implemented by maintaining a virtual pass threshold inside a UTP layer of the general-purpose flash memory device, wherein different logical units are configured with different initial values ​​of the virtual pass threshold according to their storage attributes, and the initial value of the virtual pass threshold of the logical unit configured as the enhanced storage area is higher than that of the logical unit in the ordinary storage area. When the number of active commands in a command scheduling queue reaches the virtual pass threshold, the retrieval of new commands from the host is paused in order to generate backpressure on the host using a flow control mechanism at the UTP layer.

19. The command queue adjustment method according to claim 1, characterized in that, When the storage device is a solid-state drive, the back-end physical unit is a channel; The front-end concurrency depth threshold is achieved by maintaining an active command counter and a dynamic upper limit for each commit queue of the solid-state drive. For any channel, when the channel enters an internal busy state due to garbage collection, the dynamic upper limit is automatically reduced by a preset percentage. When the active command counter of the commit queue corresponding to the channel is higher than the reduced dynamic upper limit, the extraction of new commands from the commit queue is suspended, so as to form back pressure by utilizing the doorbell mechanism on the host side. Once the channel exits the internal busy state, the original dynamic upper limit is restored.

20. The command queue adjustment method according to claim 19, characterized in that, Also includes: Continuously monitor the read command completion rate, write command completion rate, and dirty data level in the buffer memory; When the write command completion rate continuously decreases and the dirty data level exceeds a warning threshold, even if the global state snapshot does not reflect that any command scheduling queue is in the high-water congestion state, the shrinking operation is still performed on the write concurrency threshold to prevent a write cache overflow.

21. The command queue adjustment method according to claim 19, characterized in that, Also includes: Cross-core time synchronization is performed using a global clock counter, and the phase calibration of the global clock counter is performed using the flip edge of the ready / busy signal output by the back-end physical unit when the operation is completed as the synchronization reference. A hardware timestamp for each channel is transmitted to a front-end protocol core, which adjusts the front-end queue based on back-end state awareness to ensure the consistency of timestamps in a delayed calculation.

22. The command queue adjustment method according to claim 19, characterized in that, Also includes: Each channel maintains a weight value, which is calculated based on the channel's historical load intensity, average processing latency, and the number of remaining free blocks. The fewer the number of remaining free blocks, the greater the reduction in the weight value. When the front-end concurrency depth threshold is reduced, it does not limit the flow equally to all channels. Instead, based on the weight value, it prioritizes limiting the channels with lower weight values ​​from receiving new commands, while channels with higher weight values ​​maintain a relatively higher command allocation.

23. A storage device, characterized in that, include: A connection interface for electrically connecting to a host computer; The memory module includes multiple back-end physical units. When the storage device is UFS, the back-end physical unit is a logical unit; when the storage device is SSD, the back-end physical unit is a channel. as well as The controller includes an error checking and correction circuit, a buffer memory, and a control circuit, and the controller is electrically connected to the connection interface and the memory module; The control circuit is configured to perform the command queue adjustment method as described in any one of claims 1 to 22.

Images