Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "what is the use of linux soft interrupts and work queues", so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this article, "what is the use of linux soft interrupts and work queues?"

The role of soft interrupts and work queues in linux is to implement interrupt handling. Soft interrupt and work queue are the implementation mechanisms of the lower part of the interrupt mechanism. Soft interrupts can not sleep, can not block, can not switch between processes, and can only be interrupted by hardware interrupts, while work queues can sleep or be blocked, and can switch between different processes to complete different tasks.

The operating environment of this tutorial: linux5.9.8 system, Dell G3 computer.

The role of soft interrupts and work queues in linux is to implement interrupt handling.

1. Interruption concept

Interruption means that during the normal operation of CPU, due to internal and external events or events prearranged by the program, CPU temporarily stops the running program and turns to serve the internal or external event or prearranged event, and then returns to run the temporarily interrupted program after the service is completed. Linux is usually divided into external interrupts (also called hardware interrupts) and internal interrupts (also known as exceptions).

In the field addressing mode, CPU uses the 0-based 1KB space in memory as an interrupt vector table. Each item in the table occupies 4 bytes. However, in the protected mode, the interrupt vector table composed of these four-byte items does not meet the actual needs, so according to the information reflecting the mode switching and the sufficient offset, the interrupt vector table consists of 8 bytes, and the interrupt vector table is also called interrupt descriptor table (IDT). An interrupt descriptor table register (IDTR) is added to CPU to hold the starting address of the interrupt descriptor table.

2. Linux interrupt processing

2.1 system interrupt number

According to the above interrupt definition, the system interrupt vector table can save a total of 256interrupt vector entries, that is, 256interrupt descriptors (corresponding to 256interrupt vectors) contained in IDT.

The interrupt vector 0-31 is reserved by intel to handle abnormal events and cannot be used for other purposes. For the 0-31 interrupt vector, the operating system only needs to provide an exception handler. When an exception occurs, the processor will automatically transfer control to the entry of the corresponding handler and run the corresponding handler. In fact, for these 32 interrupt vectors that handle exceptions, version 2.6 of Linux only provides handlers for interrupt vectors 0-17, and their corresponding handlers are shown in the table below, interrupt vectors and exception event correspondence tables; that is, interrupt vectors 17-31 are empty and unused.

Interrupt vector number exception event Linux handler 0 division error pide_error1 debug exception Debug2NMI interrupt Nmi3 single byte Int 3Int34 overflow Overflow5 boundary monitoring interrupt Bounds6 invalid opcode Invalid_op7 device unavailable Device_not_available8 double fault Double_fault9 coprocessor segment overflow Coprocessor_segment_overrun10 invalid TSSIncalid_tss11 missing segment interrupt Segment_not_present12 stack exception Stack_segment13 general protection exception General_protection14 page exception Page_fault15 (intel retention) Spurious_interrupt_bug16 coprocessor error Coprocessor_error17 alignment check interrupt Alignment_check

0-31 interrupt vectors have been reserved, so a total of 32-255 interrupt vectors are available. How are these 224 interrupt vectors allocated? In version 2.6 of Linux, except for 0x80 (SYSCALL_VECTOR), which is used as the total entry of system calls, all the others are used in external hardware, including 15 irq; of programmable interrupt controller 8259A. In fact, when CONFIG_X86_IO_APIC is not defined, the other 223 interrupt vectors (except 0x80) only take advantage of 15 since the 32th, and the other 208are empty.

2.2 interrupt request

2.2.1 Overview of interrupt request

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

The device sends a high level to the interrupt controller through the corresponding interrupt line to generate an interrupt signal, while the operating system acquires the interrupt generated on that interrupt line from the state bit of the interrupt controller. And only if the device has control over a certain interrupt line can a signal be sent to that interrupt line. And because there are more and more peripherals now, the interrupt line is a very valuable resource that can not be corresponded one by one. Therefore, before using the break line, you have to apply for the corresponding break line. Whether it is a shared interrupt or an exclusive interrupt, the application process is to scan all the interrupt lines to find out which are not occupied, and choose one of them as the IRQ of the device. Secondly, apply for the corresponding IRQ by interrupting the application function. Finally, check whether the interrupt can be executed according to the application result.

