Linux kernel notes (4) Linux real-time architecture analysis __linux

The speed or efficiency of linux® is very good, but in some cases, such speed is not enough to meet the demand. What we need is the ability to meet scheduling deadlines within a specific tolerance range. This article will reveal various options for implementing real-time Linux and how they can be implemented in real time-from the architecture of the early imitation Virtualization solution to the choices available in today's standard 2.6 kernel.

This article explores some Linux architectures that support real-time features and explores what the implications of real-time architectures are. There are a number of solutions that give Linux real-time capabilities, and this article examines the thin kernel (or microkernel) approach, the Super microkernel approach, and the resource kernel (resource-kernel) approach. Finally, it describes the real-time capabilities of the standard 2.6 kernel and shows you how to enable and use this functionality.

Real-time definitions and requirements

The following real-time definitions provide the basis for exploring the real-time Linux architecture. The definition is presented by Donal Gillies in the realtime Computing FAQ. Real-time system calculation correctness depends not only on the logic correctness of the calculation, but also on the time of the result. If the system's time constraints are not met, the system is considered invalid.

Context switching A context switch is implied in the process of assigning a new task after an interruption occurs. This process stores the current state of the CPU at break time, and then restores the status of a given task. Context switching relies on the operating system and the underlying processor architecture.

In other words, the system must be deterministic to meet the time requirements when it faces varying loads (from least to worst). Note that the definition does not refer to performance because real-time is not related to speed: it is associated with predictability. For example, when using a fast modern processor, Linux can provide a typical interrupt response for 20μ microseconds, but sometimes the response can become very long. This is a fundamental problem: Linux is not fast enough or inefficient, but because it does not provide certainty.

Some examples will illustrate the implications of all this content. Figure 1 shows the interrupt latency metric. When the interrupt arrives (event), the CPU interrupts and goes to interrupt processing. Perform some work to determine what event has occurred, and then perform a small number of assignments that are required to handle this event (context switches). The time between the interrupt arrival and the distribution of the required tasks (assuming the highest priority task is assigned) is called response time. For real-time requirements, the response time should be determined and should be completed within the known worst-case period.

Figure 1. Interrupt latency and Response time

An example of this process is the airbag currently used in automobiles. When a sensor that reports vehicle collisions interrupts the CPU, the operating system should quickly allocate the task of expanding the airbag and not allow other non-real-time processing to interfere. It is worse to expand the airbag one second later than without the airbag.

In addition to providing certainty for interrupt processing, real-time processing also requires scheduling tasks that support periodic intervals. Consider Figure 2. This illustration shows a recurring task schedule. A large number of control systems require periodic sampling and processing. A specific task must be performed in a fixed cycle (p) to ensure system stability. Consider the car's anti-lock system (ABS). The control system samples the speed of each wheel of the vehicle (up to 20 times per second) and controls the pressure on each brake (preventing it from locking). In order to maintain the normal operation of the control system, the sampling and control of the sensor must be in a certain cycle interval. This means that other processing must be preempted so that the ABS task can be performed in the desired cycle.

Figure 2. Periodic task Scheduling

Hard -time and soft real-time system

An operating system capable of completing a real-time task at a specified time period, even under the worst processing load, is called a hard time system. However, hard real-time support is not required in any case. If the operating system can support the execution time of a task on average, it is called a soft real-time system. A hard real-time system is a system that will cause catastrophic consequences (such as the expansion of the long glide distance of the airbag or braking pressure) after the deadline. A soft real-time system that exceeds the deadline does not cause overall system failure (such as missing a frame in the video).

Now that you have some insight into real-time requirements, let's look at which level of real-time Linux architecture supports and how to do that.

Thin Kernel approach

The thin kernel (or microkernel) approach uses a second kernel as an abstract interface between the hardware and the Linux kernel (see Figure 3). The non-real-time Linux kernel runs in the background, hosting all non-real-time tasks as a low priority task for the thin kernel. Real-time tasks run directly on the thin kernel.

Figure 3. Hard real-time thin-core approach

The thin kernel is primarily used to break management (in addition to managed live tasks). The thin kernel intercepts interrupts to ensure that the non-real-time kernel cannot preempt the operation of the thin kernel. This allows the thin kernel to provide hard real-time support.

Although the thin kernel approach has its advantages (hard real-time support coexists with the standard Linux kernel), there are drawbacks to this approach. Real-time and non-real-time tasks are independent, which makes debugging difficult. Also, non-real-time tasks are not fully supported by the Linux platform (one reason thin kernel execution is known as thinness).

