Deep understanding of the Linux kernel Soft interrupt/tasklet/Task Force column

Soft interrupts, Tasklet, and work queues are not mechanisms that persist in the Linux kernel, but are evolved from the "lower half" (bottom half) in earlier versions of the kernel. The bottom half of the mechanism actually consists of five, but in the 2.6 version of the kernel, the lower half and the task queue functions disappear, leaving only the first three. The focus of this article is to introduce the relationship between the three. (The function details will not appear in this article, you can refer to the literature, click here)

(1) The difference between the top and bottom half
The upper part refers to the interrupt handler, while the lower part refers to some tasks that can be deferred, although they are related to interrupts. For example: In the network transmission, the NIC receives the packet this event does not need to be processed immediately, suitable for the lower half to achieve, but the user hit the keyboard such events must be immediately responded to, should be implemented with interrupts.
The main difference between the two is that interrupts cannot be interrupted by the same type of interrupt, while the lower half can still be interrupted, interrupts are very sensitive to time, and the lower half is basically a work that can be deferred. Because of this difference between the two, so for a job is placed in the upper half or in the lower part to perform, you can refer to the following four:
A) If a task is sensitive to time, it is placed in the interrupt handler for execution.
b) If a task is related to the hardware, put it in the interrupt handler to execute.
c) If a task is guaranteed not to be interrupted by another interrupt (especially the same interrupt), it is placed in the interrupt handler.
D) All other tasks, consider placing them in the lower part to perform.

(2) Why use soft interrupts?
As the representative of the lower half mechanism, the soft interrupt is based on the advent of the SMP (share memory processor), which is also the basis of tasklet implementation (Tasklet actually adds a certain mechanism on the basis of soft interrupts). A soft interrupt is generally a generic term for "deferred function", and sometimes includes Tasklet (the reader is inferred from the context when it encounters the inclusion of Tasklet). It occurs because the difference between the upper and lower halves of the above is met, so that time-insensitive tasks are deferred and can be executed concurrently on multiple CPUs, resulting in a higher overall system efficiency. Its features include:
A) does not execute immediately after it is generated, it must wait for the kernel to be dispatched. Soft interrupts cannot be interrupted by themselves and can only be interrupted by hardware interrupts (top half).
b) can run concurrently on multiple CPUs (even if the same type is possible). So a soft interrupt must be designed as a reentrant function (allowing multiple CPUs to operate simultaneously), so a spin lock is required to protect its data structure.

(3) Why use Tasklet? (The difference between tasklet and soft interrupts)
Because a soft interrupt must use a reentrant function, this results in a high degree of complexity in design, which adds a burden to the developer as a device driver. If an application does not need to be executed in parallel on multiple CPUs, then a soft interrupt is not necessary. Therefore, Tasklet was born to make up the above two requirements. It has the following characteristics:
A) a specific type of tasklet can only be run on one CPU, cannot be parallel, and can only be executed serially.
b) Multiple different types of tasklet can be parallel on multiple CPUs.
c) Soft interrupts are statically allocated and cannot be changed after the kernel has been compiled. However, Tasklet is much more flexible and can be changed at runtime (e.g. when adding modules).
Tasklet is implemented on the basis of two types of soft interrupts, but because of its special implementation mechanism (which will be described in detail in section 4.3), this feature is different from the soft interrupt. Because of this feature, it reduces the burden on the device driver developer, so Tasklet is the best choice if the parallel features of the soft interrupt are not required.

(4) Use of the deferred function (soft interrupt and Tasklet)
In general, there are four actions that can be performed on a deferred function: initialization/activation/execution/masking. Shielding we do not describe here, the first three are more important. The following is a comparison of the three steps of soft interrupts and tasklet.

(4.1) initialization
Initialization refers to all the work done before the deferred function is ready. It typically consists of two large steps: The first is to declare this deferred function to the kernel, in case the kernel is called when needed, and then to initialize the corresponding descriptor with the function pointer, etc., by invoking the corresponding initialization function.
If a soft interrupt occurs during kernel initialization, its descriptor is defined as follows:

struct softirq_action
{
void (*action) (struct softirq_action *);
Void*data;
};

