| Interrupt latency or interruption DelayThis refers to the time period from the interruption generation to the CPU response interruption, that is, the time period from T2 to T3 in the figure. The interrupt latency is caused by the kernel disabling the interrupt response of the CPU before entering the critical section. During this period, although the external device makes the interrupt request line of the CPU valid, however, the CPU does not immediately respond to the interruption, but continues to execute the kernel code in the critical section until the critical section is exited and the request can be interrupted. Of course, it should be noted that the interrupt latency actually includes the interruption delay time produced by the hardware. We generally study how to minimize the latency caused by the software, therefore, unless otherwise stated, we do not consider the delay caused by hardware (but in fact, in engineering applications, when the software optimization cannot meet the real-time requirements of the system, the only way is to increase the processing speed of the hardware ). Solution proposed in this article: 1. software interruption Simulation
Because Linux has many disconnected areas, this will lead to a long interruption period. When the interruption is frequent, there will be a possibility of losing external interruption, which is intolerable by the real-time system. The most direct way to solve this problem is to stop interruption. Here, we call it "no interruption", which means no interruption to the entire system. But for Linux itself, or from the perspective of Linux, linux has the same behavior as the actual disconnection. This method can be implemented using the software interrupt mode technology.
The software interruption mentioned in the software interruption mode technology is for Linux. That is to say, Linux does not directly control the hardware interruption. When Linux needs to be disconnected, in fact, it only sets a software identifier to indicate that Linux execution does not want to be interrupted at this time. When Linux is interrupted, the actual operation is to clear the software identifier. The actual hardware interruption is managed by a software layer between hardware and Linux. The main task of this software layer is to receive hardware interruptions and schedule Linux interrupt service programs as needed; when Linux is disconnected (hardware interruption is not actually prohibited), the simulation layer of software interruption continues to receive hardware interruption and records the interruption information in the log. When Linux is interrupted, the simulation layer calls the Linux interrupt service program based on the interrupt log;
The software interruption simulation technology can effectively prevent the loss of external interruptions. However, we should see that during Linux disconnection, external interruptions are still not responded (that is, the corresponding interrupt service program of Linux is not executed). Therefore, this technology does not shorten the system interrupt latency, and does not increase the system interrupt response time, it still cannot meet the requirements of real-time tasks for fast interrupt response time.2. Increase the kernel preemption point
From the analysis of the Linux task response model, we can see that the scheduling latency has a great impact on the task response time, A large part of the task response time (many tests in the literature can prove this); therefore, an important objective of Linux real-time optimization is to shorten the scheduling latency. So what are the factors that affect the Linux scheduling latency? The length of the scheduling latency is related to the running duration of Linux in the kernel state (from the time the System Service enters the kernel state to the time when the kernel state is exited). To reduce the scheduling latency, it is necessary to reduce the time for Linux to run continuously in the kernel state. The most intuitive method is to add a preemption point in the kernel code that has been executed for a long time (that is, to add some codes to actively request for scheduling ), the kernel code that has been executed for a long time is divided into several code segments for execution time. Process Scheduling can be performed between segments to shorten the scheduling latency.
It has been shown that increasing the kernel preemption point is the most effective way to shorten the scheduling latency. However, although the principle of this method is very simple, it is quite tedious and time-consuming to implement it. On the one hand, it is not easy to find out which parts of the kernel have a long execution time, And the execution time of the same Code in different system states is different, this requires dynamic analysis to find out the time-consuming code segments in the kernel. On the other hand, with the continuous development of the kernel, this method is less portable between different versions of the kernel, it also analyzes the newly added kernel code.
3. Use SMP technology to seize the kernel
Because the original design of the Linux kernel cannot be preemptible, that is to say, most of the kernel code does not consider the function re-entry (a system service is concurrently executed by two processes) and the mutex access to data, in this case, it is quite difficult to realize the preemption of the kernel. However, with the maturity of Linux's support for SMP (symmetric multi-processor), there has been a method to use SMP technology to realize kernel preemption. To achieve kernel preemption, the goal is similar to increasing the kernel preemption point. In fact, it is also to shorten the scheduling latency.
To achieve kernel preemption, the main task is to find out which code may be called by the process concurrently and protect the related critical section to maintain data consistency. The support for SMP is similar, because in a multi-processor system, multiple processes can run simultaneously and access the same critical resources. Therefore, you can use the Linux kernel to support SMP and implement kernel preemption. In a preemptible kernel, when a high-priority process can run, the system immediately schedules the process. Of course, in some cases, kernel preemptible is not allowed, this mainly includes the following situations:
1) when the system is processing the interrupted service program, it cannot be preemptible. The interrupted service program is asynchronous and irrelevant to the process. It does not belong to a specific process, there is no process attribute (that is, there is no process Context Environment), so it does not meet the conditions for preemption (no preemptible object ).
2) when the system is processing the lower half of the interrupt (bottom half), preemption is not allowed. The reason is the same as that in the first case.
3) A system holding a spin lock, write lock, or read lock during operation cannot be preemptible. These locks are used to support SMP. In an SMP system, these locks are used to protect critical zones, control the mutex access of processes running on different processors to the critical zone. That is to say, when the kernel holds these locks, it does not want to be preemptible by other processes.
4) when the kernel runs the process scheduler, it cannot be preemptible. This is obvious that running the process scheduler is actually a process of preemption, at this time, there is no context environment for any process.
Therefore, the main tasks to be completed by using SMP technology to seize the kernel include modifying the interrupt return code, modifying the SMP spin lock mechanism, and modifying the scheduler.
According to the data, although the improvement of the scheduling latency of the preemptible kernel by using SMP technology is not as good as the kernel preemptible method, because it is easy to maintain and portable, now the standard linux2.6 version has been added.
4. fine-grained timer implementation
In Linux, the timer precision is rough, generally 100Hz, that is, the interruption period of the timer is 10 ms. However, in real-time systems, there are higher requirements on the timer precision. For example, the running cycle of a real-time task in the real-time system must be less than 2 ms. In this case, normal Linux cannot meet the requirements, because when the timer frequency is Hz, the timer is interrupted every 10 ms before a process is scheduled. The running cycle of all cyclic tasks is at least 10 ms.
One way to implement a fine-grained timer is to increase the timer frequency. This method is the most direct and easy to implement, but because the timer frequency is increased, the timer interrupt service program runs more frequently, and the time spent by the system on task processing is reduced, thus reducing the system performance. Therefore, this method has some limitations. We must find a compromise between reducing system performance and improving clock accuracy.
Another way to implement a fine-grained timer is to run the timer in one-shot mode ). This is different from the timer running in the periodic mode. If you initialize the timer in the cyclic mode, the timer will interrupt periodically, you no longer need to program the timer. When the timer runs in single-trigger mode, it does not run any more when the timer is interrupted, the system then calculates the interval at which the timer should be interrupted next time according to the time requirements of the current task, and then program the timer, enable it to interrupt at a certain time point in the future as required by the system. In single-trigger mode, the timer precision can reach microseconds. However, it should be noted that the next interruption time must be calculated after each interruption, and the timer MUST be programmed. These two operations will reduce the system performance.
The specific timer scheme used in the real-time system usually depends on the specific application. There is no timer scheme applicable to all real-time applications.
5. Optimize Process Scheduling
The preceding analysis of the Linux task response model shows that the task response time is also related to the process scheduling time. When the process scheduling time is reduced, it can also effectively speed up the response of tasks. Currently, optimization of process scheduling mainly uses policies that separate real-time processes from common processes. This can be achieved through hierarchical scheduling, this can shorten the scheduling time of real-time processes and improve the response speed of real-time tasks.
6. Real-time dual-Kernel Mechanism
Although the Real-Time Optimization mechanisms of the preceding linux kernels can significantly improve the task response speed and enhance the real-time performance of Linux, they cannot meet the requirements of hard real-time. Because of the implementation and complexity of the Linux kernel, Linux itself cannot be applied to hard real-time applications. However, as Linux becomes more and more widely used, the requirements for Linux to meet hard real-time applications become more and more intense; in this environment, the real-time dual-kernel mechanism has created a precedent for Linux to support hard real-time applications. In this technology, there is a hardware real-time micro-kernel that runs on the hardware platform together with the Linux kernel. The real-time kernel has a higher priority than the Linux kernel, and is responsible for processing system real-time tasks, linux is responsible for processing non-real-time tasks. the Linux kernel can run only when there are no real-time tasks in the real-time kernel.
The real-time dual-Kernel Mechanism regards a system as composed of two parts: the real-time part and the non-real-time part. The real-time part is processed by the real-time micro-kernel, and the non-real-time part is processed by Linux, they can communicate with each other through pipelines or shared memory. Although this mechanism has a set of programming interfaces different from Linux itself when creating real-time tasks, it can communicate with Linux, so as to deliver a large amount of subsequent processing work to Linux. In this way, the hardware and real-time requirements of real-time tasks are ensured, and the application programming environment of Linux itself is retained, which can fully utilize the rich applications in Linux. |
