I / O completion polling for low-latency storage devices

Abstract

The I / O processing system includes: receiving a request from a user mode application to perform an I / O operation, providing the request to a storage device, scheduling an operating system delayed procedure call to determine whether the storage device has completed the I / O operation, executing the scheduled delayed procedure call to determine whether the storage device has completed the I / O operation, and sending a return corresponding to the completed I / O operation to the user mode application.

Description

Background Art

[0001] Storage devices currently utilize interrupts to handle I / O requests received from user-mode applications. For example, after completing a requested I / O operation, the storage device generates an interrupt that is sent to its host computer. The host computer's operating system receives the interrupt and dispatches it to a kernel-mode interrupt handler that identifies the corresponding I / O request and completes the request by providing an appropriate response to the requesting application.

[0002] In systems using modern solid-state drives or other low-latency storage devices, the proportion of I / O processing time attributed to the above process may be unacceptable, especially under intensive I / O workloads. These problems are exacerbated in virtualized environments where interrupts generated by storage devices must be delivered to the physical CPU, the hypervisor layer, and then to the virtual CPU.

[0003] Furthermore, a low-latency storage device may be able to deliver its I / O interrupts only to a limited number of CPUs. Therefore, the CPUs receiving the I / O interrupts may become saturated before the storage device reaches its maximum throughput.

[0004] It is desirable for the system to process incoming I / O requests without using hardware interrupts and to provide both reduced latency and increased throughput. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 A system implementing I / O completion polling in accordance with some embodiments is illustrated.

[0006] Figure 2 is a flow diagram of a process for providing I / O completion polling according to some embodiments.

[0007] Figure 3 Illustrated are driver queues and corresponding device queues according to some embodiments.

[0008] Figure 4 The receipt of an I / O request and providing the I / O request to a storage device are illustrated in accordance with some embodiments.

[0009] Figure 5 Illustrated is the scheduling of delayed procedure calls in accordance with some embodiments.

[0010] Figure 6 The operation of a delayed procedure call is illustrated in accordance with some embodiments.

[0011] Figure 7 Operation of a storage driver to reschedule a delayed procedure call is illustrated in accordance with some embodiments.

[0012] Figure 8 Completion of an I / O operation is illustrated in accordance with some embodiments.

[0013] Fig. 9 The operation of a delayed procedure call is illustrated in accordance with some embodiments.

[0014] Fig.10 Completion of an I / O request is illustrated in accordance with some embodiments.

[0015] Fig.11 A system is illustrated that includes I / O requests received from two applications and includes two deferred procedure call queues in accordance with some embodiments.

[0016] Fig.12 A host computing device hosting a plurality of virtual machines is illustrated in accordance with some embodiments.

[0017] Fig.13 A computing system in accordance with some embodiments is illustrated. DETAILED DESCRIPTION

[0018] The following description is provided to enable those skilled in the art to make and use the described embodiments. However, various modifications will still be apparent to those skilled in the art.

[0019] Conventional I / O processing protocols have a technical problem of excessive processing overhead when used in conjunction with low-latency storage devices. Some embodiments provide a technical solution to this technical problem by scheduling delayed procedure calls to poll for I / O completion. This solution can reduce I / O latency and provide consistent I / O throughput from low-latency storage devices on a host machine or in a virtualized environment.

[0020] According to some embodiments, the delayed procedure call is scheduled to run in the context of the requested I / O operation. Therefore, the delayed procedure call does not require a dedicated thread and is more efficient than a multi-threaded approach.

[0021] Some embodiments may reduce CPU usage by scheduling deferred procedure calls only if there are pending I / O requests to a storage device.

[0022] According to some embodiments, the scheduled delayed procedure call is a threaded delayed procedure call. The threaded delayed procedure call runs at the passive IRQL level and may therefore be preempted by a higher-level task. Since the operating system is aware of the threaded delayed procedure call operation, tasks at the same priority level can be scheduled to other CPUs as needed. The use of threaded delayed procedure calls can therefore improve the system integration of the present embodiment.

