Analysis of Linux Interrupt processing principle

First you need to understand the concept of interrupts: an "interrupt" is just a signal that can be sent when the hardware needs to gain attention from the processor. The kernel maintains a registry of interrupt signal lines similar to the I/O port registry.

The module requests an interrupt channel (or interrupt request IRQ) before using the interrupt, and then releases the channel after use. The API used is REQUEST_IRQ () and FREE_IRQ (). Note that the time to call REQUEST_IRQ () and FREE_IRQ () is best when the device is first opened and after the last shutdown.

A typical task for an interrupt-handling routine is that if the interrupt notifies the process that the event is waiting, such as when the new data arrives, it wakes up the process that is dormant on that device. Whether fast or slow-processing routines, programmers should write processing routines that perform as short a event as possible. If you need to perform a lengthy computation task, the best way to do this is to use the upper and lower half of the processing mechanism to allow the work to dispatch the compute tasks in a more secure time.

The function on the top half is a response interrupt. When an interrupt occurs, it hangs the lower half of the interrupt processing routine in the device driver into the bottom half of the device to execute the queue, and then continues waiting for a new interrupt to arrive. In this way, the upper part executes quickly, and it can accept more interrupts from the equipment it is responsible for. The upper part is fast because it is completely shielded from interruption, if it is not finished, the other interrupts can not be processed in a timely manner, only wait until the interrupt handler has finished executing. Therefore, in order to service and deal with as many interruptions as possible to the equipment, the interrupt handler must be fast.

The lower part of the function is to deal with a more complex process. The biggest difference between the lower half and the top half is interruptible, while the upper half is not interrupted. The lower half is almost complete with the interrupt handler, because the top half is just the bottom half of the processing queue for the device that they are responsible for, and then no other processing is done. The second part of the job is generally to view the device to obtain the information of the event that generated the interruption, and according to this information (generally by reading the device on the register) for the corresponding processing. The lower half is interruptible, so during operation, if the other device interrupts, the lower half can be temporarily interrupted, wait until the top half of the device runs out, and then turn back to the lower half.

Most of this is what we are looking for in the material and listening to the teacher to get the knowledge content but how specifically to achieve it?

Maybe we also know Tasklet and Work_queue. Know that these two are finished in the lower half. How will we achieve this in the specific process?

This is done by creating a work queue in which we put the initialized operation before the IRQ and commit the specific work to the work queue in Irq_handler (). The API used is queue_work (). Specific details are expected to be made available to the reader on their own.

as a new mechanism, Tasklet can obviously take on more advantages. Just at this time the SMP is getting more and more fire, so the SMP mechanism is added in the Tasklet to ensure that the same interrupts can only be executed on one CPU. In the era of soft interruptions, this is clearly not considered. Therefore the same interrupt can be executed simultaneously on two CPUs, which is likely to cause a conflict.

The next half of Linux interrupts are handled in three ways: soft interrupt, Tasklet, and task queue.

I have been asked why I want to divide these kinds, how to use. The book was used to deceive the past, but I understand that they do not really understand. Recently there is time, so try to tidy up the Linux interrupt processing mechanism, the purpose is at least from the principle to be able to make sense.

One, the simplest interrupt mechanism

The simplest interrupt mechanism is to fill in the interrupt vector table with instructions to jump to the corresponding handler function as described in the chip manual, and then implement the required functionality in the processing function. Similar:

This method is often used in the original SCM course, and some simple SCM systems are used in this way.

Its benefits are obvious, simple and straightforward.

Second, the lower half of the

What is the first thing that the interrupt handler does? The answer is to block interrupts (or to do nothing, because often if you do not clear the IF bit, it is equal to the shield is interrupted), of course, only the same interrupt is masked. The reason to block interrupts is because new interrupts call the interrupt handler again, causing the damage to the original interrupt processing site. That is, the destruction of the interrupt context.

