Systems and methods for resource-based command scheduling

Abstract

To provide a system and a method for managing memory resources in a system comprising one or more servers.SOLUTION: A scheduling method of a command for processing by a storage device includes receiving the command from an application and storing the command in a first queue, acquiring information on a first resource set to be managed by the storage device, synchronizing a second resource set on the basis of the information on the first resource set, assigning the second resource set to a first pool and a second pool, determining a condition of the second resource set in the first pool, assigning any one of the second resource set to the command in the first pool on the basis of first determination of the condition, and assigning any one of the second resource set to the command in the second pool on the basis of second determination of the condition.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to storage devices, and more particularly to a system and method for scheduling commands based on hardware resources of a storage device. [Background technology]

[0002] A host computing device provides commands (e.g., read and write commands) for processing by a storage device. The host computing device has specific quality of service (QoS) expectations for the execution of the commands. However, in certain situations, there are insufficient hardware resources to process the commands according to the QoS requirements, causing jitter.

[0003] Therefore, what is needed is a system and method for scheduling commands for processing by a storage device that takes into account the availability of hardware resources of the storage device in order to meet QoS requirements. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] U.S. Patent No. 6,466,559 [Patent Document 2] U.S. Patent No. 6,857,020 [Patent Document 3] US Patent Application Publication No. 2010 / 0146103 [Patent Document 4] US Patent Application Publication No. 2018 / 0143855 [Patent Document 5] US Patent Application Publication No. 2019 / 0114208 [Patent Document 6] US Patent Application Publication No. 2020 / 0104184 Summary of the Invention [Problem to be solved by the invention]

[0005] The present invention has been made in view of the above-mentioned conventional techniques, and an object of the present invention is to provide a system and method for managing memory resources in a system including one or more servers. [Means for solving the problem]

[0006] In order to achieve the above object, one aspect of the present invention provides a method for scheduling commands for processing by a storage device, comprising the steps of receiving a command from an application and storing the command in a first queue, acquiring information about a first resource set managed by the storage device, synchronizing a second resource set based on the information about the first resource set, allocating the second resource set to a first pool and a second pool, determining conditions for the second resource set in the first pool, allocating one of the second resource sets to the command in the first pool based on the first determination of the conditions, and allocating one of the second resource sets to the command in the second pool based on the second determination of the conditions, and the command is stored in a second queue associated with the storage device for processing by the storage device based on the allocation of one of the second resource sets.

[0007] The command may include a data operation from an application running on a host, and processing of the command may perform the data operation on a non-volatile storage medium. The information for the first resource set may include the availability of the first resource set for processing the command. The step of synchronizing the second resource set based on the information for the first resource set may include determining whether a criterion is met, determining the number of the first resource sets available based on whether the criterion is met, and setting the number of the second resource sets available to be the same as the number of the first resource sets available. The conditions may include the expiration of a period of time. The first pool may be shared by the first queue and the second queue, and the second pool may be reserved for the first queue. The second pool may be dynamically determined based on detected conditions. The detected criteria may include identifying a Quality of Service (QoS) requirement for the first queue. The method further includes allocating, by the storage device, one of the first resource sets based on storing a command in the second queue, processing the command, and deallocating, by the storage device, one of the first resource sets based on completion of processing the command. The condition may be the availability of the second set of resources in the first pool.

[0008] In order to achieve the above object, one aspect of the present invention provides a system for scheduling commands for processing by a storage device, comprising a processor and a memory for storing instructions, wherein when the instructions are executed, the processor receives a command from an application and stores it in a first queue, acquires information about a first resource set managed by the storage device, synchronizes a second resource set based on the information about the first resource set, allocates the second resource set to a first pool and a second pool, determines a condition for the second resource set in the first pool, allocates one of the second resource sets to the command in the first pool based on the first determination of the condition, and allocates one of the second resource sets to the command in the second pool based on the second determination of the condition, and the command is stored in a second queue associated with the storage device for processing by the storage device based on the allocation of one of the second resource sets.

