Realfeel Test of the Preemptible Kernel Patch
Linux was originally written as a general-purpose operating system without any consideration for real-time applications. Recently Linux has become attractive to the real-time community due to its low cost and open standards. In order to make it more practical for the real-time community, patches have been written to affect such things as interrupt latency and context switch. These patches are public domain and are becoming part of the main Linux tree.
This article talks about one of these patches, the preemptible kernel patch, and its effect on the interrupt latency of a Linux system. The patch reduces the measured interrupt latency of the system, making it more appropriate for real-time applications.
While applications run, some are going to reach a point where they wait for an interrupt to occur. That is, some piece of data must be received or something must occur before the application can proceed. The interrupt latency is a measure of the amount of time needed for the application to respond to the interrupt and then proceed. If an application responds to many interrupts, it will experience many latencies. In real-time systems, the engineer needs to design for the worst case, so the largest of these interrupts must be known.
Linux is both a multiprocess and a multithread operating system. The numbers presented in this article represent the results of two different processes running. So the interrupt latency numbers represent the time to both respond to the interrupt and to change processes. This change of process requires cache data of the operating process to be stored and cache data of the blocked process to be reloaded. Latency-sensitive and security-insensitive applications can be written in a single-process mulithread fashion. This would produce smaller latency numbers, because data does not need to be moved. Many operating systems offer only the single-process multithread option, automatically offering smaller latency times. Because we chose to run an open-source benchmark, which could only do things in a multiprocess fashion, these are the numbers presented. Future work will include a single-process multithread benchmark.
For this work, interrupt latency is measured with an open benchmark called Realfeel, written by Mark Hahn. Realfeel issues periodic interrupts and measures the time needed for the computer to respond to these interrupts. Response times vary from interrupt to interrupt. Realfeel measures these interrupts and produces a histogram by putting the measurements into bins. The measurement focused on is not the histogram itself but the largest interrupt latency measurement. The performance of an operating system may depend on the average interrupt latency for some applications, but real-time applications are more dependent on the largest interrupt latency. The largest interrupt latency is a prediction of the worst case scenario. For many of these applications, if the latency were over the limit one time, it would result in a complete failure of the system. So the purpose of the benchmark is to find the latency that would never be exceeded.
In a real-time application, the system is not dormant when the interrupt is issued. Some kind of background operation is occurring with the operating system, or another application is in process. The benchmark is run under various load conditions ranging from processor computation to system and network operations. This work looks at the maximum under three load conditions, which are run as script files on the system. The Find script searches the hard drive for a file by using the UNIX find command. The Launch script runs a script that continually launches a trivial executable program and prints a small amount of text to the screen. The File move script continually copies two large files on the disk over each other. To come up with truly worst case numbers, we made an effort to subject them to the worst load possible. The loads are run continuously and are probably worse than anything the system would see in actual use.
The application is run with two kernels. One is the Linux 2.4.19 kernel from the Galileo tree, and the other is the same kernel with the preemption patch. This patch is maintained by Robert Love and has been accepted into the 2.5 development kernel.
The benchmark was run on a Power PC system operating at 312.5MHz. The system controller chip was a Marvell Discovery operating at 125MHz. It was connected to the network and had no disk drive.
Results (see Table 1) are presented for both kernels, with all three load scripts running in the background. These results are presented in Table 1. The results are stored in the form of a histogram (see Figure 1). Because the purpose of this work is to examine the potential to use Linux in a real-time environment, only the largest interrupt latency numbers are reported.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- The Qt Company's Qt Start-Up
- Devuan Beta Release
- May 2016 Issue of Linux Journal
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The US Government and Open-Source Software
- Open-Source Project Secretly Funded by CIA
- The Death of RoboVM
- The Humble Hacker?
- BitTorrent Inc.'s Sync
- New Container Image Standard Promises More Portable Apps
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide