Electrical computers and digital data processing systems: input/ – Interrupt processing – Interrupt inhibiting or masking
Reexamination Certificate
2001-04-11
2004-09-14
Rinehart, Mark H. (Department: 2181)
Electrical computers and digital data processing systems: input/
Interrupt processing
Interrupt inhibiting or masking
C710S260000, C710S263000, C710S264000
Reexamination Certificate
active
06792492
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention relates generally to servicing of interrupts by an operating system (“OS”), and more particularly, to a method of achieving low overhead and low latency for OS interrupts.
On the majority of computer hardware systems hosting commercial operating systems, devices exist whose function it is to generate hardware interrupts to signal the occurrence of asynchronous events such as a packet arriving on a wire for a network interface card (“NIC”) or an event signaling the completion of a disk I/O request. The handling of these kinds of asynchronous events has traditionally been accomplished in one of two ways, including polling and interrupt-driven. Each of these methods has advantages, as well as disadvantages.
In particular, with regard to interrupt-driven handling of asynchronous events, during normal operation, when a device on an I/O bus, such as a storage device, NIC, or I/O device, has work that needs to be done, it asserts an interrupt to the processor. If interrupts are enabled at the processor, receipt of an interrupt causes the processor to enter a special state to service the interrupt. First, the processor must save context, which means saving the state of the registers to memory so the processor can use the registers during handling of the interrupt without destroying the state of the interrupted process. The processor then vectors to a designated location in memory and runs an interrupt service routine, or interrupt handler to service the interrupt, after which the state, or context, is restored and a return from interrupt is executed. The processor then continues executing from the position in the code at which it was interrupted.
In today's computing environment, the bit rate of a packet on the wire is steadily increasing. Hardware will traditionally deliver one interrupt to the OS for each packet of information received on the wire. As the transfer rate increases, the amount of interrupt processing required by the CPU also increases, reducing the amount of processing that can be performed by the CPU for other purposes. Interrupts are inherently inefficient, as they require some state of the interrupted process to be saved before interrupt handling can begin. This state must later be restored when interrupt handling is completed. This saving and restoring on each interrupt is a waste of CPU cycles. This problem is only compounded as the number of interrupts increases in the system.
On Intel's 32-bit architecture, the context to be saved is small, and therefore interrupt-driven drivers are not a serious problem. However, Intel's new 64-bit architecture requires a significant amount of information to be saved and restored each time an interrupt is taken. This enormous expense is not tolerable for a highly performant OS. On the other hand, the advantage of using an interrupt-driven method is that there is almost no latency between the occurrence of the asynchronous event and the time in which the OS services that event.
In contrast, in the polling mechanism, the OS informs the hardware devices to not generate interrupts. Instead, the OS will poll the devices' drivers at regular intervals to determine whether there is work that needs to be performed. This method clearly has the advantage of completely avoiding the costly overhead of interrupt-driven drivers; however, it suffers from two notable deficiencies. First, the OS must constantly be polling the drivers to determine whether there is work to be done. This act itself is a waste of the CPU's processing time and should be avoided. Secondly, there is some latency between the time the driver would have normally interrupted processing and the time the OS actually polls the device. This latency, if too great, can also result in unacceptable performance.
Therefore, what is needed is a method of handling asynchronous events in a manner that results in both lower latency and lower overhead than the aforementioned traditional methods of handling the same.
SUMMARY OF THE INVENTION
In one embodiment, a system and method of method for achieving low overhead and latency in servicing operating system (“OS”) interrupts takes advantage of the availability of a “lightweight interrupt” available on various processors, including a 64-bit processor commercially available from Intel Corporation of Santa Clara, Calif., as “Itanium” (hereinafter “IA-64”). In a preferred embodiment, when a deferrable interrupt occurs, a lightweight interrupt handler, in combination with banked and special control registers, is used to inform the OS that an interrupt occurred and prevent the CPU and associated hardware from fully acknowledging or servicing the interrupt from a hardware standpoint until a designated future time. The OS sets to TRUE a per CPU software flag, referred to as a
“Deferred_Interrupt_Pending” flag, indicating that an interrupt has been received but is still pending. A return from the lightweight interrupt handler is then executed. In this manner, the interrupt is partially acknowledged by the CPU, but the device that caused the interrupt is still awaiting service; i.e., from the device's point of view, the interrupt remains pending. To guarantee low latency, a heavyweight (“non-deferrable”), time-based interrupt that flushes all deferrable interrupts is scheduled to occur within a specified time.
At a later time, for example, when drivers would normally be polled for work, the per CPU Deferred_Interrupt_Pending flag is checked to see if there is interrupt work to be performed. If so, with all interrupts disabled at the CPU, the pending interrupts are unmasked to determine which ones need to be serviced. In one embodiment, this is accomplished by, examining a special register in the CPU designated for this purpose. Subsequently, the deferred interrupts are batch processed sequentially by calling their service routines in order of priority without any context save required.
A technical advantage achieved with the invention is that it incorporates the most desirable attributes (low latency, low overhead), while avoiding the undesirable aspects (high latency, high overhead), of both interrupt-driven and polled driver architectures.
REFERENCES:
patent: 5438677 (1995-08-01), Adams et al.
patent: 5727227 (1998-03-01), Schmidt et al.
patent: 5928321 (1999-07-01), Ozcelik et al.
patent: 6021458 (2000-02-01), Jayakumar et al.
patent: 6163829 (2000-12-01), Greim et al.
Cleary Thomas J.
Haynes and Boone LLP
Novell Inc.
Rinehart Mark H.
LandOfFree
System and method of lowering overhead and latency needed to... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method of lowering overhead and latency needed to..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method of lowering overhead and latency needed to... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3211025