Shulou(Shulou.com)06/01 Report--

This article is to share with you about whether the Linux real-time patch is about to be merged into Linux 5.3.The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

The Linux PREEMPT_RT patch is finally going to be incorporated into Linux 5.3. It means that real-time patches that have been developed for more than a decade will be able to develop in collaboration with the mainline Linux.

I. the concept of real-time

The so-called real-time means that the execution time of a specific task must be determined, predictable, and can guarantee the time limit of the task in any case (maximum execution time limit). Real-time is divided into soft real-time and hard real-time. The so-called soft real-time means that the time limit for task execution is not so strict, even if it does not meet the time limit in some cases, it will not have a fatal impact on the system itself. For example, the media playback system is soft real-time, which requires the system to be able to play 24 frames in 1 second, but it cannot process 24 frames in 1 second even under some heavy loads. It's acceptable. The so-called hard real-time means that the time limit for the execution of the task is very strict, no matter what the circumstances, the implementation of the task must be absolutely guaranteed, otherwise it will have disastrous consequences, for example, aircraft autopilot and navigation system is hard 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 collisions or explosions.

2. Indicators to measure real-time performance

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

1. Interrupt delay

Interrupt delay is the time it takes to start execution from an external event to the first instruction of the corresponding interrupt handler. Many real-time tasks are driven by interrupts, and interrupt events must be processed within a limited time limit, otherwise it will have disastrous consequences, so interrupt delay is a very important indicator for real-time systems.

two。 Preemption delay

Sometimes called scheduling delay, preemption delay is the time from the occurrence of an external event to the execution of the first command of the corresponding task handling the event. Most real-time systems deal with periodic or aperiodic repetitive events, and the frequency of the events determines the execution time limit of the task, so each time the event occurs, the corresponding processing task must respond in time, otherwise the time limit will not be met. The preemption delay reflects the timely response of the system.

If the above two indicators are definite and predictable, then it can be said that the system is real-time.

3. Factors affecting the real-time performance of the system

The factors that affect the real-time performance of the system are both hardware and software.

Modern high-performance hardware uses cache technology to make up the performance gap between CPU and memory, but cache seriously affects real-time performance. The difference between the execution time of instructions or data in cache and the execution time of instructions or data not in cache is very large, which may be several orders of magnitude, so in order to ensure the certainty and predictability of execution time, to meet the real-time needs. Some systems fail cache or use CPU without cache.

Another hardware factor is virtual memory management, which is really useful for multi-user and multi-task operating systems. It enables the system to perform tasks that are larger than physical memory, and each task does not affect each other. It has its own independent address space. However, the missing page mechanism of virtual memory management seriously affects the predictability and certainty of task execution time. when a task is executed, the gap between the execution time of the accessed instruction or data and the executed instruction and data that is already in memory is very large. Therefore, some real-time systems do not use virtual memory technology, such as Wind River's VxWorks.

In terms of software, the influencing factors include off interrupt, non-preemptive, and some O (n) algorithms.

As mentioned earlier, interrupt delay is an important index to measure the real-time performance of the system. The off interrupt causes the interrupt to be unresponsive and increases the interrupt delay.

The preemption delay mentioned above is also an important index to measure the real-time performance of the system. If the system is not preemptable when a real-time event occurs, the preemption delay increases.

Fourth, embedded systems need real-time Linux

Linux did not consider real-time at the beginning of its design, so it is no accident that it is not real-time. Linus considers resource sharing and maximum throughput. But with the rapid development of Linux, its application has been far beyond the imagination of Linus itself. The openness of Linux has made it widely used in embedded systems because of its support for many architectures, but the real-time requirements of many embedded systems have hindered the application of Linux in the embedded field, so the demand for real-time performance of Linux is getting louder and louder.

The openness and low cost of Linux are the advantages of the development of real-time Linux. More and more research institutions and business groups have carried out the research and development of real-time Linux, the most famous of which are FSMLab's Rtlinux and TimeSys Linux. The other one is Ingo's RT patch.

Fifth, the factors restricting the real-time performance of the standard Linux kernel.

There are several mechanisms in standard Linux that seriously affect real-time performance.

1. The kernel cannot be preempted.

