Topics:

• User-Level Interrupts
• Frame Scheduler

User-Level Interrupts (ULIs)

User-level interrupts (ULIs) enable you to designate a module of your user-level code as the interrupt service routine (ISR) that automatically executes in response to an interrupt.

In contrast, UNIX ISRs typically must be written with kernel-level code. ULIs offer two major advantages over kernel-level ISRs:

• ULIs greatly reduce the latency before user-level code begins executing in response to an interrupt
• ULIs simplify device driver development by eliminating the need to test and debug kernel-level code

This timing diagram shows what happens between occurrence of a hardware interrupt and the start of execution of your code. (Compare this with the diagram showing the guaranteed worst-case timing provided by REACT.) The fast path provided by ULIs avoids all scheduler activity and context switch time. ULIs were designed to provide a simple, low-latency method of handling high-speed interrupts.

The following limitations apply to ULI code:

1. System calls are not allowed.
2. The address mapping utilities required for dma operations are not available.

REACT/pro Frame-Rate Scheduler (FRS)

The FRS offers efficient, flexible support for periodic scheduling of IRIX^TM processes, as required by many real-time simulation and data acquisition applications. The FRS is a kernel module that cyclically schedules processes at intervals defined by an interrupt. When enabled on a processor, the FRS replaces the UNIX® time-sharing scheduler, and shuts off the periodic interrupts generated by the system clock. Instead, process scheduling is triggered by a periodic interrupt from a source selected at the time the FRS is initialized.

FRS interrupt sources

The interrupt source for the FRS can be the hardware timer, an external interrupt signal fed directly from the back panel of an Origin or Onyx2 system, a signal from a user process (useful for single stepping and debugging), the vertical retrace interrupt on an Onyx2 system, or any kernel-level device driver.

The FRS provides general-purpose kernel support for periodic scheduling of IRIX processes

Each incoming interrupt triggers a minor frame of the FRS. Every minor frame is associated with a queue of processes to be run within that frame. The list of processes in the queue is maintained in priority order, which specifies the order in which the processes will be run. In addition to a priority, each process is assigned an attribute which specifies its preemption behavior. For example, a process can either be required to complete execution within a minor frame, or be allowed to continue execution during the next minor frame. (If another process is enqueued at a higher priority in the next frame, that process will be run first.) An enqueued process can also be assigned a non-real-time priority, which means that it will run only when all real-time processes have completed their executions. This attribute is useful for a "cycle-burner" process, which measures the spare time in a frame. The selection of available attributes makes the FRS a general-purpose mechanism that can be tailored to meet a wide range of scheduling requirements.

A user-defined number of minor frames comprise a major frame. The minor/major frame construct enables multiple, related frame rates to be created.

For the case where real-time processes do not complete execution within their specified frames, the FRS provides a choice of three frame overrun recovery behaviors. The FRS can stretch time by extending the current frame without affecting the duration of the subsequent frame. It can steal time by extending the current frame and subtracting that time from the following frame. The third option is to insert a phantom frame, which is equivalent to stretching time by one complete minor frame.

FRS frame overrun recovery behaviors