[0023] Scheduling the delayed procedure call on the CPU from which the I / O request is received can effectively limit the I / O submission queue depth to 1, thereby reducing the single-threaded, high-queue-depth I / O throughput from the application. Therefore, some embodiments schedule the delayed procedure call on the paired multi-threaded processor of the I / O initiating CPU. As a result, embodiments can achieve an improved balance between low latency and high throughput in different deployment scenarios.

[0024] Figure 1 System 100 is illustrated in accordance with some embodiments. Embodiments are not limited to system 100 or any particular implementation described herein. System 100 includes a storage device, which may include any electronic storage medium or medium that is or becomes known. In some embodiments, storage device 130 includes one or more non-volatile random access memory devices. Storage device 130 may exhibit I / O latency and throughput characteristics similar to volatile random access memory, and significantly more advantageous than the I / O latency and throughput characteristics provided by disk-based storage.

[0025] The storage device 130 is illustrated as communicating with the storage driver 110. The storage driver 110 is illustrated as executing the kernel mode of the host operating system. The storage driver 110 includes executable program code that provides an interface between the storage device 130 and other software components within or executed by the operating system. In the operating system, the storage driver 110 may include a single storage driver or multiple layers of storage drivers.

[0026] Application 120 may include any user mode software application executed on a host operating system. According to some embodiments, application 120 includes a user mode application executed in a virtual machine or a host operating system. Application 120 may request I / O operations and receive indications of completed I / O operations from storage driver 110.

[0027] The operation of the system 100 according to some embodiments is now briefly described. The application 120 may send an I / O request to read data from or write data to the storage device 130. Due to the association between the storage driver 110 and the storage device 130, the I / O request is received by the storage driver 110. In some embodiments, the I / O request is received from the application 120 by an operating system component such as an I / O manager before being passed to the storage driver 110. In this regard, the I / O request may be passed through several drivers and / or components of the operating system stack before reaching the storage driver 110.

[0028] The storage driver 110 provides I / O requests to the storage device 130 via a protocol known in the art and described in detail below. The storage driver 110 also sends a request to the delayed procedure call scheduler 115 (kernel component) to schedule a delayed procedure call. The scheduled delayed procedure call is added to the end of the DPC queue to be executed by the operating system kernel in kernel mode. In particular, when the operating system drops to the IRQL of the scheduled delayed procedure call, the kernel executes any delayed procedure call in the queue until the queue is empty or until an interrupt with a higher IRQL occurs.

[0029] The scheduled delayed procedure call invokes a routine to determine whether the requested I / O operation has been completed. If the operation is completed, the request is completed to the application 120. If not, or if another I / O request is pending for the storage device 130, the delayed procedure call is scheduled again as described above. Figure 1 A scenario is illustrated in which a delayed procedure call is first executed to determine that the I / O operation is not completed, is rescheduled, and then executed to determine that the I / O operation has completed. The request is then completed to the application 120, as shown by the arrow marked "return" from the storage driver 110 to the application 120.

[0030] Figure 2 A flowchart of a process 200 according to some embodiments is included. In some embodiments, a processing unit (e.g., one or more processors, processing cores, processor threads) of a computing device (e.g., a computer server) executes a software program code to cause the device to perform process 200. Process 200 and all other processes mentioned herein can be implemented in a processor executable program code, which is read from one or more of non-transient computer-readable media such as a hard disk, a flash drive, etc., and then stored in a compressed, uncompiled and / or encrypted format. In some embodiments, a hard-wired circuit device can be used instead of a program code or in combination with a program code to implement a process according to some embodiments. Therefore, the embodiments are not limited to any particular combination of hardware and software.

[0031] Initially, at S210, a request for an I / O operation (i.e., an I / O request) is received from an application. According to some embodiments, the request is sent from a user mode application such as application 120, received by an operating system component, and routed to a device driver stack corresponding to a hardware device associated with the I / O request. In this example, it will be assumed that the I / O request is associated with storage device 130, and is therefore routed to and received by storage driver 110 at S210.

[0032] Next, at S220 , the I / O request is provided to the storage device. According to some embodiments, providing the I / O request to the storage device 130 includes writing the I / O request to a submission queue of the storage device 130 .

