Browse Prior Art Database

Input/Output Supervisor Dynamic Processor Signalling

IP.com Disclosure Number: IPCOM000042026D
Original Publication Date: 1984-Mar-01
Included in the Prior Art Database: 2005-Feb-03
Document File: 1 page(s) / 12K

Publishing Venue

IBM

Related People

Biersack, FP: AUTHOR [+3]

Abstract

A major consideration in any multiprogramming operating system is the design of the I/O Supervisor (IOS). Previously, IOS was designed to be capable of operating asynchronously with respect to user program requests, and even to many other portions of the operating system. This can allow IOS to control the devices and other I/O hardware with high utilizations. This article describes special IOS logic to coordinate operations with user program requests, as well as to minimize both overhead and delay. In prior tightly coupled multiprocessor systems having most devices attached by multiple paths to both processors, IOS selected a path to a requested device. IOS does this by determining if any paths are available to the device on the processor IOS happens to be using at that time.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Input/Output Supervisor Dynamic Processor Signalling

A major consideration in any multiprogramming operating system is the design of the I/O Supervisor (IOS). Previously, IOS was designed to be capable of operating asynchronously with respect to user program requests, and even to many other portions of the operating system. This can allow IOS to control the devices and other I/O hardware with high utilizations. This article describes special IOS logic to coordinate operations with user program requests, as well as to minimize both overhead and delay. In prior tightly coupled multiprocessor systems having most devices attached by multiple paths to both processors, IOS selected a path to a requested device. IOS does this by determining if any paths are available to the device on the processor IOS happens to be using at that time. If all paths are busy, IOS used a Signal Processor (SIGP) instruction to signal the other processor to run IOS to determine if there are any available paths on that side. An attempt has been made to lessen the hardware and software overhead associated with interprocessor communication, by not issuing the SIGP. The request is queued, and on a subsequent redrive of IOS (on either processor) the request would be retried. This queueing assumed that the interrupt rate would be high enough for IOS to redrive the request in a timely fashion. This was a valid assumption in a vast majority of environments. In certain environments, however, this ass...