2.2.2 interrupt related structure

The core processing data structure in the interrupt is irq_desc, which completely describes an interrupt line, Linux 2.6. 22.6 the source code 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

Irq_desc

The associated structures are as follows:

Interrupt action structure defined in include/linux/ interrupt.h: struct 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;}

Set of processing functions related to irq_chip chips defined in include/linux

/ * * struct irq_chip-hardware interrupt chip descriptor * * @ name: name for / proc/interrupts * @ startup: startup the interrupt (defaults to-> enable if NULL) * @ shutdown: shutdown 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); / / interrupt start void (* shutdown) (unsigned int irq) / / interrupt disable void (* enable) (unsigned int irq); / / interrupt enable void (* disable) (unsigned int irq); / / interrupt disable 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;}

2.2.3 interrupt request implementation

Upper and lower half mechanism

We want to make the interrupt handler run fast, and we want it to do a lot of work. These two goals restrict each other, and how to solve them-- the upper and lower half mechanism.

We cut the interrupt processing in half. The interrupt handler is the upper part-when the interrupt is accepted, it starts execution immediately, but only for a strict time limit. Work that can be done later will be postponed to the lower half, after which, at the right time, the lower half will be opened for execution. The first half is simple and fast, and some or all interruptions are prohibited during execution.

The lower half is executed later, and all interrupts can be responded to during execution. This design can make the system stay in the interrupt shielding state as short as possible, so as to improve the response ability of the system. The first half only has interrupt handler mechanism, while the lower half has soft interrupt implementation, tasklet implementation and work queue implementation.

Let's use the network card to explain the two halves. When the network card receives the packet, it notifies the kernel and triggers the interrupt. The so-called upper half is to read the packet into memory in time to prevent loss due to delay, which is a very urgent task. After reading the memory, the processing of the data is no longer urgent, and the kernel can execute the program that was run before the interrupt, while the processing of the network packet is handed over to the lower half.

The principle of dividing the upper and lower parts

1) if a task is very time-sensitive, execute it in an interrupt handler

2) if a task is related to hardware, execute it in an interrupt handler

3) if a task is not interrupted by other interrupts, put it in the interrupt handler to execute

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

Soft interrupt in the second half of the implementation mechanism

As the representative of the lower part of the mechanism, soft interrupt came into being with the emergence of SMP (share memory processor), and it is also the basis of tasklet implementation (tasklet actually only adds a certain mechanism on the basis of soft interrupt). Soft interrupts are generally referred to as "delayable functions" and sometimes include tasklet (ask the reader to infer whether or not to include tasklet from the context when encountered). It appears because to satisfy the difference between the upper part and the lower part mentioned above, the time-insensitive task is delayed, the soft interrupt executes the remaining tasks left by the interrupt handler, and it can be executed in parallel on multiple CPU, so that the overall system efficiency can be higher. Its features include:

A) it can not be executed immediately after it is generated, and must wait for the scheduling of the kernel before it can be executed. The soft interrupt cannot be interrupted by itself, but can only be interrupted by the hardware interrupt (the upper part).

B) it can run concurrently on multiple CPU (even on the same type). So soft interrupts must be designed as reentrant functions (allowing multiple CPU to operate at the same time), so spin locks are also needed to protect their data structures.

The tasklet of the second half of the implementation mechanism

Tasklet is implemented through soft interrupts, so it is also a soft interrupt itself.

Soft interrupts are handled by polling. If it happens to be the last interrupt, you must loop through all the interrupt types before you can finally execute the corresponding handler. Obviously, in order to ensure the efficiency of polling, developers limited the number of interrupts to 32.

