Software Interrupts

Software interrupts enable the kernel to defer tasks. Because they function in a similar way to the interrupts described above but are implemented fully in the software, they are logically enough known as software interrupts or softlRQs.

The kernel is informed of an anomalous condition by means of a software interrupt, and the situation is resolved at some later time by special handler routines. As already noted, the kernel services all pending software interrupts at the end of do_IRQ so that regular activation is ensured.

16Since the patch that introduced the change had to change every ISR, it might well be the one to touch most files at a single blow in the kernel history.

From a more abstract view, software interrupts can therefore be described as a form of kernel activity that is deferred to a later point in time. However, despite the clear similarities between hardware and software interrupts, they are not always comparable.

The central component of the softIRQ mechanism is a table with 32 entries to hold elements of the softirq_action type. This data type has a very simple structure and consists of two elements only:


struct softirq_action {

void (*action)(struct softirq_action *); void *data;

Whereas action is a pointer to the handler routine executed by the kernel when a software interrupt occurs, data accepts a nonspecified pointer to private data of the handler function.

The definition of the data structure is architecture-independent, as is the complete implementation of the softIRQ mechanism. With the exception of processing activation, no processor-specific functions or features are deployed; this is in clear contrast to normal interrupts.

Software interrupts must be registered before the kernel can execute them. The open_softirq function is provided for this purpose. It writes the new softIRQ at the desired position in the softirq_vec table:

kernel/softirq.c void open_softirq(int nr, void (*action)(struct softirq_action*), void *data) {

softirq_vec[nr].data = data; softirq_vec[nr].action = action;

data is used as a parameter each time the action softIRQ handler is called.

The fact that each softIRQ has a unique number immediately suggests that softIRQs are relatively scarce resources that may not be used randomly by all manner of device drivers and kernel parts but must be used judiciously. By default, only 32 softIRQs may be used on a system. However, this limit is not too restrictive because softIRQs act as a basis for implementing other mechanisms that also defer work and are better adapted to the needs of device drivers. The corresponding techniques (tasklets, work queues, and kernel timers) are discussed below.

Only the central kernel code uses software interrupts. SoftIRQs are used at a few points only, but these are all the more important:








Two serve to implement tasklets (hi_softirq and tasklet_softirq), two are used for send and receive operations in networks (net_tx_softirq and net_rx_softirq, the source of the softlRQ mechanism and its most important application), one is used by the block layer to implement asynchronous request completions (block_softirq), and one is used by the scheduler (sched_softirq) to implement periodic load balancing on SMP systems. When high-resolution timers are enabled, they also require a softlRQ (hrtimer_softirq).

Numbering of the softlRQs produces a priority sequence, which does not affect the frequency of execution of individual handler routines or their priority with respect to other system activities, but does define the sequence in which the routines are executed if several are marked as active or pending at the same time.

raise_softirq(int nr) is used to raise a software interrupt (similarly to a normal interrupt). The number of the desired softlRQ is passed as a parameter.

This function sets the corresponding bit in the per-CPU variable irq_stat[smp_processor_id]._

softirq pending. This marks the softlRQ for execution but defers execution. By using a processor-specific bitmap, the kernel ensures that several softlRQs — even identical ones — can be executed on different CPUs at the same time.

Providing raise_softirq was not called in the interrupt context, wakeup_softirqd is called to wake the softlRQ daemon; this is one of the two alternative ways of launching the processing of softlRQs. The daemon is discussed in more detail in Section 14.2.2.

Continue reading here: Starting SoftlRQ Processing

Was this article helpful?

0 0