Browse Prior Art Database

System and Method to Discard and Report Over-Initiative Thin Interrupts Allowed by the Queued I/O Devices Disclosure Number: IPCOM000199672D
Publication Date: 2010-Sep-14
Document File: 9 page(s) / 122K

Publishing Venue

The Prior Art Database


Normally, an I/O Interrupt occurs at the completion of each I/O stream and it is for the particular I/O device that executed the I/O stream. So there is a one-to-one relationship between the I/O interrupt and the execution of I/O stream on a particular I/O device. However, such tightly coupled relationship may not be desirable with some of the newer I/O devices like Queued Direct Input/Output (QDIO) and Queued Cryptographic I/O devices. In general, there are many queues for each Queued I/O Device so a new form of loosely coupled I/O Interrupt called "Thin Interrupt" is used to minimize the number of I/O interrupts that get generated for the I/O device. A Thin Interrupt is generated for one or more queues (rather than a particular I/O Device) at a time, and the individual Queued I/O Device architecture determines the conditions upon which a Thin Interrupt is generated. Although Over-Initiative Thin Interrupt is allowed, too much Over-Initiative Thin Interrupts would cause the system to look for work that is not available quite frequently and cause system performance degradation. Since only one Thin Interrupt may be presented for multiple queues and multiple Thin Interrupts may be present when the Thin Interrupt Handler is handling a Thin Interrupt, there is no way do figure out which interrupt was generated for which group of queues. This makes determining and discarding Over-Initiative Thin Interrupts difficult and not an exact science. Determining and discarding Over-Initiative Thin Interrupts become even more difficult when the Queued I/I Devices are being shared by the test/application programs. There is no known solution today to determine, discard or report Over-Initiative Thin Interrupts. Therefore, a system and method is needed to discard and report Over-Initiative Thin Interrupts that are generated by the Queued I/O Devices. The proposed solution works for both shared and exclusively owned Queued I/O Devices. Over-Initiative Thin Interrupts may also be counted, tracked and inspected to see if too much Over-Initiative Thin Interrupts are being generated.

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 21% of the total text.

Page 1 of 9

System and Method to Discard and Report Over -Initiative Thin Interrupts Allowed by the Queued I/O Devices

Each queue has a Thin Interrupt Notification Indicator (TINI) in storage defined by the Operating System (OS). For simplicity, lets assume that the Queue Numbers are sequential starting at zero and the OS uses contiguous and sequential storage locations to define the TINI for each sequential Queue Number. Let's also define two arrays (INTR

_NI and GET

example, first array index is one which represents queue zero. Another array (VLD


queue indexes while scanning all the queues for thin interrupt by the TIH after a thin interrupt is received.

     First, let's assume that all the queues are empty (no work). The test/application program(s) enqueue one or more asynchronous request messages into one or more queues. When one or more of these asynchronous request messages are processed and the corresponding reply messages are placed in their corresponding queues, at least one Thin Interrupt is generated by the machine and the Thin Interrupt Handler(s) get invoked.

     Since the state for which a thin interrupt is generated correctly is Queued I/O Device architecture dependent, lets define the thin interrupt state as follows. Since there can be multiple reply messages in the queue, the device requests for a thin interrupt when the there are no reply messages in the queue and the device places the first reply message into the queue. If more reply messages are placed in the queue before the test/application program removes them from the queue using the Dequeue Service, the device does not request for another thin interrupt. The device does not request for another thin interrupt until the test/application program removes all the pending reply messages from the queue (thin interrupt reset state) and the device places the first reply message into the queue. The machine's thin interrupt manager collects all the thin interrupt requests and then generates one thin interrupt when the Central Processor Unit (CPU) is enabled for thin interrupt.

     When a Thin Interrupt occurs on a CPU that is currently enabled for Thin Interrupt, the TIH in the Operating System (OS) gets invoked. To avoid getting another thin Interrupt on this same CPU while processing the current Thin Interrupt, the TIH first disables the CPU for Thin Interrupt. The TIH then processes the current Thin Interrupt, and re-enables the CPU for Thin Interrupt after the current Thin Interrupt has been processed. On a Multi-CPU machine, CPUs that are currently enabled for Thin Interrupt may still receive Thin Interrupts even though other CPUs are currently disabled for Thin Interrupt.

     Figure 1 shows how the TIH scans and gathers the queues with pending thin interrupts. Each TIH increments NEW


until the counter is updated successfully. This method makes sure that no overlapping updates of this counter occur when multiple TIHs are trying to update the value of this global counter concurrent...