Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1999-12-14
2004-08-03
Starks, Jr., Wilbert L. (Department: 2121)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C710S260000
Reexamination Certificate
active
06772189
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention generally relates to computer systems, specifically operating system software and device drivers, and more particularly to interrupt handling mechanisms for devices attached to multiprocessor operating systems.
2. Description of Related Art
As computer systems have evolved and become more complex, the use of multiple processors coupled by buses within a computer has increased. State-of-the-art multiprocessor network servers and dedicated desktop workstations are in common use.
Operating systems for use with multiprocessing systems have also grown in complexity, adding API's (Application Programming Interfaces) in the operating system and support routines in the kernel of the operating system to provide information about the organization of the hardware of the computer system, and allowing control of the operating system in how it allocates tasks and resources to the processors and processes being executed by the processors.
Computer systems use device drivers to enable communication between hardware devices, such as storage devices, communications ports, network adapters, and so forth, and operating systems services and services that can be interfaced to applications software. A device driver is an installable module that contains instructions and data for controlling its particular device or multiple devices and connecting them with operating system services or application programs.
An attached or integrated piece of hardware known as an adapter may control and connect one or more devices. For example, in RAID (Redundant Array of Inexpensive Disks) array controllers produced by IBM (International Business Machines Corp.), the SCSI (Small Computer Systems Interface) adapters contain several devices, each controlling an individual SCSI bus, and each SCSI bus may connect a plurality of DASD's (Direct Access Storage Devices).
Commonly, a hardware device will provide an interrupt so that it may request service due to stimulus from an outside source. For example, a serial port driver will commonly generate interrupts on the receipt of one or more bytes of data. In addition, interrupts are used to indicate to the device driver that the device has completed a command or other task that has been previously given to the device by the driver. For example, a SCSI controller may generate an interrupt when it has completed a read or a seek operation on a disk drive, so that the driver knows that data is present to be transferred, or the device is ready to execute the next command.
These interrupts originate as an electrical signal from the device and provided to the computer system, usually via an interrupt controller that is a circuit coupled to the computer bus to which the device is attached. This controller issues another signal to tell a processor that an interrupt is pending. Operating system code, typically provided by the kernel, changes execution. context (leaving the context of lower priority application code or kernel routines), and executes code that has been “attached” to the interrupt by the device driver, known as an ISR (Interrupt Service Routine). This attachment often takes the form of an interrupt binding service provided by the kernel and called by the device driver during initialization.
When the interrupt service routine is executed, the device driver performs tasks associated with the interrupt. For example, the device driver will usually set or reset the hardware register responsible for generating the interrupt signal so that the interrupt will not be present upon exiting the ISR, which on some computer system/operating system combinations will result in the ISR being called again.
The ISR is typically executed at a very high priority within the set of tasks managed by the kernel of the operating system and it is not desirable to tie up the execution of the ISR with time-intensive tasks. Additionally, in some operating systems, certain services may not be available or may yield unstable results or system crashes if the service routines providing these services are called during the execution of an ISR. This allows the operating system to synchronize objects that may only be manipulated by lower priority tasks without having to block higher priority tasks to ensure that the objects are not corrupted by simultaneous execution of the services by multiple high priority tasks.
For this purpose, operating systems such as WINDOWS NT and WINDOWS 2000 (produced by Microsoft Corporation), provide an architecture that includes a deferred procedure call (DPC). This deferred procedure call can be queued by the ISR, and the operating system will call a routine associated with the DPC at a lower priority level, after the ISR has returned and other higher priority tasks in the system have been performed. The operating system can provide more services at this DPC level, since it is scheduled, and the operating system can delay the execution of the DPC to a greater degree than the ISR while still allowing for a higher execution priority than for example, application program code.
Typically, a device driver will create and initialize one DPC object and associated work list per interrupt that it uses. The DPC routine handles requests, command completions, and external communication responses for all of the devices supported by the interrupt. The interrupt signal line may be shared with other device drivers and devices, each driver having it's own DPC and work list associated with the interrupt. Some device drivers that control devices that do not perform sequences of tasks do not require work lists, but queue DPC objects with the system and the DPC routine can interact with hardware or values stored by the ISR to complete DPC processing.
When multiple processors execute operating system and application code, tasks are generally apportioned to the processors based on processor availability. A scheduled DPC routine may be scheduled for more than one processor, and in some cases, it is up to the DPC routine to determine that the DPC is already being executed on another processor. It is also possible to “lock” the queued DPC requests associated with a DPC object for execution on a single processor.
Locking the queued DPC requests has a disadvantage in that some devices may either momentarily or on-average receive more interrupt requests and generate more work list entries than others. For example, when a particular direct access storage device (DASD) is being accessed in a system that manages multiple DASD's and interfaces, on a momentary basis, a majority of work items will be placed on the work list associated with that device. Locking the DPC object to one processor means that only that processor will be able to service this high priority task. If the DPC object is not locked, having only one work list available for servicing an interrupt associated with a device still limits the system such that only one processor at a time will be able to service that device, since the DPC routine will generally mutually exclude other calls while a first call is being handled.
Therefore, it would be desirable to provide a method and a multiprocessor computer system to balance the handling of work items associated with a device, so that the power of the multiple processors can be brought to bear on the queued work items. This would improve performance of the particular device for which the method is implemented and further the performance of the multiprocessor computer system, as DPC's would be executed for high demand periods on multiple processors without waiting on a single DPC object and associated work list to be free. This would utilize idle time on processors that have no tasks scheduled, increasing overall system performance.
SUMMARY OF THE INVENTION
It is therefore one object of the present invention to provide a method to improve the performance of a multiprocessing computer system.
It is another object of the present invention to provide a computer system with improved deferred procedure call hand
Bracewell&Patterson LLP
Hartman Jr. Ronald D
Starks, Jr. Wilbert L.
LandOfFree
Method and system for balancing deferred procedure queues in... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for balancing deferred procedure queues in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for balancing deferred procedure queues in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3269900