[0033] Figure 3 The association of submission queues according to some embodiments is illustrated. During initialization of the storage drive 110 (e.g., at system power-up), a submission queue 112 (i.e., a memory buffer) is allocated for the storage drive 110. In addition, each of the queues 112 is associated with one of the submission queues 102 (i.e., hardware registers) created within the storage device 130. Similarly, a completion queue 114 is allocated for the storage drive 110, and each of the completion queues 114 is associated with one of the completion queues 104 created within the storage device 130. Each of the queues 102, 104, 112, and 114 includes four queues, i.e., each illustrated box represents a different queue.

[0034] According to some embodiments of S220 , the I / O request is received at the submission queue 112 of the storage driver 110 and then written to the corresponding submission queue 102 (ie, device memory) of the storage device 130 . Figure 4 S210 and S220 are illustrated according to some embodiments.Writing the request into the corresponding submission queue 102 of the storage device 130 and signaling the storage device 130 that the request is ready for execution will trigger the storage device 130 to start executing the requested I / O operation.

[0035] In some embodiments, the submission queue 112 (and resulting submission queue 102) to which an I / O request is written depends on the CPU from which the I / O request is received. For example, a CPU ID-and-submission queue table can be used to determine the submission queue 102 to which a request will be written. When a request is received from a CPU, the table is checked to determine the submission queue associated with the ID of the CPU. If there is no table entry for the CPU ID, an entry is created. The association of a submission queue with a particular CPU can assist in load balancing I / O requests in all submission queues 102.

[0036] Next, at S230, a request is made to schedule a delayed procedure call. Figure 5 As shown in , the storage driver 110 may send a request to the delayed procedure call scheduler 115 to schedule a delayed procedure call to determine whether the requested I / O operation is completed. The request may indicate the submission queue 112 to which the I / O request is written.

[0037] The scheduled delayed procedure call is added to the end of the DPC queue and will be executed by the operating system kernel in kernel mode when the operating system drops to the IRQL of the scheduled delayed procedure call. In some embodiments, the scheduled delayed procedure call may include a threaded delayed procedure call running at a passive IRQL level. This arrangement can reduce the use of the CPU by I / O processing while maintaining appropriate latency and throughput.

[0038] According to some embodiments, the request to schedule a delayed procedure call may also instruct a simultaneous multithreaded processor to execute the delayed procedure call. The simultaneous multithreaded processor may be determined based on a mapping between a CPU and a paired simultaneous multithreaded processor. Thus, the simultaneous multithreaded processor indicated in the request to schedule a delayed procedure call may be determined based on the mapping and the CPU from which the I / O request was received. A separate delayed procedure call queue may be established for each CPU / simultaneous multithreaded processor.

[0039] The process loops at S240 until the scheduled delayed procedure call is determined to be executed based on the CPU state, the queue and the queue position. At S250, the delayed procedure call is executed to determine whether the requested I / O operation is completed. Figure 6 S250 according to some embodiments is illustrated. As shown, the delayed procedure call checks the completion queue 114 associated with the original submission queue 112. If the checked completion queue 114 does not indicate that the requested I / O operation is complete, the process returns to S230 to schedule the same delayed procedure call again, such as Figure 7 as shown in .

[0040] Figure 8 An I / O completion is illustrated in accordance with some embodiments. In response to completing the I / O request, the storage device 130 writes to the corresponding completion queue 104. The storage device 130 also writes an entry to the corresponding completion queue 114 indicating to the operating system that the I / O request is complete.

[0041] Returning to process 200, it is assumed that the rescheduled delayed procedure call is executed again at S250, such as Fig. 9 At this point, due to the entry in the completion queue 114, it is determined that the requested I / O operation is completed. Accordingly, then at S260, the I / O request is completed for the requesting application, as shown in FIG. Fig.10 As is known in the art, the manner in which a request is completed (ie, what is “returned”) by a request application may be based on an entry written to completion queue 114 .

[0042] In some embodiments, S260 may also include determining whether the current submission queue is empty (i.e., whether one or more other I / O requests associated with the same CPU are pending). If so, the process may return to S230 to schedule another delayed procedure call. In such an embodiment, process 200 terminates only when there are no pending I / O requests in the submission queue. Accordingly, each completion queue only needs to schedule one delayed procedure call. Therefore, if an I / O request is received at a submission queue and a delayed procedure call has been scheduled for a completion queue corresponding to the submission queue, the delayed procedure call is not scheduled at S230.