[0009] The features, aspects, and advantages of embodiments of the present invention may be more fully understood when considered in conjunction with the following detailed description, claims, and drawings. [Effects of the Invention]

[0010] According to the present invention, QoS requirements can be met by scheduling commands for processing by storage devices taking into account the availability of hardware resources of the storage devices. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a conceptual block diagram of a system for scheduling commands based on current art mechanisms. [Figure 2] FIG. 1 is a block diagram of a resource-based command scheduling system according to one embodiment. [Figure 3]A block diagram illustrating the various abstraction layers of the system of FIG. [Figure 4] FIG. 3 is a conceptual block diagram of FIG. 2 scheduling commands from a first and second queue. [Figure 5] 1 is a process flow diagram for resource-based command scheduling stored in a software queue according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Specific examples of embodiments of the present invention will be described in detail below with reference to the drawings. Herein, like reference numerals refer to like elements. However, the present invention may be embodied in various forms and should not be construed as being limited to the embodiments described below. Rather, the embodiments are provided as examples so that the present invention will be thorough and complete and will fully convey the aspects and features of the present invention to those of ordinary skill in the art. Therefore, processes, elements, and techniques that are not necessary for a complete understanding of the aspects and features of the present invention may not be described. Unless otherwise specified, like reference numerals may not be repeated to represent like elements throughout the drawings and the following description. Note that in the drawings, the relative sizes of elements, layers, and regions may be exaggerated and / or simplified for clarity.

[0013] Typically, a storage device has a limited number of hardware resources for processing commands from a host computing device, such as a hardware queue and tokens used to schedule commands for processing. The size of the hardware queue and the number of associated tokens vary depending on the implementation and are dependent on the performance and QoS requirements of the storage device.

[0014] A device driver that interacts with a storage device allocates software resources to commands to be processed. For example, the software resources are software queues and associated tokens. The depth of the software queues and associated tokens is arbitrary and may exceed the depth of the hardware queues and associated tokens. This allows the device driver to schedule more commands than the hardware resources available on the storage device. In such a situation, commands that are scheduled by the device driver but for which hardware resources are unavailable are delayed in processing, resulting in high jitter.

[0015] 1 is a conceptual block diagram of a system for scheduling commands based on current technology mechanisms. The system includes a device driver 100 that submits commands for processing by a storage device 102. The device driver 100 includes various software queues (104-108) that store commands submitted by one or more applications on a host processing device. For example, Q1 (104) is a deep write queue configured to store write commands, while Q2 (106) is a shallow read queue configured to store read commands. To communicate the commands to the storage device 102 for processing, the commands use software resources (e.g., the software queues (104-108) and a token 110).

[0016] Similar to device driver 100, storage device 102 includes one or more hardware queues (112-114) configured to store commands submitted by device driver 100. For example, hardware queue 112 is configured to store commands fetched from Q1 (104) and Q2 (106). Commands in hardware queue 112 use hardware resources 116 (e.g., hardware tokens). Commands that have hardware resources 116 assigned to them are scheduled for processing by the storage device.

[0017] The various software queues (104-108) configured within the device driver 100 are intended to provide QoS for command processing. For example, by separating write and read commands into separate queues (104 and 106) and applying a scheduling algorithm such as round robin, read commands in Q2 (106) are generally serviced within a predictable time window. However, in some situations, even though commands expected to be processed in Q2 (106) are queued up, the commands in Q2 (106) may not be serviced as expected due to resource conflicts within the storage device.

[0018] To illustrate this point, consider an example in which Q1 (104) queues up 1,000 write commands and Q2 (106) queues up 10 read commands. Assume that the 1,000 write commands are submitted to the storage device 102 for processing using 1,000 software tokens 110. However, according to this example, the storage device 102 is assigned only 768 hardware tokens 116. Therefore, the storage device 102 fetches up to 768 write commands from Q1 (104) for processing, ensuring that all 768 hardware tokens 116 are used. Considering that the write commands use all the hardware tokens 116, leaving more write commands to be processed that are assigned software tokens 110, it is not possible for the read commands in Q2 (106) to be processed during the expected time window. Therefore, it is not possible to meet the QoS requirements for Q2 (106).

