Linux real-time technology and typical Implementation Analysis

This series of articles is divided into two parts. Part 1 describes the concept of real-time and the metrics for measuring real-time performance. It analyzes in detail the requirements of embedded systems for Linux real-time performance and the shortcomings of Linux in real-time performance, next, we briefly describe three well-known real-time implementations of Linux. Part 1 provides a detailed analysis of a typical real-time implementation (INGO's RT patch.

I. Concept of real-time

Real-time means that the execution time of a specific task must be determined and predictable, and the task's time limit (maximum execution time limit) can be guaranteed under any circumstances ). Real-time, soft real-time, and hard real-time. The so-called soft real-time means that the requirements on the task execution time limit are not so strict, even if in some cases the time limit requirement cannot be met, it will not have a fatal impact on the system itself. For example, the media playing system is soft real-time, and the system needs to be able to play 24 frames in one second, however, it is acceptable that 24 frames cannot be processed within one second under some severe loads. The so-called hard real-time is very strict requirements on the execution time limit of the task. Under any circumstances, the implementation of the task must be absolutely guaranteed; otherwise, disastrous consequences will occur, for example, the automatic driving and navigation system of an aircraft is hard and real-time. It must require the system to complete specific tasks within a limited time limit, otherwise it will lead to major accidents, such as collision or explosion.

2. Real-time metrics

So how can we determine whether a system is real-time? There are two main indicators:

1. Interruption Delay

The interruption delay is the time required to start executing the first instruction of the corresponding interrupt processing function from an external event. Many real-time tasks are driven by interruptions, and interrupt events must be handled within a limited time limit. Otherwise, catastrophic consequences will occur. Therefore, the interruption delay is for real-time systems, is a very important indicator.

2. preemption Delay

It is also called scheduling delay. the preemption delay is the time from the time when an external event occurs to the First Command of the task for processing the event. Most Real-Time Systems process periodic or non-periodic repetitive events. The frequency of events determines the task execution time limit. Therefore, when an event occurs, the corresponding processing task must be promptly responded to; otherwise, the time limit cannot be met. The preemptible latency reflects the system's timeliness.

If the above two indicators are deterministic and predictable, then the system can be said to be real-time.

Iii. Factors affecting system real-time performance

Factors that affect system real-time performance include both hardware and software.

Modern High-performance hardware uses the cache technology to bridge the performance gap between CPU and memory, but the cache seriously affects real-time performance, there is a huge gap between the execution time of commands or data in the cache and the execution time of commands or data not in the cache, which may be several orders of magnitude different. Therefore, to ensure the certainty and predictability of the execution time, to meet the real-time needs, some systems will no longer use the cache or use the CPU without the cache.

Another hardware factor is virtual memory management. It is really useful for multi-user and multi-task operating systems. It enables the system to execute tasks larger than the physical memory, and tasks do not affect each other, it has its own independent address space. However, the page-missing mechanism of the inventory management seriously affects the predictability and certainty of the task execution time, when a task is executed, the page-missing mechanism is used to call access commands or data, and the execution time required by executed commands and data in the memory is very large. Therefore, some real-time systems do not use the virtual storage technology, such as Wind River's VxWorks.

In terms of software, the influencing factors include Guanzhong disconnection, non-preemption, and some O (n) algorithms.

As mentioned above, interruption delay is an important indicator to measure the real-time performance of the system. The disconnection causes the interruption to be unable to respond and increases the interruption delay.

The preemptible delay mentioned above is also an important indicator to measure the real-time performance of the system. If the system cannot be preemptible when a real-time event occurs, the preemption delay increases.

In addition, some algorithms with time complexity O (n) also affect the uncertainty of the execution time. For example, to execute a real-time task, scheduling is required, if the execution time of the scheduling algorithm depends on the number of tasks running in the current system, the time spent for scheduling real-time tasks is uncertain, because it is a function with a linear relationship with the number of tasks run by the system, the more tasks run, the longer the time.

4. embedded systems require real-time Linux

At the beginning of the design, Linux did not have any considerations for real-time performance. Therefore, non-real-time performance is not accidental. Linus considers resource sharing and maximizes throughput. However, with the rapid development of Linux, its application is far beyond Linus's imagination. The openness of Linux has already supported many types of architectures, making it widely used in embedded systems, however, the real-time requirements of many embedded systems make Linux applications in the embedded field suffer certain obstacles. Therefore, the demand for real-time requirements for Linux is getting higher and higher.

The openness and low cost of Linux are the advantages of Real-Time Linux development. More and more research institutions and business groups are conducting research and development on real-time Linux. The most famous ones are RTLinux and timesys Linux of fsmlab. Another is the INGO's RT patch.

5. Restrictions on real-time performance of the standard Linux Kernel

Standard Linux has several mechanisms that seriously affect real-time performance.

1. the kernel cannot be preemptible.

In Linux 2.4 and earlier versions, the kernel cannot be preemptible. That is to say, if the current task runs in the kernel state, even if more urgent tasks need to be run, the current task cannot be preemptible. Therefore, the emergency task must wait until the current task completes the kernel state operation and return to the user State, or the current task can be considered to be executed only when the CPU is actively given out because it needs to wait for certain conditions to be met, this seriously affects the preemption delay.

In Linux 2.6, the kernel can be preemptible, so the real-time performance is enhanced. However, there are still a large number of unpreemptible regions in the kernel, such as the critical zone protected by the spin lock and some critical zones explicitly preempt_disable.

2. Disconnect

Linux uses the interrupt close command in some synchronization operations. The interrupt close command increases the Interrupt Delay and reduces the real-time performance of the system.

3. spin lock)

