Timing analysis of the PREEMPT RT Linux kernel

Abstract

In the theory of real-time scheduling, tasks are described by mathematical variables, which are used in analytical models in order to prove schedulability of the system. On real-time Linux, tasks are computer programs, and Linux developers try to lower the latencies caused by the Linux kernel, trying to achieve faster response for the highest-priority task. Although both seek temporal correctness, they use different abstractions, which end up separating these efforts in two different worlds, making it hard for the Linux practitioners to understand and apply the formally proved models to the Linux kernel and for theoretical researchers to apply the restrictions imposed by Linux for the theoretical models. This paper traces a parallel between the theory of response-time analysis and the abstractions used in the Linux kernel. The contribution of this paper is threefold. We first identify the PREEMPT RT Linux kernel mechanisms that impact the timing of real-time tasks and map these impacts to the main abstractions used by the real-time scheduling theory. Then, we describe a customized trace tool, based on the existing trace infrastructure of the Linux kernel, that allows the measurement of the delays associated with the main abstractions of the real-time scheduling theory. Finally, we use this customized trace tool to characterize the timing lines resulting from the behavior of the PREEMPT RT Linux kernel.In addition to the function trace, there are other trace plugins, with emphasis on the function graph. The function graph traces the call and return of a function. To improve the understanding of the stack of functions, the output shows the indentation of the functions according to its position in the stack. This is an example of the execution of the function graph:An advantage of the function graph is the ability to determine the execution time of a particular function. It also makes the trace easy to follow, because of the indentation of functions. Ftrace allows the combined use of trace plugins and tracepoints.The tracer proposed in this article, denominated Trace Timeflow, was created based on the function graph tracer, in order to trace the relevant functions. It also uses tracepoints to trace important changes in the system state. Trace timeflowInitially, the new plugin was built as a copy of function graph. From this clone, changes were made to meet our needs. The first change was the fields to be displayed in the trace. Trace format.The format of the trace consists of six fields, as in the following example:The field TASK-PID identifies the task running, it displays the name of the process and its PID. The field PRIO displays the priority. Currently, Linux has 140 priorities, where priority 0 is the highest and 139 is the lowest. The real-time tasks use priorities from 0 to 99, with priorities from 100 to 139 used as time-sharing priorities.The field CPU displays the CPU where the task is running.TIMING ANALYSIS OF THE PREEMPT RT LINUX KERNEL 805 Inside the infinite loop created with for, the function pause(...

Open Embedded Real-time Controllers for Industrial Distributed Control Systems

“…Several real-time Linux approaches were introduced in the recent past which improves the response time and priority-based scheduling in order to meet hard real-time deadlines. These are largely classified into two major approaches: the preemptible kernel [8] and the dual-kernel approaches [7,9,10]. In the fully preemptible kernel approach, all parts of the standard Linux kernel with relationship to the scheduler and timers are directly modified to render lower priority tasks preemptible by higher priority ones.…”

“…A blocking happens when a low priority task owns a resource needed by a high priority task. Whereas, an interference occurs when lower priority tasks are preempted by tasks with higher priorities [8]. In the figure, for task τ i , timing characteristics are defined with their respective priorities, activation period (P), which is usually equal to the relative deadline where execution time is defined as computation time (C).…”

“…A blocking happens when a low priority task owns a resource needed by a high priority task. Whereas, an interference occurs when lower priority tasks are preempted by tasks with higher priorities [8]. In this equation, I i denotes the sum of the computation time of all the elements included in the set of tasks with higher priority than task τ i , hp(i).…”

“…This is only applicable to determine the busy period of the current task, τ i , and should be repeated when needed for the other tasks. After the busy period is calculated, the overall response time of the system is determined by the following equation [8]:…”

Time synchronization services for low-cost fog computing applications

“…We evaluated several run-time options-using the cyclictest [1,3] tool for task scheduling measurements and custom code for testing the timing accuracy of I/O actions. In almost all cases, the RT PREEMPT [10] Linux real-time extensions-an extensive patch set for making the Linux kernel fully preemptibleresulted in superior performance.…”