[0019] An embodiment of the present invention relates to a system and method for resource-based scheduling of commands that takes into account the availability of hardware resources of a storage device for submitting commands for processing. According to one embodiment, the hardware resources of a storage device are monitored to match / synchronize with the software resources. Once synchronized, the software resources are allocated to commands as desired. For example, the allocation of software resources to commands is based on QoS determined as specified in a service level agreement (SLA). While QoS is used as an example of a criterion used to determine the allocation of software resources, one of ordinary skill in the art should recognize that other criteria (e.g., user preference) may also be considered.

[0020] In one embodiment, the device driver 100 includes a software token manager configured to identify hardware resource information and update software resource information accordingly. In one embodiment, the software token manager updates a number of available software resources to match the number of available hardware resources. A certain portion of the available software resources is reserved for one or more queues of the device driver, for example, based on QoS expectations. The remaining software resources are part of a shared pool. In one embodiment, the software token manager allocates software tokens / resources from the shared pool to commands in the software queues to submit the commands to the storage device for processing. In one embodiment, if the software resources allocated to a command in a queue are not present in the shared pool, the software token manager accesses the software tokens reserved for the queue and allocates one of the reserved tokens to the command. The reserved tokens ensure that the command is processed in a timely manner to meet QoS expectations.

[0021] 2 is a block diagram of a resource-based command scheduling system according to one embodiment. The system includes a host computing device 200 coupled to a storage device 202 via a storage interface bus 204. For example, the storage device 202 may be a non-volatile storage device such as a solid state drive (SSD), an Ethernet solid state drive (eSSD), a universal serial bus (USB) drive, a security digital (SD) card, an embedded multi-media controller (eMMC), a universal flash storage (UFC), etc. For example, the storage interface bus 204 may be a Peripheral Component Interconnect Express (PCIe) bus, an Ethernet (registered trademark), or a Compute Express Link (CXL). In one embodiment, the host computing device 200 transmits and receives data to and from the storage device 202 via the storage interface bus 204 using a storage interface protocol. For example, the storage interface protocol may be non-volatile memory express (NVMe) or other similar protocols that use queues to store commands to be processed.

[0022] In one embodiment, host computing device 200 includes one or more applications 206 executing at an application layer of host computing device 200. One or more applications 206 are software applications stored in a host memory area for execution by a processor. In one embodiment, one or more applications 206 send commands to storage device 202 for processing. For example, one or more applications issue read commands to read data from storage device 202, write commands to write data to storage device 202, and / or other input / output (I / O) requests.

[0023] In one embodiment, the host computing device 200 includes a device driver 208 configured to interface with the storage device 202. In one embodiment, the device driver 208 is embodied as software instructions stored in host memory and executed by a processor. The device driver 208 includes one or more queues (212a, 212b) (hereinafter, software queues 212). For example, the software queue 212 includes one or more submit queues and completion queues. The submit queues are configured to store commands / requests submitted by the various applications 206. The completion queues are configured to store completion messages for commands / requests processed by the storage device 202.

[0024] One or more software queues 212 (e.g., submit queues) are dedicated to storing particular types of commands from host computing device 200. For example, one queue is dedicated to storing read commands from an application, while another queue is dedicated to storing write commands. In one embodiment, particular QoS requirements are imposed on software queues 212 based on one or more SLAs. For example, a particular number of commands in software queue 212 are expected to be processed within a given time. Other QoS requirements are associated with other software queues 212.

[0025] The device driver 208 further includes a software token manager 210 configured to manage software resources that significantly impact the scheduling of commands to be processed. For example, the software resources are software tokens and / or queues 212. In one embodiment, the software token manager 210 is configured to determine software availability based on information from a storage device and allocate available tokens to commands stored in the software queues 212. The software token manager 210 is configured to maintain availability information per controller and / or token type basis. The allocated tokens are from a shared pool, if available, or from a pool reserved for any queue, for commands submitted to that queue.

