Browse Prior Art Database

I/O Interruption Priority for ESA/390

IP.com Disclosure Number: IPCOM000103973D
Original Publication Date: 1993-Feb-01
Included in the Prior Art Database: 2005-Mar-18
Document File: 4 page(s) / 127K

Publishing Venue

IBM

Related People

Meritt, AS: AUTHOR

Abstract

Disclosed is a means for adding a prioritization mechanism to I/O interruptions for ESA/390*. This method balances the priority of the completion of I/O events, the disruption caused by interruptions, and the latency of delaying interruptions regardless of the work currently executing. Similar mechanisms have been described for systems other than ESA/390.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 42% of the total text.

I/O Interruption Priority for ESA/390

      Disclosed is a means for adding a prioritization mechanism to
I/O interruptions for ESA/390*.  This method balances the priority of
the completion of I/O events, the disruption caused by interruptions,
and the latency of delaying interruptions regardless of the work
currently executing.  Similar mechanisms have been described for
systems other than ESA/390.

      For many years , systems have been trying to balance the value
of interrupts with the harmful effects they have.  The value comes
from timeliness in responding to events, such as the completion of an
I/O operation; this can make work ready sooner than if the
notification were delayed, and also permits the device to be started
with another operation earlier.  The harmful  effects occur because
of disruption to the currently executing work, mainly appearing due
to the serialization effects of the interruption process,
invalidation of the contents of the cache with new data referenced to
service the interrupt, and disruption to translation lookaside
buffers.  Over the years, MVS has implemented a number of approaches
to reduce the impacts.

1.  The selective enablement function in MVS/SP2.1 reduced the number
    of central processors (CPs) CPs which could be disrupted by an
    I/O interrupt by only enabling a subset of the CPs for
    interrupts, using control register 6; this was controlled by
    various thresholds, so that more processors were enabled as the
    backlog of interrupts grew, to reduce the latency with which
    these interrupts were serviced.

2.  Another approach redispatched the interrupted unit of work if it
    were of higher priority than any work made ready by the
    interrupt, only preempting if higher priority work was made
    ready.  Yet another approach redispatched the interrupted unit of

    work after the interruption occurred, even if higher priority
    work were made ready by the interruption, to attempt to maximize
    whatever data remained in the cache and lookaside buffers after
    the interrupt was serviced; timeslicing was used as the mechanism
    for preempting work, rather than the traditional interrupt-driven
    mechanism.  These approaches do not avoid the disruption caused
    by actually taking the interrupt, or some level of disruption to
    the cache and lookaside buffers.

      Another possible approach, not implemented by MVS, is to
disable all processors for interrupts until an opportune time arises,
such as when going through the dispatcher to dispatch another unit of
work.  At this time, the effect of the disruption on the cache or
lookaside buffers of the previously executing work is not important,
since another unit of work is going to be running anyway.  However,
this introduces latency in notifying high priority work of completion
because there is no way to distinguish completions which are more
important...