IBM 10 SP1 EAL4 5.1.8 I/O interrupts

requests. This capability makes it behaves similarly to the Anticipatory I/O scheduler. I/O priorities are also

considered for the processes, which are derived from their CPU priority.

The noop I/O scheduler can be considered as a rather minimal I/O scheduler that performs, as well as

provides, basic merging and sorting functionalities. The main usage of the noop scheduler revolves around

non-disk-based block devices, such as memory devices, as well as specialized software or hardware

environments that incorporate their own I/O scheduling and large caching functionality, thus requiring only

minimal assistance from the kernel.

5.1.8 I/O interrupts

The Linux kernel supports concurrent execution of multiple tasks. Each active task gets a portion of the CPU

time to advance its execution. Apart from this, the CPU also has to respond to address space violations, page

faults, synchronous signals from the CPU control unit, and asynchronous signals from devices such as a

keyboard or a network card. This section describes how the Linux kernel handles these asynchronous

interrupts generated by I/O devices.

Various I/O devices, such as the keyboard, communicate with the CPU regarding events occurring in the

device, such as a key typed at the keyboard, by sending special electrical signals to the CPU. The CPU

receives the signal and communicates it to the kernel for processing. Depending on the signal, the kernel

executes an appropriate interrupt handler to process the event.

Responsiveness of the system can be increased by promptly handling the interrupts. However, depending on

the type of the interrupt, not all actions associated with handling an interrupt must be executed immediately.

Therefore, an interrupt handler can be thought to consist of two sets of operations.

The first set, which is called the top half, consists of operations that must be executed immediately. The

second set, which is called the bottom half, consists of operations that can be deferred. The top half usually

includes the most critical tasks, such as acknowledging the signal. The Linux kernel provides three

mechanisms for implementing a bottom half of an interrupt handler. They are softirqs, tasklets, and work

queues.

Top halves perform critical parts of interrupt-related tasks such as acknowledging interrupts to the PIC,

reprogramming the PIC or device controller, and updating data structures accessed by both device and

processor.

Bottom halves perform interrupt-related tasks that were not performed by the top half of the interrupt handler.

That is, bottom halves perform the work that was deferred by the top halves because it was not absolutely

necessary to perform it in the top half.

Softirqs are statically linked (defined at compile time) bottom halves that execute in the interrupt context.

Many softirqs can always be executed concurrently on several CPUs even if they are of same type.