[0026] In one embodiment, the storage device 202 includes a host interface layer (HIL) 214 for interfacing between the host computing device 200 and the device control subsystem 216. The host interface 214 includes, without limitation, one or more controllers 218 and one or more queues (220a-220c) (hereinafter, hardware queues 220). For example, the depth of the hardware queues 220 varies depending on the processing capabilities of the storage device 202. In one embodiment, different queues are maintained for different types of processing by the storage device 202. For example, one hardware queue stores commands for processing by a hardware acceleration engine, while another hardware queue stores commands for processing via firmware.

[0027] The controllers 218 may be implemented using one or more processors (e.g., a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC)). Any one of the one or more controllers 218 may be associated with one or more hardware queues 220. Any one of the one or more controllers 218 may be configured to manage and allocate hardware resources to commands submitted for processing in the software queue 212. For example, the hardware resources may be hardware tokens and / or queues 220.

[0028] In one embodiment, one or more controllers 218 are configured to fetch I / O requests / commands from one or more software queues 212 and store the fetched requests in one or more hardware queues 220 corresponding to the one or more controllers 218. In some embodiments, the requests are fetched and submitted by the device driver 208.

[0029] Commands stored in hardware queues 220 are assigned to hardware tokens for processing. In one embodiment, different types of hardware tokens are maintained and assigned depending on the type and number of hardware queues 220. For example, a first type of hardware token is assigned to a first hardware queue 220a dedicated for processing by a hardware acceleration engine, while a second type of hardware token is assigned to a second hardware queue 220b dedicated for processing via firmware.

[0030] The number of available hardware tokens that can be assigned to commands in different queues 220 is dependent on the number of commands already present in the queue. In one embodiment, tokens are assigned by the controller 218 based on the type of hardware queue. In one embodiment, hardware tokens are automatically assigned to store commands in one or more hardware queues 220. Commands that have assigned hardware tokens are scheduled for processing by the device control subsystem 216.

[0031] In one embodiment, device control subsystem 216 interacts with controller 218 to execute commands requested by application 206. Device control subsystem 216 includes, without limitation, one or more processors 222 and one or more media interfaces. One or more processors 222 are configured to process commands to or from controller 218 and execute computer-readable instructions to manage the operation of storage device 202. For example, the computer-readable instructions executed by one or more processors 222 are firmware code.

[0032] For example, one or more processors 222 are configured to interact with controller 218 to receive write or read commands to or from NVM media 226. One or more processors 222 interact with NVM media 226 via media interface 224 to perform write or read operations. NVM media 226 includes one or more types of non-volatile memory (e.g., flash memory).

[0033] In one embodiment, storage device 202 further includes internal memory 228 for short-term or temporary storage during execution of storage device 202. Internal memory 228 may include dynamic random access memory (DRAM), static random access memory (SRAM), and / or data tightly coupled memory (DTCM). For example, internal memory 228 may be used to store hardware queue 220.

[0034] Figure 3 is a block diagram illustrating various abstraction layers of the system of Figure 2. For ease of explanation, Figure 3 will be described below with reference to Figure 2. The abstraction layers of the host computing device 200 include an application layer 300 and a device driver layer 302. The application layer 300 is configured to generate commands based on I / O requests issued by the application 206. The commands generated by the application layer 300 conform to the storage interface protocol of the storage interface bus 204 used to communicate with the storage device 202.

[0035] In one embodiment, the device driver layer 302 includes a software queue 212 and a software token manager 210. For example, commands generated by the application layer 300 are stored in the queue 212 of the device driver 208 based on the command type. The software token manager 210 determines the availability of software tokens based on information from the storage device 202 and allocates available tokens to commands stored in the software queue 212. If all tokens are allocated, service is denied. In one embodiment, commands are allowed to be queued in the software queue 212, but if there are no available tokens, the commands are not submitted to the hardware queue 220 for processing.

