Patent Application
20220027084
Solid state devices or drives (also known as SSDs) are data storage devices that use integrated circuit assemblies, and typically utilize Flash memory protocols.
Whenever there is a read request or a write request to the SSD, the SSD tries to complete the request as soon as possible. At times, the drive is very busy or may be not busy at all, depending on the incoming requests. Because of this, there are performance instabilities, such as IOPS (input/output operations per second) variations and response time variations.
This disclosure is directed to improving performance instability in solid state devices (SSDs), particularly, decreasing the instability, by controlling or throttling the SSD performance. By improving the performance, the product competitiveness improves.
This disclosure provides, in one particular implementation, a method. The method includes monitoring a request queue in a solid state device (an SSD), the request queue comprising a first request and a second request having an actual time interval therebetween, determining a queue depth for the request queue, determining a target interval based on the queue depth and a target queue depth, and responsive to the actual time interval being less than the target interval, delaying acting on the second request until after the target interval.
In another particular implementation, another method is provided. The method includes monitoring a request queue to a semiconductor storage device (an SSD), the request queue having a depth and comprising at least a first request, a second request, and an outgoing interval between the requests, and responsive to the outgoing interval being less than a target interval based on a target queue depth and the queue depth, setting an actual outgoing interval to be no less than the target interval and acting on the second request after expiration of the target interval.
In another particular implementation, a system is provided. The system includes a solid state device (SSD) and a host, and an interval throttling module stored in memory and implemented by a processor. The interval throttling module is located in a data request completion path of the system and comprises a queue memory unit, a delay unit configured to delay acting on a second request if an outgoing interval between a first request and the second request is less than a target interval, and a calculator unit configured to dynamically adjust the target interval based on a throttle queue depth.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. These and various other features and advantages will be apparent from a reading of the following detailed description.
The described technology is best understood from the following Detailed Description describing various implementations read in connection with the accompanying drawing.
When there is a read request or a write request to the SSD, the SSD tries to complete the request as soon as possible. At times, the drive is very busy or not busy at all, depending on the incoming requests. The present disclosure provides a methodology to improve the SSD performance by controlling (e.g., throttling) the spacing between requests (the target interval, or T_TargetInterval) in the queue to be acted on based on the throttle queue depth.
In general, a throttling module of this disclosure monitors and controls the number or requests residing in the queue to be acted on. The throttling module utilizes a control algorithm to calculate an average throttle queue depth, then modulates the target interval (T_TargetInterval) between requests, so that the average throttle queue depth moves closer to the target queue depth.
In general, the throttling module of this disclosure has three sub-units, a queue unit, a delay unit and a target interval calculator. The queue unit stores the queue of read or write requests, or both read and write requests, and may be, e.g., a volatile memory. The delay unit receives the request and sends it to be acted on no sooner than after the target interval (T_TargetInterval), which adjusts based on the queue depth. The calculator calculates the target interval, which is the target time between each request's completion, taking into account the average queue depth in the queue unit.
By setting a minimum time between acting on requests, i.e., the T_TargetInterval, the IOPS can be precisely controlled, resulting in decreased performance variations and significantly improved overall SSD performance. By basing the target interval on an internal parameter such as the depth of the queue, a more universal and complete control is obtained.
It is noted that throttling does not improve overall performance in the sense of increased speed, but rather, throttling makes the performance more consistent, which is especially desirable in large network (e.g., “Cloud”) environments where a service level agreement often requires specific response times. It is performance in this broader sense that is improved, rather than the narrow usage of performance referring to simple throughput.
In the following description, reference is made to the accompanying drawing that forms a part hereof and in which is shown by way of illustration at least one specific implementation. The following description provides additional specific implementations. It is to be understood that other implementations are contemplated and may be made without departing from the scope or spirit of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense. While the present disclosure is not so limited, an appreciation of various aspects of the disclosure will be gained through a discussion of the examples, including the figures, provided below. In some instances, a reference numeral may have an associated sub-label consisting of a lower-case letter to denote one of multiple similar components. When reference is made to a reference numeral without specification of a sub-label, the reference is intended to refer to all such multiple similar components.
Within the SSD 102 and between the host 104 and the SSD 102 are various data paths, particularly, read/write submission paths shown as dotted arrows and various completion paths shown as solid arrows. Within the SSD 102, the submission and completion paths run between the memories 108, the back-end controller 110 and the front-end controller 112. The submission and completion paths also run within each element (e.g., the host 104, the back-end controller 110 and the front-end controller 112). In the particular system 100 of
In an alternate system 200 shown in
The throttling module can be positioned in any location within the system 100 or system 200, within a data path. Although a completion path is desired, the throttling module could be present in a submission path. As another example, the throttling module can be positioned between Flash memory and the back-end controller.
Returning to
Although not illustrated, the throttling module 106 also may include any or all of a read/write splitter, a throttling unit which can have a first portion for the read actions and a second portion for the write actions, and a read/write merger.
The throttling module 106, 206 is configured to control the interval between all read and write requests. In alternate implementations, the read requests and write requests are throttled independently.
A plurality of requests 302, either read requests or write requests, or both, are shown in
Because incoming request 302a is the first sent, the corresponding outgoing request 304a is acted on without delay, essentially immediately. The second incoming request 302b occurs at an actual T_IncomingInterval where the corresponding T_OutgoingInterval will be less than the desired interval T_TargetInterval if this request is acted on immediately upon receipt; thus, the corresponding outgoing request 304b is delayed so that the interval between request 304a and 304b (i.e., T_OutgoingInterval) is T_TargetInterval. Similarly, the third incoming request 302c occurs at an actual T_IncomingInterval where the corresponding T_OutgoingInterval will be less than the desired interval T_TargetInterval if this request is acted on immediately upon receipt; thus, the corresponding outgoing request 304c is delayed so that the interval between request 304b and 304c (i.e., T_OutgoingInterval) is T_TargetInterval. The fourth incoming request 302d has an actual T_OutgoingInterval that is at least, and even more than, the desired interval T_TargetInterval if this request is acted on immediately up receipt; thus, the corresponding outgoing request 304d is completed essentially immediately with no delay. The fifth incoming request 302e occurs at an actual T_IncomingInterval after the fourth request 302d where the corresponding T_OutgoingInterval will be less than the desired interval T_TargetInterval if this request is acted on immediately upon receipt; thus, the corresponding outgoing request 304d is delayed so that the interval between the request 304c and 304d (i.e., T_OutgoingInterval) is T_TargetInterval. The sixth incoming request 302f occurs at an actual T_IncomingInterval after the fifth incoming request 302e that is approximately the same as the desired interval T_TargetInterval; however, because of the delay in acting on the fifth request (i.e., the outgoing request 304e), the corresponding outgoing request 304f is also delayed so that the interval between the outgoing request 304e and the outgoing request 304f is T_TargetInterval.
The particular T_TargetInterval depends on the throttle queue depth and dynamically adjusts with the queue depth. For example, as the throttle queue depth becomes higher than the target value, the T_TargetInterval decreases, in order to process the requests more quickly and shorten the queue. The value for T_TargetInterval may be between, e.g., 1 microsecond and 100 microseconds.
Summarized, the interval between outgoing requests 304 (T_OutgoingInterval) is no less than T_TargetInterval, or, the interval between outgoing requests 304 (T_OutgoingInterval) is T_TargetInterval or greater, with the T_TargetInterval based on the throttle queue depth.
An overall example methodology of the delay unit (e.g., the delay unit 162) to throttle the requests is shown in
The T_TargetInterval is dynamically adjusted based on the throttle queue depth, e.g., the average throttle queue depth. An average throttle queue depth may be calculated over a predetermined period of time, which also may be dynamically adjusted.
An overall example methodology for adjusting the T_TargetInterval based on an average throttle queue depth is shown in
In a first step 502, the average throttle queue depth (QD) is obtained. This may be any type of average, e.g., an arithmetic mean, moving average, exponential moving average, harmonic mean, quadratic mean, geometric mean, weighted mean, or trimmed or truncated mean. In one example, the average QD is 32. The average QD is calculated for a predetermined period of time, e.g., 1 second, 10 seconds; the predetermined period of time may also be adjusted. The average QD can be updated after a predetermined number of requests or calculations. In some implementations, the average QD may be further adjusted based on, e.g., temperature of the SSD, or power usage of the SSD.
After the average QD is obtained, a normalized difference of the QD is calculated in step 504, by dividing the target QD (TargetQD) less the average QD by a system QD. This system QD is the number of outstanding requests within the SSD, whether or not in the throttle queue. The TargetQD may be a fixed or dynamically adjusted value; in one example, the TargetQD is 8. The system QD may be an actual real time number or may be an averaged value. Either or both the TargetQD and the system QD may be further adjusted based on, e.g., temperature of the SSD, or power usage of the SSD.
With this normalized difference of the QD from step 504, the change for the T_TargetInterval is calculated in step 506, as the normalized difference of the QD multiplied by the current T_TargetInterval, multiplied by a coefficient α. The coefficient α defines the range of change for the T_TargetInterval per adjustment, and may be, e.g., a percentage. For example, when α is 5%, the change in T_TargetInterval is within 5% of the previous T_TargetInterval. Another example is when α is 10%. Although a can be any value, it is not desired to move the T_TargetInterval drastically, as drastic changes can provide less precise queue depth throttling. Thus, in some implementations, a is no greater than 25%, no greater than 15%, no greater than 10%, or no greater than 5%.
With the change in T_TargetInterval from step 506, the new T_TargetInterval is calculated in step 508. This new T_TargetInterval is transmitted to the delay unit of the throttling module (e.g., delay unit 162 of module 106 in
The throttling modules described herein may be implemented as and/or processed as software or other machine-readable instructions. When implemented as processes in software, the modules may be provided as executable code which, when run on a device having a processor and computer capability, implement a process or method as described. The modules or code may be stored on a computer device or may be stored on a memory and may be connected to or downloaded to a computer device. In alternate implementations, the throttling modules may be implemented in hardware.
In summary, described herein are methodologies for improving the performance of an SSD by throttling the incoming requests by having a minimum time interval between actions, the minimum time interval based on the queue depth of the requests. The throttling is accomplished by a throttling queue module stored in memory of an SSD and implemented by a processor. The throttling module can be configured to throttle read requests, write requests, or both read and write requests.
The above specification and examples provide a complete description of the structure and use of exemplary implementations of the invention. The above description provides specific implementations. It is to be understood that other implementations are contemplated and may be made without departing from the scope or spirit of the present disclosure. The above detailed description, therefore, is not to be taken in a limiting sense. While the present disclosure is not so limited, an appreciation of various aspects of the disclosure will be gained through a discussion of the examples provided.
Unless otherwise indicated, all numbers expressing feature sizes, amounts, and physical properties are to be understood as being modified by the term “about,” whether or not the term “about” is immediately present. Accordingly, unless indicated to the contrary, the numerical parameters set forth are approximations that can vary depending upon the desired properties sought to be obtained by those skilled in the art utilizing the teachings disclosed herein.
As used herein, the singular forms “a”, “an”, and “the” encompass implementations having plural referents, unless the content clearly dictates otherwise. As used in this specification and the appended claims, the term “or” is generally employed in its sense including “and/or” unless the content clearly dictates otherwise.
Spatially related terms, including but not limited to, “bottom,” “lower”, “top”, “upper”, “beneath”, “below”, “above”, “on top”, “on,” etc., if used herein, are utilized for ease of description to describe spatial relationships of an element(s) to another. Such spatially related terms encompass different orientations of the device in addition to the particular orientations depicted in the figures and described herein. For example, if a structure depicted in the figures is turned over or flipped over, portions previously described as below or beneath other elements would then be above or over those other elements.
Since many implementations of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended. Furthermore, structural features of the different implementations may be combined in yet another implementation without departing from the disclosure or the recited claims.