[0043] Although S220 and S230 are described and illustrated as being performed sequentially, these steps may be performed in reverse order or in any degree of parallelism.

[0044] In some embodiments, if no I / O request is pending, no delayed procedure call is scheduled to save CPU cycles. Due to the lack of a dedicated polling thread, system resources are also saved. Due to the CPU-specific delayed procedure call execution, some embodiments can provide balanced CPU usage.

[0045] Fig.11 System 100 is illustrated, including executing user mode applications 120 and 125. It is assumed that applications 120 and 125 each have issued I / O requests associated with storage drive 110. Each of applications 120 and 125 executes on a different CPU, and therefore the issued requests are stored in a different submission queue 112 and programmed into a different corresponding submission queue 102. In addition, deferred procedure calls have been scheduled into queues 116 and 117, one of queues 116 and 117 corresponding to a simultaneous multi-threaded processor associated with the CPU executing application 120, and the other of queues 116 and 117 corresponding to a simultaneous multi-threaded processor associated with the CPU executing application 125.

[0046] Fig.12 A computing device 1200 is illustrated that can implement process 200 according to some embodiments. Computing device 1200 can be a traditional stand-alone computing device or a blade server. Computing device 1200 includes a NIC that manages communications with an external physical network. One or more CPUs execute a host operating system that supports a hypervisor layer on which two virtual machines are executed.

[0047] Each virtual machine can be configured to utilize a dedicated amount of RAM, persistent storage (e.g., low-latency storage such as NVRAM), and processing resources of the computing device 1200. Each virtual machine can execute its own operating system, which can be the same or different from the operating system executed by other virtual machines. Each virtual machine can run one or more applications on its operating system to request I / O operations from NVRAM. These I / O requests can be processed as described above. By doing so, some embodiments provide improved latency and throughput compared to conventional processing, in which an interrupt generated by a storage device will be delivered to the physical CPU, the hypervisor layer, and then delivered to the virtual CPU of the requesting application.

[0048] Fig.13 1 is a block diagram of a system 1300 according to some embodiments. The system 1300 may include a general purpose computer server and may execute program code to provide I / O request processing using any of the processes described herein. Any one or more components of the system 1300 may be implemented in a distributed architecture. According to some embodiments, the system 1300 may include other elements not shown.

[0049] System 1300 includes a processing unit 1310 operatively coupled to a communication device 1320, a persistent data storage system 1330, one or more input devices 1340, one or more output devices 1350, a volatile memory 1360, and a low-latency non-volatile memory 1370. Processing unit 1310 may include one or more processors, processing cores, processing threads, etc. for executing program code. Communication device 1320 may facilitate communication with external devices such as client devices requiring application services. (Multiple) input device 1340 may include, for example, a keyboard, keypad, mouse or other pointing device, microphone, touch screen, and / or eye tracking device. (Multiple) output device 1350 may include, for example, a display (e.g., a display screen), a speaker, and / or a printer. (Multiple) input device 1340 and / or (multiple) output device 1350 may be coupled to system 1300 as desired, and in some cases, no such devices are coupled to system 1300 during operation.

[0050] The data storage system 1330 may include any number of suitable permanent storage devices, including combinations of magnetic storage devices (e.g., magnetic tape, hard drive, and flash memory), optical storage devices, read-only memory (ROM) devices, etc. The memory 1360 may include any type of random access memory (RAM) that is known or becomes known. The non-volatile low-latency memory 1370 may include non-volatile random access memory (NVRAM), storage class memory (SCM), or any other low-latency memory that is known or becomes known.

[0051] Application 1332 may include program code executed by processing unit 1310 to enable system 1300 to provide functionality, and may require I / O services in order to provide such functionality. For example, program code of application 1332 may be executed to send a request for an I / O operation to an executing operating system 1336, which provides the request to one of the executing device drivers 1334. If the request is associated with non-volatile low-latency memory 1370, the request is received by one of the device drivers 1334 associated with memory 1370. Therefore, processing may continue as described above to complete the I / O request. Data storage device 1330 may also store data and other program code necessary for providing additional functionality and / or operation of system 1300.