[0036] In one embodiment, storage device 202 includes a storage layer 304 that includes various sublayers, including host interface layer 214 as well as other layers for interfacing with NVM media 226, such as flash translation layer 306 and flash interface layer 308. NVM media 226 is included in storage layer 304 as flash media 310.

[0037] 4 is a conceptual block diagram of FIG. 2 scheduling commands from the first and second queues. Software token manager 210 manages information on available software tokens 400, including information on the number of software tokens available in a shared pool and information on the number of software tokens available in a reserved pool. In one embodiment, software token manager 210 maintains token availability information for queues 112 managed by any one of various controllers 218 of storage device 202. If storage device 202 includes multiple controllers 218, software token manager 210 maintains multiple sets of token availability information for queues managed by multiple controllers 218.

[0038] The software token manager 210 also maintains information about the availability of different types of tokens in a given set of available tokens. For example, different tokens may be assigned depending on whether a command is to be processed by a hardware acceleration engine or via firmware. The software token manager 210 is configured to monitor the availability of tokens for hardware acceleration processing and tokens for firmware processing and assign the appropriate type of token to a command based on availability.

[0039] In one embodiment, a certain number of software tokens are reserved in a reservation pool for each software queue 212. The reservation is also based on different token types. The number of software tokens reserved for a software queue may be the same or different for different queues and token types.

[0040] In one embodiment, the number of tokens reserved for a queue 212 (which should be understood to include token type) is dynamically determined based on one or more criteria. For example, the criteria may be usage statistics and / or SLA requirements. In one embodiment, the software token manager 210 is configured to identify the SLA requirements for the queue 212 (e.g., required I / O per second, bandwidth, etc.) and dedicate a portion of the available software tokens 400 based on the SLA requirements. For example, if the bandwidth requirement for a queue is BW1 and the total available bandwidth is BW, the number of reserved tokens is based on the ratio of BW1 to BW (BW1 / BW).

[0041] In some embodiments, software token manager 210 is configured to collect historical information related to usage of the software queues, including duration of usage, amount of usage, and applications responsible for usage, and dynamically adjust the number of tokens reserved in the queues based on the historical information. In this manner, when a particular period of predicted high usage of any one of queues 212 arrives, software token manager 210 is configured to reserve more tokens in the queues based on the prediction.

[0042] In some other embodiments, software token manager 210 receives information from various applications 206 regarding the number and type of commands expected from the applications 206 (e.g., within the next millisecond). Software token manager 210 dynamically adjusts the number of reserved tokens for the affected queues based on the information. For example, if a first queue is expected to be more heavily utilized than a second queue, the number of reserved tokens for the first queue will be proportionally greater than the number of reserved tokens for the second queue during a given period.

[0043] For example, the total number of available software tokens 400 identified by the software token manager 210 for a particular controller 218 in a given time window is 768. The number of available software tokens 400 corresponds to the total number of hardware tokens 402 associated with the particular controller 218. The software token manager 210 is configured to reserve a certain number of available software tokens 400 for a reservation pool. For example, 10% (e.g., 77) of the available tokens are allocated to the reservation pool, and the remaining 691 tokens are allocated to the shared pool. If a first one of the software queues Q1 (212a) has 691 commands stored and a second one of the software queues Q2 (212b) has two commands stored, the software token manager 210 is configured to schedule the commands in Q1 (212a) for processing based on a scheduling algorithm (e.g., round robin, weighted round robin, fixed priority, etc.). The commands in Q1 (212a) are allocated 691 available software tokens in the shared pool so that the commands can be submitted to the associated hardware queue 220a for processing. The 691 commands submitted to the hardware queue 220a use 691 hardware tokens from the pool of available hardware tokens 402.

[0044] The two commands in Q2 (212b) are next selected for processing by the scheduling algorithm. Assuming that the 691 tokens allocated to the commands in Q1 (212a) have not yet been released, there are no more tokens in the shared pool available to allocate to the commands in Q2 (212b). However, if 77 tokens are allocated to the reserved pool and divided among the various software queues 212, two of the software tokens in the reserved pool allocated to Q2 (212b) are allocated to Q2 (212b). In this regard, even though there are no more software tokens available in the shared pool, the two commands in Q2 (212b) are subsequently submitted to the corresponding hardware queue 220a for processing using the reserved software tokens, thereby maintaining scheduling fairness. The two commands submitted to the hardware queues use two tokens from the available hardware tokens, thereby reducing the total number of available hardware tokens 402 to 75.