A spin lock is a synchronization mechanism for shared resources when the kernel and SMP can be preemptible. Generally, a task has a very short access to shared resources, if two tasks compete for a shared resource, tasks that do not obtain the resource spin to wait for the other task to use the shared resource. This lock mechanism is very efficient, but it will fail to be preemptible while holding the spin lock, which means the preemption delay will increase. In the 2.6 kernel, spin locks are widely used, and some even use spin locks for the entire calendar process of an array or linked list. Therefore, the preemption delay is uncertain.

4. Large kernel lock

For historical reasons, the kernel has been retained with several major kernel locks. The large kernel locks are essentially a kind of spin locks, but the difference between them and general spin locks is, it is used to synchronize the entire kernel, and generally the lock remains for a long time, that is, the preemption failure time is long, so its use will seriously affect the preemption delay.

5. interruption is always the highest priority

In Linux, interrupt (including Soft Interrupt) is the highest priority. No matter at any time, as long as an interrupt event occurs, the kernel will immediately execute the corresponding interrupt processing function and Soft Interrupt, the normal task can be executed only after all pending and soft interruptions are processed. Therefore, in a standard Linux system, real-time tasks cannot be guaranteed in real time. For example, if a real-time task is run on a standard Linux system (that is, the sched_fifo scheduling policy is used and the highest real-time priority is set ), however, the system has a very heavy network load and I/O load, so the system may be interrupted and unable to run any task, so that real-time tasks will never run, the preemption delay will be infinite. Therefore, if this mechanism is not changed, real-time Linux will never be implemented.

6. Scheduling Algorithms and scheduling points

In Linux 2.4 and earlier versions, the time complexity of the scheduler is O (n), and the performance is low in SMP, because all CPUs share a task linked list, only one scheduler can run at any time. Therefore, the preemption delay is largely due to the number of tasks in the current system, which has great uncertainty and unpredictability.

The O (1) scheduler introduced in the 2.6 kernel solves these problems well.

In addition, even if the kernel is preemptible, scheduling is not allowed anywhere. For example, in the interrupt context, an interrupt handler may wake up a high-priority process, however, this process cannot run immediately, because scheduling cannot occur in the interrupt context. After the interrupt processing is complete, the kernel must execute the suspended Soft Interrupt, wait until they are processed to schedule the wake-up process. In the standard Linux kernel, there are not many scheduling points (intentionally scheduled task execution points). The test results for Kernel 2.4 and kernel 2.6 show that, the lack of scheduling points is a factor affecting the real-time performance of Linux.

Vi. Existing Real-Time Linux technology

The existing well-known real-time Linux implementations include RTLinux, rtai, and timesys.

1. RTLinux

RTLinux is a real-time Linux developed by fsmlab, a famous research institution. It has both GPL and free versions and commercial versions. The sub-kernel method is used to implement the Linux kernel as a new idle task of sub-kernel. The sub-kernel is located between the Linux kernel and the hardware abstraction layer, the real-time task runs on the sub-kernel. the Linux kernel can run only when no real-time task is required.

Especially for interrupt management, it uses a software method to handle interrupt shutdown in Linux. When the Linux kernel is closed, it does not actually block hardware interruptions. On the contrary, it uses a variable to save the interrupt flag of the Linux kernel. The switch interrupt of the Linux kernel only affects the variable. The hardware interrupt is taken over by the sub-kernel. When the interrupt of the Linux kernel is disabled, the sub-kernel can still respond to any interruptions, but if the sub-kernel does not need to handle the interruptions, it will be handed over to the Linux kernel for processing. If the Linux kernel is disconnected, the sub-kernel records the interrupt and submits it for processing after the Linux kernel is interrupted.

In RTLinux, every real-time task is a kernel thread and runs in the kernel space. RTLinux provides a dedicated mechanism for inter-process communication between real-time tasks and common Linux tasks.

The implementation of this seed kernel provides excellent real-time performance. It is completely a hardware real-time Linux.

2. timesys Linux

Timesys has released the commercial and GPL versions of Real-Time Linux for a long time. It adopts a completely different implementation method than RTLinux. As mentioned above, the real-time restrictions of the standard Linux kernel are eliminated by timesys Linux to achieve real-time performance. It thread all interrupt (IRQ) and Soft Interrupt (softirq) and gives different priorities. real-time tasks can have a higher priority than interrupt threads, it uses mutex instead of spinlock to make the spin lock fully preemption. It also optimizes the scheduler so that it is O (1) (Note: Because the 2.4 kernel is used ). As the interruption has been threaded, it is unnecessary to close many interruptions, thus eliminating many interruption close areas. It also realizes CPU and Network Resource Reservation to improve real-time performance. The Ingo's RT patch mentioned later is based on these ideas to achieve real-time performance.

This implementation method maintains all the Linux Application Programming modes. Real-time applications and common applications adopt the same programming method and use the same API, only real-time tasks need to specify their own priorities and scheduling policies. However, this implementation method also has drawbacks, that is, it has certain difficulties in meeting the hard real-time performance, because even if the interruption is closed and the number of inaccessible zones is greatly reduced, it still exists, some interruptions are still not thread-based, such as clock interruptions.

3. Ingo's RT patch

Ingo's RT patch is another real-time implementation of Linux. It adopts the same technical path as timesys, and some implementations are based on the source code of timesys, such as IRQ and softirq. However, unlike the two real-time implementations mentioned above, it may be incorporated into the standard Linux kernel (as predicted by the author, it may be incorporated into 2.6.13 or a later version ). In the latest standard kernel Linux 2.6.11, some of the Code contained in this patch, such as the IRQ subsystem, has already appeared, which is the basis for thread-based IRQ and softirq, some thread-based code has been hidden, such as voluntary code preemption. It is a 2.4 low-latency patch) and some of Ingo's collections of voluntary code preemption and Robert Love's lock decomposition patches, as well as large kernel locks that can be preemptible.