Examples of this approach are RTLinux (now proprietary by Wind River Systems), real-time Application interface (RTAI) and Xenomai.

Super Micro Kernel method

Here the thin-core approach relies on the smallest kernel that contains task management, and the hyper-kernel method reduces the kernel further. In this way, it is not like a kernel but more like a hardware abstraction layer (HAL). The micro-kernel provides hardware resource sharing for multiple operating systems running at a higher level (see Figure 4). Because the micro-kernel abstracts the hardware, it provides priority for higher-level operating systems to support real-time performance.

Figure 4. Ultra-microkernel method for hardware abstraction

Note that there are some similarities between this approach and the virtualization approach to running multiple operating systems. Using this approach, the Microkernel abstracts hardware in both real-time and non-real-time cores. This is similar to the way hypervisor abstracts the bare metal from the customer (guest) operating system.

An example of a super microkernel is the adaptive Domain environment for operating Systems (ADEOS) of the operating system. ADEOS enables multiple concurrent operating systems to run synchronously. When a hardware event occurs, ADEOS queries each operating system in the chain to determine which system is used to handle the event.

Resource Kernel Method

Another real-time architecture is the resource-kernel approach. This method adds a module to the kernel and provides reservations (reservation) for various resources. This mechanism guarantees access to time-division multiplexing (time-multiplexed) system resources (CPU, network, or disk bandwidth). These resources have multiple reservation parameters, such as the cycle cycle, the required processing time (that is, the time required to complete the processing), and the cutoff time.

The resource kernel provides a set of application programming interfaces (APIs) that allow tasks to request these reserved resources (see Figure 5). The resource kernel can then merge these requests and define a schedule using the constraints defined by the task, providing deterministic access (an error is returned if certainty is not provided). Through scheduling algorithms, such as Earliest-deadline-first (EDF), the kernel can handle dynamic scheduling loads.

Figure 5. Resource-kernel method to implement resource reservation

An example of the implementation of the resource kernel method is the CMU company's Linux/rk, which integrates the portable resource kernel into Linux as a loadable module. This realization evolves into a commercial timesys linux/rt product.

real-time in the standard 2.6 kernel

The methods currently being explored are architecturally interesting, but they all run on the periphery of the kernel. However, what happens if you make the necessary modifications to the standard Linux kernel to support real-time performance?

Today, in the 2.6 kernel, you can get soft real-time functionality by simply configuring the kernel to fully preempt it (see Figure 6). In the standard 2.6 Linux kernel, when a user-space process executes a kernel call (via a system call), it cannot be preempted. This means that if the low-priority process makes a system call, the high-priority process must wait until the call is finished before the CPU can be accessed. The new configuration option config_preempt changes this kernel behavior, allowing the process to be preempted when high-priority tasks are available (even if the process is making system calls).

But this configuration option is also a tradeoff. While this option enables soft, real-time performance and allows the operating system to run smoothly even under load conditions, this can be a price to pay. The cost is a slight reduction in throughput and kernel performance, because the CONFIG_PREEMPT option adds overhead. This option is useful for desktops and embedded systems, but is not useful in any scenario (for example, a server).

New O (1) Scheduler The new O (1) scheduler in the 2.6 kernel has a significant performance boost, even in the case of many tasks. No matter how many tasks you need to run, the new scheduler will run for a limited amount of time.

Another useful configuration option in the 2.6 kernel is the high-precision timer. This new option allows the timer to run with 1μs precision (if supported by the underlying hardware) and to efficiently manage the timer through the red-black tree. With a red-black tree, you can use a large number of timers without affecting the performance of the timer subsystem (O (log n)).

With just a little extra work, you can implement hard real-time with preempt_rt patches. PREEMPT_RT patches provide a number of modifications to achieve hard real-time support. Some of these modifications include the RE implementation of some kernel-locked primitives, which enable full preemption, the prioritization of kernel mutexes, and the transformation of interrupt handlers into kernel threads to enable the thread to preempt.

Concluding remarks

Linux is not only an ideal platform to experiment and describe real-time algorithms, but also implements real-time functions in the standard 2.6 kernel. You can implement soft real-time functionality from the standard kernel and perform some extra work (kernel patches) to build a hard real-time application.

This article briefly introduces some techniques for providing real-time computing to the Linux kernel. Many early attempts to isolate real-time tasks from the standard kernel using the thin-core approach. Later, there was the Super microkernel approach, which is very similar to the hypervisor used in today's virtualization solutions. Finally, the Linux kernel provides its own real-time methods, including soft real-time and hard real-time.

Http://www.embeddedlinux.org.cn/html/yingjianqudong/201010/08-911.html