[0045] In one embodiment, information about the updated hardware tokens is disclosed to the software token manager 210 via a command or via an application programming interface (API) 404. The information is then used by the software token manager 210 to synchronize the software tokens 400. Information about the updated tokens is periodically (regularly or irregularly) pushed to the software token manager 210 or fetched by the software token manager 210 from the storage device 226. For example, the controller 218, upon completing processing of one or more commands by the processor 222, submits a completion message to the device driver 208 using an interrupt signal, which in turn places one or more corresponding hardware tokens 402 in a deallocated / available state. The completion message is sent to the software token manager 210 and / or submitted to a completion queue of one or more software queues 212. Once submitted to the completion queue, the software token manager 210 is configured to periodically fetch the completion message from the completion queue and update the available software tokens 400 accordingly. For example, if one or more completion messages related to five processed commands are received by software token manager 210, software token manager 210 deallocates the five corresponding software tokens previously allocated to the commands.

[0046] 5 is a process flow diagram for resource-based command scheduling stored in software queue 212 according to one embodiment. It should be understood that the order of the process steps is not fixed, but may be changed to any order recognized by one of ordinary skill in the art. For ease of explanation, FIG. 5 below will be described with reference to FIG. 2.

[0047] The processing process begins at step 500, when software token manager 210 receives a request to the software token for a command in any one of software queues 212. In some embodiments, the placement of the command in the queue is considered a request to the software token. The request includes an identifier of the queue that stores the command and the token type.

[0048] In step 502, the software token manager 210 determines whether information for an available software token is updated. For example, a software token is updated based on meeting criteria such as expiration or determining that there are no software tokens available in the shared pool and reserved pool when a request is received.

[0049] If the token availability information is to be updated, then in step 504, the software token manager 210 obtains information about the available hardware tokens and synchronizes the available software tokens to match the available hardware tokens. For example, this may include receiving an interrupt signal from one or more controllers 218 to receive the update information, or querying one or more completion queues for information about commands completed by the storage device 202. In one embodiment, the update information includes token type information, allowing the software token manager 210 to synchronize one or more available software tokens for each token type.

[0050] In step 506, the software token manager 210 reserves a specific number of available tokens per queue and token type. For example, if the total number of available tokens is 1000, the software token manager 210 allocates 10% of the available tokens to the first queue and 5% of the available tokens to the second queue. The ratio can be fixed (e.g., manually configured) or dynamically determined. Other ratios are possible. For example, the number of reserved tokens is based on the expected utilization of the queue, queue type, and / or QoS expectations.

[0051] At step 508, the remaining available tokens are allocated as shared tokens in a shared pool.

[0052] At step 510, a determination is made as to whether a shared token in the shared pool satisfies a condition. For example, the condition is the availability of a shared token assigned to a command. If the condition is met (for example), an available token from the shared pool is assigned to the command at step 512. The command is submitted / fetched by the controller 218 for processing, which triggers the use of a hardware token.

[0053] In step 514, the software token manager 210 decrements the number of available software tokens in the shared pool by one.

[0054] Referring back to step 510, if it is determined that the shared token does not meet the condition (No) (e.g., there are no shared tokens in the shared pool), the software token manager 210 determines whether there are any reserved tokens for the token type and queue associated with the command in step 516. If there are (Yes), then an available token in the reserved pool for the token type and queue is assigned to the command in step 518.

[0055] In step 520, the software token manager 210 decrements the number of reserved tokens for the token type and queue by one.

[0056] If a command does not have a shared or reserved token assigned to it, the command will remain in the queue unserviced until a software token becomes available again.