With the continuous complexity of the system, the interrupt processing function to do more and more things, too late to receive new interrupts. The interruption is lost, which obviously does not work, resulting in a new mechanism: separating the interrupt reception and the interrupt processing process. Interrupt reception is done in the case of a shielded interrupt, and the interrupt processing is done in the case of interruption, which is called the lower half of the interrupt.

From this, only look at the treatment of int0. FUNC0 is the interrupt receive function. Interrupts can simply trigger func0, while FUNC0 can do more, and it can use caching mechanisms such as queues between Funca. When another interrupt occurs, the FUNC0 is triggered, then an interrupt request is sent to the cache queue, and then the Funca is processed.

Since the func0 do is very simple, it does not affect the int0 reception. And when the func0 returns, it will enable int0, so the Funca execution time is longer and will not affect the int0 reception.

Third, soft interrupt

Here's a look at Linux interrupt handling. As an operating system, it is clearly not possible to allow each outage to be fragmented, and unified management is a must.

The common part of our non-interruptible part is placed in the function DO_IRQ, which needs to be implemented by REQUEST_IRQ when the interrupt handler is added. The lower half is placed in the DO_SOFTIRQ, which is the soft interrupt, and the corresponding processing function is added through OPEN_SOFTIRQ.

Iv. Tasklet

When old things cannot keep up with the development of history, there will always be new things.

As the number of interrupts increases, the soft interrupts are not enough, and the second half has evolved.

Soft interrupts are handled in the form of polling. If it happens to be the last interrupt, you must loop through all of the interrupt types before you can finally execute the corresponding handler function. It was clear that the developers in order to ensure the efficiency of polling, so limit the number of interrupts is 32.

In order to improve the processing efficiency, the Tasklet mechanism was created to increase the number of interrupt processing.

Tasklet uses a non-discriminatory queuing mechanism, which executes only when there is an interruption, eliminating the pain of a circular look-up table.

Summarize the advantages of Tasklet:

(1) No type quantity limit;

(2) High efficiency, no need to cycle check table;

(3) Support SMP mechanism;

V. Work queue

The previous mechanism no matter how toss, one thing will not change. They are all in the context of the interrupt. What do you mean? Indicates that they cannot be suspended. And because it is serially executed, it can cause delays in other interrupt responses as long as one has a longer processing time. In order to accomplish these impossible tasks, a work queue appears. The work queue is plainly a set of kernel threads to use as an interrupt daemon. Multiple interrupts can be placed in one thread, or each interrupt can be assigned one thread.

The work queue encapsulates threads and makes them easier to use.

Because the work queue is a thread, we can use all the methods that can be used in threads.

Tasklet is not necessarily executed in an interrupt context, it is also possible to execute in a thread.

If the number of interrupts is large and the interrupts are self-priming (the interrupt handler causes a new interrupt), it is possible that the CPU has been executing the interrupt handler here, causing the user process to never get the scheduled time.

To avoid this situation, the Linux discovery of an excessive number of interrupts, will put the extra interrupt processing in a separate thread to do, that is, KSOFTIRQD thread. This ensures that the response speed is not long, but also ensure that the interruption of the user process will not starve.

The problem is that we cannot guarantee that our tasklet or soft interrupt handlers will be executed in the thread, so there are some methods that cannot be used by the process, such as abort scheduling, long delay, and so on.

Vi. Summary of Usage methods

REQUEST_IRQ hangs the interrupt function to be as simple as possible, only must do in the shielding interruption situation to do the thing.

The rest of the break is done in the lower part.

The principle of using soft interrupts is simple and never used. It is not even a kind of interrupt processing mechanism, but the tasklet is the basis of implementation.

Work queues are also used sparingly, and do not use the queue if there are some mechanisms that must be used for threading. In fact, for the interruption, just a simple processing of interrupts, most of the work is done in the driver. So what's the need to use a work queue?

In addition to the above, the use of tasklet is necessary.

Even the bottom half, just do what must be done in the interruption, such as saving data, etc., all the other to the driver to do.

Copyright NOTICE: This article is "lend you a second" original article, reproduced please indicate the source.

Analysis of Linux Interrupt processing principle