[0052] Each functional component described herein can be implemented in computer hardware (integrated and / or discrete circuit components), in program code, and / or in one or more computing systems that execute such program code, as is known in the art. Such computing systems may include one or more processing units that execute processor-executable program code stored in a memory system.

[0053] Above-mentioned figure represents the logical framework for describing process according to some embodiments, and actual realization can comprise more or different components arranged in other ways.Other topologies can be used in combination with other embodiments.In addition, each component or device described herein can be realized by any number of devices communicating via any number of other public and / or private networks.Two or more of such computing devices can be located away from each other, and can communicate with each other via any known network mode and / or dedicated connection.Each component or device can comprise any number of hardware and / or software elements suitable for providing the functions described herein and any other functions.

[0054] The embodiments described herein are for illustrative purposes only. Those skilled in the art will appreciate that modifications and changes may be made to the above embodiments to practice other embodiments.

Claims

1. A computing system comprising: one or more processors to execute processor-executable program code; as well as Storage devices, Wherein the system is operable to: Receive a request to perform an I / O operation; providing the request to the storage device; storing an entry associated with the request in a storage driver submission queue, Scheduling a delayed procedure call associated with an operating system, the delayed procedure call being used to determine whether the storage device has completed the I / O operation; If it is determined that the operating system is at the interrupt request level of the delayed procedure call, executing the delayed procedure call to determine that the storage device has completed the I / O operation; as well as In response to determining that the storage device has completed the I / O operation, sending a return corresponding to the completed I / O operation; determining whether the storage drive submission queue contains an entry associated with a request to perform a second I / O operation; as well as If it is determined that the storage driver submission queue contains an entry associated with a request to perform a second I / O operation, the deferred procedure call is rescheduled to determine whether the storage device has completed the second I / O operation.

2. The computing system of claim 1 , wherein the delaying procedure call comprises: A process for checking a storage drive completion queue corresponding to the I / O operation.

3. The computing system of claim 1 , wherein providing the request to the storage device comprises: determining a processor from which the request was received; as well as A determination is made as to whether the storage drive submission queue is associated with the determined processor. 4 . The computing system of claim 3 , wherein the deferred procedure call is scheduled for execution by a simultaneous multi-threaded processor associated with the processor.

5. The computing system of claim 3, further operable to: receiving a second request to perform a third I / O operation; determining a second processor from which the second request was received; determining a second storage drive submission queue associated with the determined second processor; storing a second entry associated with the second I / O request in the determined second storage drive submission queue; Scheduling a second delayed procedure call associated with the operating system, the second delayed procedure call being used to determine whether the storage device has completed the third I / O operation; If it is determined that the operating system is at the interrupt request level of the second delayed procedure call, executing the second delayed procedure call to determine that the storage device has completed the third I / O operation; as well as In response to determining that the storage device has completed the third I / O operation, Sending a second return corresponding to the completed third I / O operation; determining whether the second storage drive submission queue contains an entry associated with a request to perform a fourth I / O operation; as well as If it is determined that the storage driver submission queue contains an entry associated with a request to perform a fourth I / O operation, then the second deferred procedure call is rescheduled to determine whether the storage device has completed the fourth I / O operation.

6. The computing system of claim 5, wherein the deferred procedure call is scheduled for execution by a simultaneous multi-threaded processor associated with the processor, and Wherein the second deferred procedure call is scheduled to be executed by a second simultaneous multi-threaded processor associated with the second processor.

7. A computing system executing an operating system, a user mode application, and a storage driver, the computing system being configured to: receiving, at the storage driver, a request from the user mode application to perform an I / O operation associated with a storage device; providing the request to the storage device; storing an entry associated with the request in a storage driver submission queue, sending a request from the storage driver to the operating system to schedule a deferred procedure call to determine whether the I / O operation is complete; determining, by the operating system, that the operating system is at an interrupt request level of the delayed procedure call; In response to determining that the operating system is at an interrupt request level for the delayed procedure call, executing the delayed procedure call by the operating system to determine that the I / O operation is complete; as well as In response to determining that the I / O operation is complete, Sending a return corresponding to the completed I / O operation to the user mode application; determining whether the storage drive submission queue contains an entry associated with a request to perform a second I / O operation; as well as If it is determined that the storage drive submission queue contains an entry associated with a request to perform a second I / O operation, the deferred procedure call is rescheduled to determine whether the second I / O operation is complete.