[0057] In some embodiments, the resource-based command scheduling system and method described above are implemented with one or more processors. Here, a processor refers to one or more processors and / or one or more processing cores. The one or more processors may be hosted on a single device or distributed across one or more devices (e.g., via a cloud system). For example, processors include application-specific integrated circuits (ASICs), general-purpose or special-purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices such as field programmable gate arrays (FPGAs). In the processors described herein, each function is performed by hardware configured to perform that function, i.e., hard-wired, or by more general-purpose hardware such as a CPU configured to execute commands stored in a non-transitory storage medium (e.g., memory). The processors may be fabricated on a single printed circuit board (PCB) or distributed across multiple interconnected PCBs. The processor includes other processing circuits, for example an FPGA and a CPU, which are two processing circuits interconnected on a PCB.

[0058] Although terms such as "first," "second," and "third" are used to describe various elements, components, regions, layers, and / or sections, these elements, components, regions, layers, and / or sections are not limited to these terms. These terms are used only to distinguish one element, component, region, layer, or section from another element, component, region, layer, or section. Thus, a first element, component, region, layer, or section discussed herein could be referred to as a second element, component, region, layer, or section without departing from the spirit and scope of the present invention.

[0059] The terms used herein are intended to describe specific embodiments and are not intended to limit the concept of the present invention. As used herein, the terms "substantially," "about," and similar terms are used as terms of approximation, not as terms of degree, to account for inherent deviations in measurements or calculations recognized by those of ordinary skill in the art.

[0060] As used herein, words used in the singular are intended to include the plural unless the context clearly dictates otherwise. As used herein, the terms "comprises" and / or "comprising" specify the presence of the stated features, integers, steps, operations, elements, and configurations, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, configurations, and / or groups thereof. As used herein, "and / or" includes any and all combinations of one or more of the associated list items. Expressions such as "at least one or more," when preceding listed elements, modify the entire list element, but not the individual list elements. Furthermore, when describing embodiments of the present invention, the term "may" means "one or more embodiments of the present invention." Additionally, the term "exemplary" is intended to indicate example or illustration. As used herein, the terms "use," "using," and "used" are considered synonymous with the terms "utilize," "utilizing," and "utilized," respectively.

[0061] When an element or layer is referred to as being "located on," "connected," "coupled," or "adjacent," it refers to being directly disposed on, connected to, coupled to, or adjacent to another element or layer, or there may be one or more intervening elements or layers present. In contrast, when an element or layer is described as being "directly located on," "directly connected," "directly coupled," or "immediately adjacent" to another element or layer, it can be understood that there are no intervening elements or layers present.

[0062] Any numerical range recited herein is intended to include all subranges of the same numerical precision subsumed within the recited range. For example, a range of "1.0 to 10.0" includes all subranges between a minimum value of 1.0 and a maximum value of 10.0, i.e., subranges with minimum values ​​equal to or greater than 1.0 and maximum values ​​equal to or less than 10.0 (e.g., 2.4 to 7.6). Any maximum numerical limitation recited herein is intended to include all lower numerical limitations subsumed therein, and any minimum numerical limitation recited herein is intended to include all higher numerical limitations subsumed therein.

[0063] Although the embodiments of the present invention have been described in detail above with reference to the drawings, the present invention is not limited to the above-described embodiments and can be modified in various ways without departing from the technical concept of the present invention. [Explanation of symbols]

[0064] 100, 208 Device Driver 102, 202 Storage device (SSD) 104, 106, 108, 212 Software queue (Q1~Q4) 110 Software (S / W) Tokens 112, 114, 220 Hardware Queue 116 Hardware (H / W) Token (Hardware Resource) 200 Host Computing Device 204 Storage Interface Bus 206 Applications 210 Manager 212a, 212b Software Queue 214 Host Interface Layer (HIL) 216 Equipment Control Subsystem 218 Controller 220a, 220b, 220c Hardware queues 222 processors 224 Media Interface 226 NVM Media 228 internal memory 300 Application Layer 302 Device Driver Layer 304 Storage Layer 306 Flash Transformation Layer 308 Flash Interface Layer 310 Flash Media 400 Available Software Tokens 402 Hardware Token 404 API

