Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method for precise interrupt notification

IP.com Disclosure Number: IPCOM000180459D
Original Publication Date: 2009-Mar-10
Included in the Prior Art Database: 2009-Mar-10
Document File: 5 page(s) / 88K

Publishing Venue

IBM

Abstract

In this invention we propose an extended interrupt notification mechanism which keeps track of the number of events signalled and processed. The interrupt source therefore signals the number of events associated with the interrupt call while the processing units return the difference between the number of interrupts signalled and the number of interrupts processed.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 5

Method for precise interrupt notification

Method for precise interrupt notificationMethod for precise interrupt notification

The interrupt presentation in multi-core environments is becoming more and more difficult. This has two major reasons: the interrupts can be presented to an ever increasing number of processing units and, moreover, there are more possible interrupt sources as I/O devices adopt virtualization. Therefore, traditional mechanisms using a central APIC,

which directs the interrupts to processing units, are not very practical any

longer. Low-level I/O protocols like HyperTransport or IBM's GX bus on the other hand allow the I/O device to indicate to which processing unit an interrupt shall be directed to. Thus, interrupts from I/O devices can be routed to predefined processing units (interrupt servers). The routing is configured by software and may also be changed between interrupt requests. Interrupt requests are automatically routed through the processor fabric,

which interconnects the processing units, to the destination processing unit.

finishing the interrupt processing, the serving processing unit sends an End-of-interrupt (EOI) response back to the requesting device to signal successful completion of the interrupt. This non-posted mechanism is more efficient in multi-core environments than the PCI-scheme of handling interrupt-requests as memory-

writes with further assistance

Figure 1 - Prior Art

Figure 1 and Figure 2 show the current interrupt presentation mechanism. The device is configured to present the interrupt to one server processing unit (arrow 1 in Figure 2). The interrupt causes overhead in the server processing unit due to the necessary context switch and latencies for bringing necessary interrupt-code into the cache ("Cont." in Figure 1). Only then the processing unit can start actually processing the interrupt. The interrupt cause is usually stored on one or more linked lists in memory in order to provide the processing unit with information on the interrupt cause. The processing unit therefore analyzes those possible sources for interrupt requests and processes new requests. In Figure 1, a second interrupt A) and therefore a second

1

After

of the central APIC.

Generally speaking, interrupts are probably the most complex and also the most costly operation in processors today as they not only have the highest degree of interaction between processing units and I/O devices, but also between software and hardware. However, the non-posted interrupt presentation scheme used in many systems as shown below is imprecise and can thus inflict unnecessary overhead in the processing units.

[This page contains 16 pictures or other non-text objects]

Page 2 of 5

notification is created in the device while the interrupt is processed in the server processing unit. The device will therefore not...