Linux Kernel Architecture

(Jacob Rumans) #1

Chapter 14: Kernel Activities


The softIRQ daemons of the system are generated shortly afterinitis called at system startup using the
initcallmechanism described in Appendix D. After initialization, each daemon executes the following
endless loop^17 :

kernel/softirq.c
static int ksoftirqd(void * __bind_cpu)
...
while (!kthread_should_stop()) {
if (!local_softirq_pending()) {
schedule();
}

__set_current_state(TASK_RUNNING);

while (local_softirq_pending()) {
do_softirq();
cond_resched();
}
set_current_state(TASK_INTERRUPTIBLE);
}
...
}

Each time it is awakened, the daemon first checks whether marked softIRQs are pending, as otherwise
control can be passed to another process by explicitly invoking the scheduler.

If there are marked softIRQs, the daemon gets on with servicing them. In awhileloop the two functions
do_softirqandcond_reschedare invoked repeatedly until no marked softIRQS remain.cond_resched
ensures that the scheduler is called if theTIF_NEED_RESCHEDflag was set for the current process (see
Chapter 2). This is possible because all functions execute with enabled hardware interrupts.

14.3 Tasklets


Software interrupts are the most effective way of deferring the performance of activities to a future
point in time. However, this deferral mechanism is very complicated to handle. Because softIRQs can
be serviced simultaneously and independently onseveral processors, the handler routine of one and
the same softIRQ can run on several CPUs at the same time. This represents a key contribution to the
effectiveness of the concept — network implementation is a clear winner on multiprocessor systems.
However, the handler routines must be designed to be fully reentrant and thread-safe. Alternatively,
critical areas must be protected with spinlocks (or with other IPC mechanisms; see Chapter 5), and this
requires a great deal of careful thought.

Tasklets and work queues are mechanisms for the deferred execution of work; their implementation is
based on softIRQs, but they are easier to use and therefore more suitable for device drivers (and also for
other general kernel code).

(^17) kthread_should_stop()returns a true value if the softIRQ daemon is stopped explicitly. Since this happens only when a
CPU is removed from the system, I will not discuss this case. I also omit preemption handling for the sake of clarity.

Free download pdf