In order to increase the number of interrupt processing and improve the processing efficiency, the tasklet mechanism is produced.

Tasklet uses an undifferentiated queuing mechanism, which is executed only when there is an interrupt, eliminating the pain of cyclic table lookup. As a new mechanism, Tasklet can obviously bear more advantages. At this time, SMP is becoming more and more popular, so the SMP mechanism is added to tasklet to ensure that the same kind of interrupt can only be executed on one cpu. In the era of soft interrupts, it is clear that there is no such consideration. So the same kind of soft interrupt can be executed on both cpu at the same time, which is likely to cause conflict.

Summarize the advantages of tasklet:

(1) No type quantity limit

(2) High efficiency, no need to cycle to look up the table

(3) support SMP mechanism

Its features are as follows:

1) A specific type of tasklet can only run on one CPU, cannot be executed in parallel, and can only be executed serially.

2) multiple different types of tasklet can be parallel on multiple CPU.

3) soft interrupts are statically allocated and cannot be changed after the kernel has been compiled. But tasklet is much more flexible and can be changed at run time (such as when modules are added).

Work queue for the second half of the implementation mechanism (work queue)

The delayable function we described above runs in the interrupt context (one of the checkpoints of the soft interrupt is when the do_IRQ exits), which leads to some problems: the soft interrupt can't sleep or block. Because the interrupt context is in kernel state, there is no process switching, so once the soft interrupt sleeps or blocks, it will not be able to exit this state, resulting in the whole kernel will be dead. However, blocking functions cannot be implemented in an interrupt context and must be run in the context of a process, such as a function that accesses disk blocks. Therefore, blocking functions cannot be implemented with soft interrupts. But they often have the characteristic of delaying.

The delayable functions we described above run in the interrupt context, which leads to some problems, indicating that they cannot be suspended, that is, soft interrupts cannot sleep or block, because the interrupt context is in kernel state and there is no process switch. therefore, once the soft interrupt sleeps or blocks, it will not be able to exit this state, causing the entire kernel to freeze. Therefore, blocking functions cannot be implemented with soft interrupts. But they often have the characteristic of delaying. And because it is a serial execution, as long as one processing time is long, it will cause delays in other interrupt responses. In order to accomplish these impossible tasks, there is a work queue, which can switch between different processes to complete different tasks.

If the delayed task requires sleep, select the work queue, or soft interrupt or tasklet if you don't need sleep. The work queue can run in the context of a process and entrusts work to a kernel thread. To put it bluntly, the work queue is a set of kernel threads that are used as interrupt daemon threads. Multiple interrupts can be placed in a single thread, or one thread can be assigned to each interrupt. We use the structure workqueue_struct to represent the worker thread, which is implemented with the kernel thread. And how the worker thread performs the delayed work-there is a linked list that consists of the structure work_struct, and the work_struct describes a job, once the work is done, the corresponding work_struct objects are removed from the linked list, and when there are no more objects on the linked list, the worker thread continues to sleep. Because the work queue is a thread, we can use all the methods that can be used in the thread.

What is the function of Linux soft interrupts and work queues

The role of soft interrupts and work queues in linux is to implement interrupt handling; they are the lower half of the interrupt mechanism.

1. Soft interrupt is generally the general name of "delayable function", it can not sleep, can not block, it is in the interrupt context, can not switch between processes, soft interrupt can not be interrupted by itself, can only be interrupted by hardware interrupt (the top part), can run concurrently on multiple CPU. So soft interrupts must be designed as reentrant functions, so spin locks are also needed to protect their data structures.

two。 The function in the work queue is in the process context, it can sleep, it can be blocked, and it can switch between different processes to do different work.

Neither the delay function nor the work queue can access the user's process space, but the delay function can not have any running processes when it is executed. The work queue function has kernel process execution, and it cannot access the user space address.

The above is about the content of this article on "what is the use of linux soft interrupts and work queues". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.