In Linux 2.4 and earlier, the kernel is not preemptable, that is, if the current task is running in kernel mode, even if there are more urgent tasks to run, the current task cannot be preempted. Therefore, the urgent task must wait until the current task returns to the user state after the kernel operation is completed, or the current task actively gives up the CPU because it needs to wait for certain conditions to be met before it can be considered to be executed, which obviously seriously affects the preemption delay.

In Linux 2.6, the kernel can already be preempted, so the real-time performance is enhanced. However, there are still a large number of non-preemptable areas in the kernel, such as critical areas protected by spin locks (spinlock), and some critical regions that are explicitly preempted by preempt_disable failures.

two。 Interrupt shutdown

Linux uses interrupt shutdown instructions in some synchronous operations, which will increase the interrupt delay and reduce the real-time performance of the system.

3. Spin lock (spinlock)

Spin lock is a synchronization mechanism for shared resources in the case of preemptive kernel and SMP. Generally speaking, the access of a task to a shared resource is very short. If two tasks compete for a shared resource, the task that does not get the resource will spin to wait for another task to finish using the shared resource. This locking mechanism is very efficient, but preemption will fail during spin locking, which means that preemption delay will increase. In the kernel, the use of spin locks is so common that some even use spin locks for the entire traversal of an array or linked list. So the preemption delay is very uncertain.

4. Interrupts are always the highest priority.

In Linux, interrupts (including soft interrupts) are the highest priority. Whenever an interrupt event occurs at any time, the kernel will immediately execute the corresponding interrupt handling functions and soft interrupts, and wait until all pending interrupts and soft interrupts have been processed before performing normal tasks. Therefore, in the standard Linux system, real-time tasks can not be guaranteed at all. For example, suppose that a real-time task is running on a standard Linux system (that is, using the SCHED_FIFO scheduling policy), but the system has a very heavy network load and Ihand O load, then the system may always be in a state of interrupt processing without a chance to run any tasks, so that real-time tasks will never be able to run, and the preemption delay will be infinite. Therefore, if this mechanism is not changed, real-time Linux will never be implemented.

5. Scheduling algorithm and scheduling point

Even if the kernel is preemptable, scheduling can not occur anywhere. For example, in an interrupt context, an interrupt handler may wake up a high-priority process, but the process cannot be run immediately, because scheduling cannot occur in the interrupt context, and the kernel has to execute a pending soft interrupt after the interrupt has been processed, if the previous interrupt occurred in the spin_lock critical area. There is also the code waiting for the critical section to be executed, and only after they have all been processed will they have a chance to schedule the process that has just been awakened.

Real-time patches for Ingo Molnar I. introduction

Ingo Molnar's real-time patch is completely open source, its real-time implementation technology is completely similar to Timesys Linux, and the interrupt threaded code is based on TimeSys Linux's interrupt threaded code. These real-time implementation technologies include: interrupt threading (including IRQ and softirq), replacing spinlock with Mutex, priority inheritance and deadlock detection, waiting queue prioritization and so on.

This real-time implementation includes the previous VP patch (known as the kernel mailing list, or Voluntary Preemption), which evolved from a low-latency patch (low latency patch) for the 2.4 kernel, which uses two ways to achieve low latency:

One is lock decomposition, which decomposes the locks held in a large loop into acquiring and releasing locks in each loop. A typical example of the code structure is as follows: before the lock is decomposed:

Spin_lock (& x_lock); for (…) {some operations;... } spin_unlock (& x_lock)

After the lock is decomposed:

For (…) {spin_lock (& x_lock); some operations;... Spin_unlock (& x_lock);}

The other is to increase the preemption point, that is, to be voluntarily preempted. Here is a mouse-driven example:

A piece of code in the file driver/char/tty_io.c before the preemption point is added:

/ * Do the write.. * / for (;) {size_t size = count; if (size > chunk) size = chunk; ret =-EFAULT; if (copy_from_user (tty- > write_buf, buf, size)) break; lock_kernel (); ret = write (tty, file, tty- > write_buf, size); unlock_kernel () If (ret chunk) size = chunk; ret =-EFAULT; if (copy_from_user (tty- > write_buf, buf, size) break; lock_kernel (); ret = write (tty, file, tty- > write_buf, size); unlock_kernel (); if (ret)

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.