Claims

1. 1. A method for scheduling commands for processing by a storage device, comprising: receiving a command from an application and storing the command in a first software queue; acquiring information about hardware resources managed by the storage device; updating the software token based on the information about the hardware resource; Allocating the software tokens to a shared pool and a reserved pool; determining the number of software tokens available in the shared pool; if there are software tokens available in the shared pool, assigning one of the software tokens allocated to the shared pool to the command; if there are no software tokens in the shared pool or reserved pool allocated to the command, maintaining the command in the first software queue; the shared pool is shared by the first software queue and the second software queue; a first portion of the specified number of available software tokens in the reservation pool is reserved for a first queue; a second portion of the specified number of available software tokens in the reservation pool is reserved for a second queue; The method of claim 1, wherein the command is stored in a hardware queue associated with the storage device for processing by the storage device when one of the software tokens is assigned to the shared pool.

2. the command includes a data operation from the application running on the host; The method further includes processing the command by the storage device; 10. The method of claim 1, wherein the processing includes performing the data operation on a non-volatile storage medium.

3. 2. The method of claim 1, wherein the information about the hardware resources includes availability of the hardware resources to process the command.

4. The step of updating the software token comprises: determining that a criterion is satisfied; If the criteria are met, determining the number of available resources in the hardware resource; 2. The method of claim 1, further comprising: setting the number of available resources in the software token to be the same as the number of available resources in the hardware resource.

5. The method of claim 4 , wherein the criteria includes the expiration of a time period.

6. 10. The method of claim 1, wherein the reservation pool is dynamically determined based on detected criteria.

7. 7. The method of claim 6, wherein the detected criteria includes identifying a Quality of Service (QoS) requirement for the first software queue.

8. The storage device allocating one of the hardware resources if the command is stored in the hardware queue; processing the command; 2. The method of claim 1, further comprising: deallocating one of the hardware resources when processing of the command is complete.

9. 1. A system for scheduling commands for processing by a storage device, comprising: a processor; a memory for storing instructions; When the instruction is executed, the processor: receiving a command from an application and storing it in a first software queue; acquiring information about hardware resources managed by the storage device; updating the software token based on the information about the hardware resource; Allocating the software tokens to a shared pool and a reserved pool; determining the number of software tokens available in the shared pool; If there are software tokens available in the shared pool, assign one of the software tokens allocated to the shared pool to the command; configured to maintain the command in the first software queue if there are no software tokens in the shared pool or reserved pool allocated to the command; the shared pool is shared by the first software queue and the second software queue; a first portion of the specified number of available software tokens in the reservation pool is reserved for a first software queue; a second portion of the specified number of available software tokens in the reservation pool is reserved for a second queue; The system, wherein the command is stored in a hardware queue associated with the storage device for processing by the storage device when one of the software tokens is allocated to the shared pool.

10. the command includes a data operation from the application running on the host; the storage device is configured to participate in processing the command; 10. The system of claim 9, wherein the processing includes performing the data operation on a non-volatile storage medium.

11. 10. The system of claim 9, wherein the information about the hardware resources includes availability of the hardware resources to process the command.

12. When the instructions that cause the processor to update the software token are executed, the processor: Determined to meet the criteria, If the criteria are met, determining the number of available resources in the hardware resource; The system of claim 9, configured to set the number of available resources in the software token to be the same as the number of available resources in the hardware resource.

13. The system of claim 12 , wherein the criteria includes the expiration of a time period.

14. 10. The system of claim 9, wherein the reservation pool is dynamically determined based on detected criteria.

15. 15. The system of claim 14, wherein the detected criteria includes identifying a Quality of Service (QoS) requirement for the first software queue.

16. The storage device allocating one of the hardware resources when the command is stored in the hardware queue; Process the command; 10. The system of claim 9, further configured to send a signal to deallocate one of the hardware resources when processing of the command is complete.

Images