Method and system for moderating thread priority boost for I/O completion

A system and method uses a heuristic approach to manage the boosting of thread priorities after I/O completion to improve system performance. Upon detection of the completion of an I/O operation in response to a request, the system thread does not automatically boost the priority of the thread that made the I/O request by a fixed amount. Instead, the system thread determines whether to boost the requesting thread's priority by applying heuristic criteria based on the I/O operation status, such as whether the system thread has additional I/O requests to process, how many I/O request packets have been completed in the current thread context without a priority boost to the requesting thread, and the time that has passed since the last boosted I/O completion.

TECHNICAL FIELD

This invention relates generally to computer operations, and more particularly to the operation of a computer that has a plurality of threads running thereon.

BACKGROUND OF THE INVENTION

A modern computer with an operating system implementing multi-threading typically has many threads going at a given time. Generally, the threads are context-switched in and out all the time, and which thread is switched in (i.e., getting to use the processor) depends on the priorities of the threads. How the switching is managed can have a significant impact on the performance of the computer.

In the traditional operating system device driver model, a system thread (e.g., the thread for a system-provided driver) performs an I/O operation in response to an I/O request from an application or a higher-level driver. Once the system thread has completed the requested I/O operation, it boosts the priority of the thread that made the request. This priority boost, which is a standard way of implementing I/O drivers, increases the likelihood that the thread that made the request will be context-switched in so that it can consume the data resulting from the I/O operation. In some situations, however, the system thread will have its priority superceded by the boosted thread. This can cause the system thread to be context-switched out and in frequently, which can have significant detrimental effect on the overall system performance.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention provides a system and method that uses a heuristic approach to manage the boosting of thread priorities to improve system performance. Upon detection of the completion of an I/O operation in response to a request, the system thread does not automatically boost the priority of the thread that made the I/O request by a fixed amount, as is done conventionally. Instead, the system thread determines whether to boost the requesting thread's priority by applying specific heuristic criteria based on the I/O status, such as whether the system thread has additional I/O requests to process, how many I/O request packets have been completed in the current thread context without a boost to the requesting thread's priority, the time that has passed since the last priority-boosted I/O completion, etc. By allowing the system thread to decide whether to boost the priority of the requesting thread based on heuristic criteria, the system can optimize the overall system performance by trying to accomplish more I/O operations before being context switched out.

DETAILED DESCRIPTION OF THE INVENTION

The following description begins with a description of a general-purpose computing device that may implement the system and method for managing thread priority for I/O completion in accordance with the invention. The thread priority management for I/O completion of the invention will be described in greater detail with reference toFIGS. 2-4. Turning now toFIG. 1, a general purpose computing device is shown in the form of a conventional personal computer20, including a processing unit21, a system memory22, and a system bus23that couples various system components including the system memory to the processing unit21. The system bus23may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)24and random access memory (RAM)25. A basic input/output system (BIOS)26, containing the basic routines that help to transfer information between elements within the personal computer20, such as during start-up, is stored in ROM24. The personal computer20further includes a hard disk drive27for reading from and writing to a hard disk60, a magnetic disk drive28for reading from or writing to a removable magnetic disk29, and an optical disk drive30for reading from or writing to a removable optical disk31such as a CD ROM or other optical media.

The hard disk drive27, magnetic disk drive28, and optical disk drive30are connected to the system bus23by a hard disk drive interface32, a magnetic disk drive interface33, and an optical disk drive interface34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer20. Although the exemplary environment described herein employs a hard disk60, a removable magnetic disk29, and a removable optical disk31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, storage area networks, and the like may also be used in the exemplary operating environment.

Referring now toFIG. 2, the present invention is directed to a new approach to handling thread priorities in the event of completion of an I/O request. For example, as shown inFIG. 2, an application70running in the user mode may make a request for an I/O operation (e.g., to obtain data) and posts an input buffer72for that I/O request in a queue76. In one implementation, the input buffer is in the form of an I/O request packet (IRP), which is a data structure used in the Windows operating systems of Microsoft Corporation for asynchronous delivery of data, and is marked completed when the requested I/O is done. A system-provided driver80(e.g., an Http.sys driver) handles the I/O request by inserting data into the input buffer72. The system-provided driver80may obtain the data from a lower-level driver82(e.g., a Transport Driver Interface (TDI) driver), which may obtain data from a data source, such as the Internet. As shown inFIG. 2, the lower-level driver82inserts data into buffers86of the driver80, which then copies the data into the input buffer72posted by the application70. As is typical in a computer that has a multi-threading operating system, the application70runs in the user mode and corresponds to an application thread, and the system-provided driver runs in the kernel mode and corresponds to a system thread.

