What is the role of linux softirqs and work queues

Interrupt vectors 0-31 have been reserved, leaving a total of 224 interrupt vectors 32-255 available. How are these 224 interrupt vectors allocated? In 2.6 version of Linux, except 0x80 (SYSCALL_VECTOR) which is used as the system call main entrance, the others are used for external hardware interrupt sources, including 15 irqs of the programmable interrupt controller 8259A; in fact, when CONFIG_X86_IO_APIC is not defined, the other 223 (except 0x80) interrupt vectors only use 15 starting from the 32nd, and the other 208 are left empty.

　2.2 Interrupt request

##　2.2.1 Interrupt request Overview

When external devices require the operating system to do related things, they will generate corresponding interrupts.

The device sends a high level to the interrupt controller through the corresponding interrupt line to generate an interrupt signal, and the operating system will obtain that interrupt line from the status bit of the interrupt controller. interrupts generated. And only when the device has control over a certain interrupt line, it can send a signal to this interrupt line. Also because there are more and more peripherals nowadays, interrupt lines are very precious resources and cannot be mapped one to one. Therefore, before using the interrupt line, you must apply for the corresponding interrupt line. Regardless of whether the shared interrupt method or an exclusive interrupt is used, the application process is to first scan all the interrupt lines to find out which ones are not occupied by others, and select one of them as the IRQ of the device. Secondly, apply for the corresponding IRQ through the interrupt application function. Finally, check whether the interrupt can be executed based on the application result.

　2.2.2 Interrupt related structures

The core processes data during interruption The structure is irq_desc, which completely describes an interrupt line. The source code in Linux 2.6.22.6 is as follows.

irq_desc is defined in include/linux/irq.h

/**
 * struct irq_desc - interrupt descriptor
 *
 * @handle_irq:        highlevel irq-events handler [if NULL, __do_IRQ()]
 * @chip:        low level interrupt hardware access
 * @msi_desc:        MSI descriptor
 * @handler_data:    per-IRQ data for the irq_chip methods
 * @chip_data:        platform-specific per-chip private data for the chip
 *            methods, to allow shared chip implementations
 * @action:        the irq action chain
 * @status:        status information
 * @depth:        disable-depth, for nested irq_disable() calls
 * @wake_depth:        enable depth, for multiple set_irq_wake() callers
 * @irq_count:        stats field to detect stalled irqs
 * @irqs_unhandled:    stats field for spurious unhandled interrupts
 * @lock:        locking for SMP
 * @affinity:        IRQ affinity on SMP
 * @cpu:        cpu index useful for balancing
 * @pending_mask:    pending rebalanced interrupts
 * @dir:        /proc/irq/ procfs entry
 * @affinity_entry:    /proc/irq/smp_affinity procfs entry on SMP
 * @name:        flow handler name for /proc/interrupts output */struct irq_desc {
    irq_flow_handler_t    handle_irq;    struct irq_chip        *chip;    struct msi_desc        *msi_desc;    void            *handler_data;    void            *chip_data;    struct irqaction    *action;    /* IRQ action list */
    unsigned int        status;        /* IRQ status */

    unsigned int        depth;        /* nested irq disables */
    unsigned int        wake_depth;    /* nested wake enables */
    unsigned int        irq_count;    /* For detecting broken IRQs */
    unsigned int        irqs_unhandled;
    spinlock_t        lock;
#ifdef CONFIG_SMP
    cpumask_t        affinity;
    unsigned int        cpu;#endif#if defined(CONFIG_GENERIC_PENDING_IRQ) || defined(CONFIG_IRQBALANCE)
    cpumask_t        pending_mask;#endif#ifdef CONFIG_PROC_FS    struct proc_dir_entry    *dir;#endif
    const char        *name;
} ____cacheline_internodealigned_in_smp;

The associated structures are as follows:

irqaction

struct irqaction {
    irq_handler_t handler;
    unsigned long flags;
    cpumask_t mask;    const char *name;    void *dev_id;    struct irqaction *next;    int irq;    struct proc_dir_entry *dir;
};