8. The computing system of claim 7, wherein the delayed procedure call comprises a procedure for checking a completion queue of the storage drive, the completion queue corresponding to the requested I / O operation.

9. The computing system of claim 7, wherein providing the request to the storage device comprises: determining a processor of the computing system from which the request is received; as well as A determination is made as to whether the storage drive submission queue is associated with the determined processor.

10. The computing system of claim 9, wherein the deferred procedure call is scheduled for execution by a simultaneous multi-threaded processor associated with the processor.

11. The computing system of claim 9, further operable to: receiving, at the storage driver, a second request from a second user mode application to perform a third I / O operation; determining a second processor from which the second request was received; determining a second storage drive submission queue associated with the determined second processor; storing a second entry associated with the second I / O request in the determined second storage drive submission queue; sending a second request from the storage driver to the operating system to schedule a second deferred procedure call to determine whether the third I / O operation is complete; Determining, by the operating system, that the interrupt request level at which the operating system is executed is at the second delayed procedure call; In response to determining that the operating system is at an interrupt request level for the second deferred procedure call, executing, by the operating system, the scheduled second deferred procedure call to determine that the second I / O operation is complete; as well as In response to determining that the third I / O operation is complete, sending a second return corresponding to the completed second I / O operation to the second user mode application; determining whether the second storage drive submission queue contains an entry associated with a request to perform a fourth I / O operation; as well as If it is determined that the storage drive submission queue contains an entry associated with a request to perform a fourth I / O operation, the second deferred procedure call is rescheduled to determine whether the fourth I / O operation is complete.

12. The computing system of claim 11, wherein the deferred procedure call is scheduled to be executed by a simultaneous multi-threaded processor associated with the processor, and Wherein the second deferred procedure call is scheduled to be executed by a second simultaneous multi-threaded processor associated with the second processor.

13. A computer-implemented method comprising: Receive requests from user-mode applications to perform I / O operations; storing an entry associated with the request in a storage driver submission queue, Scheduling a delayed procedure call associated with an operating system, the delayed procedure call being used to determine whether the I / O operation is complete; If it is determined that the operating system is at an interrupt request level for the delayed procedure call, executing the scheduled delayed procedure call to determine that the I / O operation is complete; as well as In response to determining that the I / O operation is complete, Sending a return corresponding to the completed I / O operation to the user mode application; determining whether the storage drive submission queue contains an entry associated with a request to perform a second I / O operation; as well as If it is determined that the storage drive submission queue contains an entry associated with a request to perform a second I / O operation, the deferred procedure call is rescheduled to determine whether the second I / O operation is complete.

14. The computer-implemented method of claim 13, wherein the delaying procedure call comprises: A process for checking a storage drive completion queue corresponding to the I / O operation.

15. The computer-implemented method of claim 13, further comprising: determining a processor from which the request was received; as well as A determination is made as to whether the storage drive submission queue is associated with the determined processor.

16. The computer-implemented method of claim 15, further comprising: receiving a second request from a second user mode application to perform a third I / O operation; determining a second processor from which the second request was received; determining a second storage drive submission queue associated with the determined second processor; storing a second entry associated with the second request in the determined second storage drive submission queue; scheduling a second delayed procedure call associated with the operating system, the second delayed procedure call being used to determine whether the third I / O operation is complete; If it is determined that the operating system is at the interrupt request level of the second delayed procedure call, executing the scheduled second delayed procedure call to determine that the third I / O operation is completed; as well as In response to determining that the third I / O operation is complete, sending a second return corresponding to the completed third I / O operation to the second user mode application; determining whether the second storage drive submission queue contains an entry associated with a request to perform a fourth I / O operation; as well as If it is determined that the storage drive submission queue contains an entry associated with a request to perform a fourth I / O operation, the second deferred procedure call is rescheduled to determine whether the fourth I / O operation is complete.

17. The computer-implemented method of claim 16, wherein the deferred procedure call is scheduled for execution by a simultaneous multi-threaded processor associated with the processor, and Wherein the second deferred procedure call is scheduled to be executed by a second simultaneous multi-threaded processor associated with the second processor.

Images