In the traditional operating system device driver model, the system thread that handles the I/O request of the application thread (or the thread of a higher-level driver) would boost the priority of the application thread once the system thread has completed the I/O operation in response to the request. The priority boost is by a fixed increment in the priority level, such as 2, and the recommended boost value is typically given in a public interface file (e.g., ntddk.h for the Windows NT operating system of Microsoft Corporation). The purpose of this priority boost is to increase the likelihood that the application thread will be switched in, i.e., given possession of the processor, so that it can consume the data obtained in the I/O operation or free up resources in a timely manner. The problem with the conventional approach is that the system thread that provides the boost to the application thread may be immediately preempted by the boosted application thread and be switched out, preventing it from performing more I/O operations. This reduces the possibility of batch processing I/O requests and, as a result, may have detrimental effects on the overall system performance, due to the significant CPU cost associated with context switching.

By way of example,FIG. 3shows an exemplary sequence of switching between the application thread and the system thread for the driver that handles the I/O requests, with the convention thread-boosting after each I/O completion. As shown inFIG. 3, the application thread (in the user mode)90makes an I/O request (step92) and posts an I/O buffer96, and at a later time the system thread100for the driver (in the kernel mode) is context switched in to handle the I/O request. The system thread100obtains the requested data and copies the data into the I/O buffer (step102). The system thread100reports the completion of the I/O operation, and then boosts the priority of the application thread (step102). The priority boost to the application thread causes the system thread to be context switched out and the application thread90context switched in. The application thread90reads the data from the buffer and performs its operations (step110). Later, the application thread makes another I/O request (step112) and posts another I/O buffer (116), and the system thread100of the driver is again switched in to handle the I/O request. After the I/O operation for the second request is completed, the system thread100reports the I/O completion and again boosts the priority of the application thread (step118), causing another context switch to the application thread90. As can be seen fromFIG. 3, a context switch occurs after the completion of every I/O request as a result of the priority boost to the application thread upon I/O completion. In other words, each time the system thread100is context switched in, it can handle only one I/O request before it is switched out. This is undesirable when the application thread makes many I/O requests, and the frequent context switching can incur a large amount of time and overhead. In addition, the frequent context switching may increase resource contention, as the boosted thread may initiate additional I/O requests before the system thread can release its I/O resources. As a result, the performance of the system may be significantly reduces.

In accordance with the invention, this problem is effectively prevented by moderating the boost of the application thread after the completion of an I/O operation in response to a request. Rather than automatically boosting the priority of the application thread at each I/O completion, the system thread determines whether a priority boost should be applied based on heuristic criteria based on the status of I/O operations. In a preferred embodiment, the priority boost is reduced or eliminated at an I/O completion unless one or more of conditions are met. First, the priority boost may be made when the system thread has no additional I/O requests to process in the immediate future and thus would not benefit from being able to finish its CPU time quantum without interruption. The system thread may also boost the priority of the application thread when a threshold number of IRPs have been completed in the current thread context without interruption. In other words, if the system thread has completed responding to a pre-set number of I/O requests without the interruption caused by context switching induced by priority boosting, it may allow the application to switched in to consume the data generated by the I/O operations. The system thread may also decide to boost the priority of the application thread if a pre-set threshold amount of time has passed since the last time the priority of the application thread was boosted after an I/O completion, to allow the application thread to be context switched in to perform its operations.

Again by way of example,FIG. 4shows an exemplary sequence of context switching between an application thread120and a system thread122for the driver, with the priority boost after I/O completion moderated in accordance with the invention. The user mode application thread120may make multiple I/O requests (steps126) and posts I/O buffers128for the requests. When the system thread122for the driver is switched in, it responds to one I/O request, and reports the completion of the requested I/O operation. The system thread, however, decides not boost the priority of the application thread at this time (step132). This allows the system thread122to stay in, i.e., to remain in possession of the processor. As a result, the system thread122can carry out the I/O operation for another I/O request. After completion of this I/O operation, the system thread reports the completion but again decides not to boost the priority of the application thread (step136). This allows it to perform more I/O work. Finally, the system thread122decides that it is time to boost the priority of the application thread to allow it to be context switched in (step138). This may be because there is no more I/O to be done, or the number of I/O operations it has performed since it was switched in has reached a threshold number, or the time elapsed since the time it was switched in (or when the last time the priority boost was made) has reached a threshold length of time, etc. It will be appreciated that other heuristic criteria based the status of I/O operations can be set up for the system thread to determine whether it should boost the priority of the application thread120. When the system thread122decides that it is time to allow the application thread120to be switched in, it boosts the priority of the application thread (step138). As a result, the system thread is switched out, and the application thread is switched in and consumes the data or performs other tasks (step140).

In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.