/**
 * struct irq_chip - hardware interrupt chip descriptor
 *
 * @name:        name for /proc/interrupts
 * @startup:        start up the interrupt (defaults to ->enable if NULL)
 * @shutdown:        shut down the interrupt (defaults to ->disable if NULL)
 * @enable:        enable the interrupt (defaults to chip->unmask if NULL)
 * @disable:        disable the interrupt (defaults to chip->mask if NULL)
 * @ack:        start of a new interrupt
 * @mask:        mask an interrupt source
 * @mask_ack:        ack and mask an interrupt source
 * @unmask:        unmask an interrupt source
 * @eoi:        end of interrupt - chip level
 * @end:        end of interrupt - flow level
 * @set_affinity:    set the CPU affinity on SMP machines
 * @retrigger:        resend an IRQ to the CPU
 * @set_type:        set the flow type (IRQ_TYPE_LEVEL/etc.) of an IRQ
 * @set_wake:        enable/disable power-management wake-on of an IRQ
 *
 * @release:        release function solely used by UML
 * @typename:        obsoleted by name, kept as migration helper */struct irq_chip {    const char    *name;
    unsigned int    (*startup)(unsigned int irq);　　//中断开始    void        (*shutdown)(unsigned int irq);　　　　//中断关闭    void        (*enable)(unsigned int irq);　　　　　　//中断使能    void        (*disable)(unsigned int irq);　　　　//中断禁用    void        (*ack)(unsigned int irq);    void        (*mask)(unsigned int irq);    void        (*mask_ack)(unsigned int irq);    void        (*unmask)(unsigned int irq);    void        (*eoi)(unsigned int irq);    void        (*end)(unsigned int irq);    void        (*set_affinity)(unsigned int irq, cpumask_t dest);    int        (*retrigger)(unsigned int irq);    int        (*set_type)(unsigned int irq, unsigned int flow_type);    int        (*set_wake)(unsigned int irq, unsigned int on);    /* Currently used only by UML, might disappear one day.*/#ifdef CONFIG_IRQ_RELEASE_METHOD    void        (*release)(unsigned int irq, void *dev_id);#endif
    /*
     * For compatibility, ->typename is copied into ->name.
     * Will disappear.     */
    const char    *typename;
};

Upper and lower half Internal mechanism

——upper and lower half mechanism.

accepts the interrupt, and it starts executing immediately, but it can only do work with a strict time limit. Work that can be allowed to be completed later will be postponed to the second half, and then, at the appropriate time, the second half will be executed by the terminal. The first half is simple and fast, disabling some or all interrupts during execution.

can respond to all interrupts during execution. This design can make the system in the interrupt shielding state as short as possible, thereby improving the system's responsiveness. The upper half only has the interrupt handler mechanism, while the lower half has soft interrupt implementation, tasklet implementation and work queue implementation.

If a task is very time-sensitive, put it in the interrupt handler implement;

　2) If a task is related to hardware, put it in the interrupt handler for execution;

　3) If a The task must ensure that it is not interrupted by other interrupts and be executed in the interrupt handler;

　4) For all other tasks, consider placing them in the lower half for execution .

Soft interrupt of the lower half implementation mechanism

Soft interrupt, as the representative of the lower half mechanism, is followed by## The emergence of #SMP (share memory processor) came into being, and it is also the basis for the implementation of tasklet (tasklet is actually only used in soft interrupts. A certain mechanism has been added based on this). Softirq is generally the general term for "Delayable function", sometimes including tasklet (readers are asked to infer whether it contains # based on the context when encountering it) ##tasklet). It appears because it needs to satisfy the distinction between the upper and lower halves proposed above, so that tasks that are not time-sensitive can be deferred. The soft interrupt executes the remaining tasks left to it by the interrupt handler, and can Parallel execution on multiple CPU makes the overall system efficiency higher. Its features include: ## a

b

CPU (even the same type). Therefore, soft interrupts must be designed as reentrant functions (allowing multiple CPU to operate at the same time), so spin locks also need to be used to protect their data structures.

Tasklet

