Point-to-point interrupt messaging within a multiprocessing...

Details Point-to-point interrupt messaging within a multiprocessing... Point-to-point interrupt messaging within a multiprocessing...

1999-02-16

2001-09-25

Lefkowitz, Sumati (Department: 2181)

Electrical computers and digital data processing systems: input/

Interrupt processing

C710S268000

Reexamination Certificate

active

06295573

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to multiprocessing computer systems, and more particularly, to interrupt messaging within a multiprocessing computer system.
2. Description of the Related Art
Multiprocessing computer systems are characterized by having two or more processing units operating in parallel to effectively increase the throughput of the system. In a multiprocessing environment, tasks are divided into groups or “threads” that can be handled by separate processors. This is quite different from a single processor system, because the processing load is advantageously distributed among several processors, and the distributed tasks may be executed simultaneously in parallel. The operating system software may divide various portions of the program code into separately executable threads, and may also typically assign a priority level to each thread.
An important consideration with respect to a multiprocessing system is the handling and distribution of interrupts generated by various system resources.
FIG. 1
shows a prior art arrangement to manage interrupts in a multiprocessing environment. In
FIG. 1
, three local interrupt controllers,
14
A through
14
C, are shown connected to their respective processors,
12
A through
12
C. An I/O subsystem
10
is shown as an initiator of interrupts that are directed to an I/O interrupt controller
16
through a set of interrupt lines
15
. One of the devices constituting the I/O subsystem
10
may assert a respective interrupt signal on one of the interrupt lines
15
. In response to that interrupt signal, the I/O interrupt controller
16
determines potential destinations for the interrupt signal and delivers that interrupt signal to one or more of the local interrupt controllers that are determined as interrupt destinations. The interrupt signal is delivered through an appropriate interrupt message that is transmitted on the dedicated interrupt bus
18
. The interrupt message includes the bits to identify one or more of the interrupt destinations, and may also include an appropriate interrupt vector depending on the type of the interrupt being asserted by the I/O subsystem
10
. For example, a lowest priority interrupt may generate a different interrupt message than a non-maskable interrupt.
The I/O subsystem may include an I/O device that asserts a respective interrupt signal based on the occurrence (or non-occurrence) of a particular event. As will be appreciated by those skilled in the art, interrupts are routinely generated by system resources such as keyboard devices, printers, timers etc. These devices may also comprise the I/O subsystem
10
. Many systems also accommodate software interrupts whereby an interrupt may be asserted in response to software command. Additionally, in a multiprocessing computer system, one or more inter-processor interrupts may arise. In that case, the respective local interrupt controller transmits an appropriate interrupt message to one or more local interrupt controllers that are specified as potential destinations for the inter-processor interrupt.
Due to the number of different interrupts that may occur within a system, it is desirable to provide a mechanism to efficiently manage and distribute the interrupts to achieve optimal system performance and bus utilization. In the arrangement of
FIG. 1
, a dedicated wired-or bus is required to manage the interrupt traffic. The presence of such an additional dedicated bus may necessitate blending of the physical characteristics of the bus with the interrupt-management protocol to be implemented in the system. This, in turn, may make the interrupt-management protocol bus-dependent, thereby reducing the portability of the protocol when a different multiprocessor architecture is introduced. The wired-or architecture places a limitation on the number of local interrupt controllers a system can have, which, in turn, places a limitation on the number of processors that can be accommodated. This is due to the fact that a wired-or bus inherently suffers from signal degradation as loads are added and, in some cases, may necessitate slowing down of the bus frequency because of the bandwidth constraints.
The dedicated interrupt bus
18
is physically hooked to each interrupt controller as is depicted in FIG.
1
. The width of the bus
18
may range from two to five bits. In any event, the serial nature of message transmission over the interrupt bus
18
requires many bit times to complete a single message. A “bit time” is the amount of time required to transmit one bit per line. When the interrupt bus
18
is an open drain bus, i.e. a bus connected to pull-up transistors to function as a wired-or bus, any interrupt controller—local or I/O—can pull the bus to a logic low state. This action by one interrupt controller may severely restrict a simultaneous transmission of anther interrupt message through the bus by a different interrupt controller. As the bus
18
is physically connected to each interrupt controller in the system, all interrupt controllers are able to track every message that is sent on the dedicated interrupt bus
18
, thereby knowing when a message starts and when it ends. When this kind of arrangement is an integral part of the interrupt-management protocol, only one interrupt message may be sent through the bus at a time. When multiple interrupt controllers try to transmit respective interrupt messages simultaneously, the wired-or nature of the bus and the bus-dependent interrupt-management protocol force the interrupt controllers to arbitrate in real time before sending the interrupt message on the bus. This may, in certain critical situations, not be desirable at all.
Bus arbitration normally takes place at the beginning of an interrupt message, thereby adding additional bit times for that particular message. Further, interrupt controllers that lose the arbitration priority must postpone their transmission of interrupt messages until the winner interrupt controller is taken care of by the system. Also, response to an interrupt message, e.g., accept, reject, retry, etc., takes place within the message itself. In fact, there is actually a bit time reserved within each interrupt message to allow destination interrupt controllers to indicate their response to the interrupt message, or even to drive a check_sum error response. In other words, the interrupt message is treated as a seamless event that is complete only when an indication of beginning of interrupt servicing is received by the interrupt controller that initiated the interrupt message on the dedicated bus
18
. Thus, a different interrupt message cannot be transmitted on the dedicated bus
18
as long as there is a pending interrupt message occupying the bus bandwidth. This protocol, thus, results in less than optimal use of system resources.
Further, each interrupt controller, whether I/O or local, requires additional pins to allow its physical attachment to the dedicated bus
18
. This increase in pin-count per interrupt controller is not at all balanced by a proportionate increase in performance throughput as discussed above. The existence of a dedicated interrupt bus
18
, physical connection of each interrupt controller to that dedicated interrupt bus, and heavily bus-dependent nature of the interrupt management protocol create quite an inflexible multiprocessing architecture.
SUMMARY OF THE INVENTION
The foregoing briefly described the problems associated with a multiprocessing computer system architecture that employs a dedicated interrupt bus to carry interrupt messages and responses among different interrupt controllers. In one embodiment, the present invention contemplates a multiprocessing computer system without such a dedicated bus to carry the interrupt traffic. The multiprocessing computer system may comprise a plurality of processing nodes that are interconnected through an interconnect structure, preferably a first plurality of dual unidirectional links. Each unidirectional link in a dual unidirectional link connect

Affiliated with

Also associated with

Rating

Point-to-point interrupt messaging within a multiprocessing... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Point-to-point interrupt messaging within a multiprocessing..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Point-to-point interrupt messaging within a multiprocessing... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2462612