IBM 10 SP1 EAL4 User Manual
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.
considered for the processes, which are derived from their CPU priority.
5.1.7.4 Noop I/O scheduler
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.
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.
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.
5.1.8.1 Top halves
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.
reprogramming the PIC or device controller, and updating data structures accessed by both device and
processor.
5.1.8.2 Bottom halves
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.
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.
5.1.8.3 Softirqs
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.
Many softirqs can always be executed concurrently on several CPUs even if they are of same type.
53