Soft interrupts are processed in a polling manner. If it happens to be the last type of interrupt, all interrupt types must be cycled before the corresponding processing function can finally be executed. Obviously, in order to ensure the efficiency of polling, the developers limited the number of interrupts to

. In order to increase the number of interrupt processing and improve processing efficiency, the

mechanism was born.

Tasklet adopts an undifferentiated queue mechanism and is executed only when there is an interruption, eliminating the pain of circular table lookup. TaskletAs a new mechanism, it can obviously bear more advantages. At this time, SMP became more and more popular, so the SMP mechanism was added to tasklet to ensure that the same type of interrupt can only be processed on one cpu Execute on . In the era of soft interrupts, there was obviously no such consideration. Therefore, the same soft interrupt can be executed on two cpu at the same time, which is likely to cause conflicts.

# Summary of the advantages of tasklet:

1）No limit on the number of types;

2）High efficiency, no need to loop table lookup;##　（

) Supports SMP mechanism; ## Its characteristics are as follows:

　1) A specific type of

can only run on one CPU, and cannot be executed in parallel, but can only be executed serially. 2) Multiple

of different types can be run in parallel on multiple CPU on. ## 3) Soft interrupts are statically allocated and cannot be changed after the kernel is compiled. But tasklet

The lower half of the implementation mechanism is the work queue

The deferrable function we introduced above runs in the interrupt context (one checkpoint of soft interrupt is when do_IRQ exits), which leads to some problems: soft interrupt cannot sleep or block. Since the interrupt context is in the kernel state and there is no process switching, if the soft interrupt is put to sleep or blocked, it will not be able to exit this state, causing the entire kernel to freeze. However, blocking functions cannot be implemented in the interrupt context and must be run in the process context, such as functions that access disk data blocks. Therefore, blocking functions cannot be implemented using softirqs. But they often have deferrable properties.

The deferrable functions we introduced above run in the interrupt context, which causes some problems, indicating that they cannot be suspended, which means that soft interrupts cannot sleep , cannot block. The reason is that the interrupt context is in the kernel state and there is no process switching. Therefore, once the soft interrupt sleeps or is blocked, it will not be able to exit this state, causing the entire kernel to freeze. Therefore, blocking functions cannot be implemented using softirqs. But they often have deferrable properties. And since it is executed serially, as long as one processing time is long, it will cause a delay in the response of other interrupts. In order to complete these impossible tasks, a work queue emerged, which can switch between different processes to complete different tasks.

If the postponed task requires sleep, then choose the work queue. If sleep is not required, then choose soft interrupt or tasklet. Work queues can run in process context and delegate work to a kernel thread. To put it simply, the work queue is a group of kernel threads, used as interrupt daemon threads. Multiple interrupts can be placed in one thread, or each interrupt can be assigned a thread. We use the structure workqueue_struct to represent the worker thread, which is implemented using the kernel thread. And how the worker thread executes the postponed work——There is such a linked list, which consists of the structure work_struct, and this work_struct describes A job, once the job is executed, the corresponding work_struct object is removed from the linked list. When there are no more objects on the linked list, the worker thread will continue to sleep. Because work queues are threads, we can use all the methods that can be used in threads.

#What is the role of soft interrupts and work queues in Linux

The role of soft interrupts and work queues in Linux is to implement interrupt processing; they are the upper and lower interrupt mechanisms The lower half of the implementation mechanism.

　1.Soft interrupt is generally the general name of "Delayable function". It cannot sleep or block. , it is in the interrupt context and cannot switch between processes. Soft interrupts cannot be interrupted by themselves, but can only be interrupted by hardware interrupts (upper part). They can run concurrently on multiple CPU. Therefore, soft interrupts must be designed as reentrant functions, so spin locks are also needed to protect their data structures.

　2.The function in the work queue is in the process context. It can sleep or be blocked, and can switch between different processes to complete different tasks.

Neither the deferrable function nor the work queue can access the user's process space. There cannot be any running process when the deferrable function is executed. The work queue function has While the kernel process is executing, it cannot access user space addresses.

Linux Video Tutorial"