An array of 32 descriptors was included in the \kernel\softirq.c file static struct softirq_action softirq_vec[32]; but actually only the first 6 have been registered with the kernel (including Tasklet used Hi_ SOFTIRQ/TASKLET_SOFTIRQ and the network protocol stack use the NET_TX_SOFTIRQ/NET_RX_SOFTIRQ, as well as SCSI storage and system timers using two), the rest can be used by the kernel developers. You need to use a function:
void Open_softirq (int nr, void (*action) (struct softirq_action*), void *data)
Initializes the element in the array that is indexed as Nr. The required parameters are, of course, the action function pointer and data. For example, the network subsystem Initializes a soft interrupt with the following two functions (Net_tx_action/net_rx_action is two functions):

OPEN_SOFTIRQ (net_tx_softirq,net_tx_action);
OPEN_SOFTIRQ (net_rx_softirq,net_rx_action);

This completes a one by one corresponding relationship when the initialization is complete: The Net_tx_action function is called after the Net_tx_softirq soft interrupt is generated in the kernel.
Tasklet can be defined at run time, such as when a module is loaded. There are two ways of defining this:
Static declaration

Declare_tasket (Name, func, data)
Declare_tasklet_disabled (Name, func, data)

Dynamic declaration

void Tasklet_init (struct tasklet_struct *t, void (*func) (unsigned long), unsigned Long data)

Its arguments are descriptors, the functions that need to be called, and the parameters of this function-must be unsigned long type. It also requires the user to write a function pointer func like net_tx_action. The result of initializing the final build is an actual descriptor, assumed to be my_tasklet (to be used below).

(4.2) Activation
Activation tag A deferred function is a pending (pending) state, which means that the kernel can invoke this deferred function (even though the deferred function can be activated in the interrupt process, but the function is not executed immediately), which can be analogous to a process in task_running state. The process in this state is only ready to be scheduled by the CPU, but not necessarily immediately.
Soft interrupts are activated using the RAISE_SOFTIRQ () function, and the received parameter is the array index used to initialize the above Nr.
Tasklet uses tasklet_schedule () activation, which accepts tasklet descriptors as arguments, such as the my_tasklet generated above:

Tasklet_schedule (& My_tasklet)

(4.3) implementation
Execution is the process by which the kernel runs a deferred function, but execution only occurs at certain points in time (called checkpoints, what are the specific checkpoints?). See "In-depth" p.177).
There is a 32-bit mask __softirq_pending on each CPU that indicates what hangs (has been activated) soft interrupts on this CPU. This mask can be obtained with the local_softirq_pending () macro. All pending soft interrupts need to be handled with a loop of the DO_SOFTIRQ () function.
For Tasklet, because of the soft interrupt initialization, the following statement has been initialized with the functions required to perform the two soft interrupts of the TASKLET_SOFTIRQ/HI_SOFTIRQ:

OPEN_SOFTIRQ (TASKLET_SOFTIRQ, tasklet_action, NULL);
OPEN_SOFTIRQ (HI_SOFTIRQ, tasklet_hi_action, NULL);

Therefore, these two soft interrupts are to be treated differently. The internal implementation of Tasklet_action and tasklet_hi_action is the reason why soft interrupts and tasklet have different characteristics (and of course, because the descriptors of the two are different, the Tasklet descriptor is more complex than the soft interrupt, This means that the kernel designer has done a bit more work on the limit and reduced the driver developer's work.

(5) Why do I use the work queue? (The difference between work queue and soft interrupt)
The deferred function we described above runs in the interrupt context (a checkpoint for soft interrupts is when DO_IRQ exits), causing some problems: soft interrupts cannot sleep and cannot be blocked. Because the interrupt context is out of the kernel state, there is no process switch, so if the soft interrupt is asleep or blocked, it will not be able to exit this state, causing the kernel to complete zombie. However, a blocking function cannot be implemented in an interrupt context and must be run in a process context, such as a function that accesses disk data blocks. Therefore, a blocking function cannot be implemented with a soft interrupt. However, they tend to have delayed characteristics.
Therefore, in the 2.6 version of the kernel, there is a work queue running in the kernel state (instead of the task queue in the 2.4 kernel). It also features a number of deferred functions (which need to be activated and deferred), but can be able to switch between different processes to accomplish different tasks.

Deep understanding of the Linux kernel Soft interrupt/tasklet/Task Force column