Limitations interrupt handler
1. interrupt handler asynchronously executed, and it has the potential to interrupt other important code, therefore, in order to avoid being stopped playing section of the code too long, the interrupt handler should be executed as quickly as possible;
2. If there is a current interrupt handler in execution, in the best case (not set IRQF_DISABLED), with the same level of the interrupt other interrupts will be blocked, in the worst case (set IRQF_DISABLED), the current processing All other interrupts are on is shielded; because after disabling interrupts, hardware and operating systems can not communicate, therefore, the interrupt handler executed as quickly as possible;
3. Since the interrupt handler often requires the hardware to operate, so they usually have high time requirements;
4. The interrupt handler is not in process context to run, so they can not be blocked, which limits what they are doing;
Lower half
The lower half of the task is closely related to the implementation of interrupt handling but the interrupt handler itself does not work executed; in the ideal case, it is best interrupt handler will all work to the lower half of the execution, because we want to interrupt handler work done better, we expect the interrupt handler can return as soon as possible;
Interrupt handlers and the lower half is divided between the reference:
1. If a task is very sensitive to the incident, it is placed in an interrupt handler;
2. If a hardware-related tasks and then put it in the interrupt handler;
3. If a task is to ensure that no other interrupts (especially siblings interrupted) interrupted, then put it in the interrupt handler;
4. All other tasks, consider placing in the lower half of the execution;
The lower half of the way and selection
The lower half provides three ways: soft interrupt, tasklet and work queues; tasklet based soft interrupt achieved, so the two very close; they work queue mechanism is completely different, it achieved by kernel threads;
Soft interrupt the body with a minimum guarantee of the execution sequence, which requires soft interrupt handler must be careful to take some steps to ensure the security of shared data, two or more of the same type of software interrupt is possible on different processors Meanwhile execution; if their multi-threaded code inspection work is done very well, such as network subsystem, using a single processor it is fully variable, then the soft interrupt is a very good choice; for time-critical and high frequency execution application, it was also the fastest execution;
If the code is not sufficient to consider multi-threaded, then choose a larger tasklet sense; it's interface is very simple, and, because two of the same type tasklet can not be performed at the same time, it is also simpler to implement; tasklet is effective soft interrupt, but can not be executed concurrently; driver developers should choose tasklet as possible rather than soft interrupt; of course, if each processor is ready to use variables to ensure that run concurrently on multiple processors soft interrupt safe, then or choose soft interrupt;
If you need to put the task back to the context of the process is completed, then this can only choose among the three work queues, and the context is not necessary if the process conditions (that is, if you do not sleep), and then the soft interrupt tasklet may be more appropriate ; work queue caused by the most expensive, because it has to involve even a kernel thread context switching; this is not to say that the low efficiency of the work queue, if there are thousands of times per second interrupts, other mechanisms may be more appropriate;
Simply put, the general driver writers need to do two choices: first, the need is not a scheduling entity to perform after the completion of work needs to be pushed - Basically, you need to sleep? There, the work queue is the only option; otherwise, the best tasklet; If you must focus on improving performance, consider soft interrupt;