Rtlinux with Address Spaces 1 Introduction 2 L4RTL

Rtlinux with Address Spaces 1 Introduction 2 L4RTL

RTLinux with Address Spaces Frank Mehnert Michael Hohmuth Sebastian Sch¨onberg Hermann H¨artig Dresden University of Technology Department of Computer Science, D-01062 Dresden, Germany [email protected] Abstract The combination of a real-time executive and an off-the-shelf time-sharing operating system has the potential of providing both predictability and the comfort of a large application base. To isolate the real-time section from a significant class of faults in the (ever-growing) time-sharing operating system, address spaces can be used to encapsulate the time-sharing subsystem. However, in practice designers seldomly use address spaces for this purpose, fearing that extra cost induced thereby limits the system’s predictability. To analyze this cost, we compared in detail two systems with almost identical interfaces—both are a combination of the Linux operating system and a small real-time executive. Our analysis revealed that for interrupt-response times, the delay and jitter caused by address spaces are similar to or even smaller than those caused by caches and blocked interrupts. As a side effect of our analysis, we observed that published figures on predictability must be carefully checked whether or not such hardware features are included in the analysis. 1 Introduction from the time-sharing subsystem (both kernel and applications) than the other way round: For exam- In this paper, we determine the cost of introducing ple, a real-time application may be safety-critical, address-space protection to RTLinux [8]. but time-sharing operating systems have become so RTLinux is a real-time extension for Linux. It in- big and bloated that it is difficult to trust in their troduces a small real-time executive layer into the stability. However, the undoubtable benefits of sep- time-sharing Linux kernel. On top of that layer, the arate address spaces do not come for free. time-sharing kernel and the real-time applications all We observed RTLinux’ worst-case response time to run in kernel mode. User mode is reserved for time- be much higher than “about 15 µs on a generic x86 sharing applications. Real-time applications are pro- PC” claimed by the system’s authors [7]. In our tected from errors in time-sharing applications. experiments, RTLinux’ worst-case interrupt latency 1 For our evaluation, we used L4RTL, a reimplemen- was 68 µs. The worst case for L4RTL was 85 µs. tation of the RTLinux API based on a real-time mi- We found that the cost induced by address-space crokernel and a user-level Linux server. That design switches to real-time applications does not signifi- has the property that the real-time subsystem is pro- cantly distort the predictability of the system. In tected from a large class of errors: Crashes in the general, most of the worst-case overhead we observed time-sharing subsystem (either in the operating sys- must be attributed to implementation artifacts of the tem or in user code) will not bring down the real-time microkernel we used, not to the use of address spaces. subsystem, except if a device driven by the time- sharing subsystem locks up the machine or corrupts main memory. 2L4RTL This increased level of fault tolerance is desirable for many real-time applications. In many ways, it is For an accurate comparison of the cost of address more important to protect the real-time subsystem spaces in real-time systems, we have reimplemented 1We carried out our measurements on a 800-MHz Pentium-III PC—more details in Section 3. We believe that this system qualifies as a “generic x86 PC” as presumed by the RTLinux statement. the RTLinux API in the context of the Drops sys- separate from L4Linux’s address space. We call tem. The resulting system, called L4RTL, can run these threads and address spaces L4RTL threads and unmodified RTLinux programs (source-level compat- L4RTL tasks, respectively. Each L4RTL taskcan ibility). contain several L4RTL threads, and these threads can cooperate using the RTLinux API. 2.1 The DROPS system There can be more than one L4RTL task. All of these tasks can use the same single L4Linux server. Drops is an operating system that supports appli- However, L4RTL currently does not allow real-time cations with real-time and quality-of-service require- threads in different tasks to communicate with each ments as well as non-real-time (time-sharing) appli- other using the RTLinux API. cations [2]. It uses the Fiasco microkernel as its base. The L4RTL dynamic load module2 for L4Linux im- The Fiasco microkernel is a fully preemptible real- plements the API for use by Linux programs to com- time kernel supporting hard priorities. It uses non- municate with L4RTL threads. It also creates a ser- blocking synchronization for its kernel objects. This vice thread in the L4Linux task. L4RTL threads use ensures that runnable high-priority threads never this thread as their only connection to L4Linux, and blockwaiting for lower-priority threads or the ker- only for communication with time-sharing Linux pro- nel [5]. cesses. Otherwise, L4RTL tasks can work completely For time-sharing applications, Drops comes with independent from L4Linux. 4 L Linux, a Linux server that runs as an applica- FIFOs and Mbuffs are implemented using shared- tion program on top of the Fiasco microkernel [3]. memory regions between L4RTL threads and the 4 L Linux supports standard, unmodified Linux pro- L4RTL load module. L4RTL threads allocate these grams (binary compatibility). The Linux server memory regions and then transfer a mapping of these never disables interrupts for synchronization pur- to the load module’s service thread inside L4Linux poses. Instead, we modified the implementations of using microkernel IPC. The shared-memory regions cli() and sti() to workwithout disabling inter- contain all necessary control data. Once a L4RTL rupts while still ensuring their semantics (to protect thread and the load module have established the a critical section) [4]. mapping, they only communicate using their shared- memory region. L4RTL has been designed so that 2.2 L4RTL implementation bugs in L4Linux that corrupt the shared-memory data cannot crash L4RTL threads. We implemented L4RTL as a library for RTLinux More Fiasco-microkernel IPC is necessary only for application programs and a dynamic load module 4 FIFO signalling. For this purpose, the L4RTL li- for L Linux. Figure 1 gives an overview of L4RTL’s brary creates one thread in each L4RTL task(Fig- structure. ure 1). This thread handles signal messages from the L4RTL task L4RTL load module and forwards them to L4RTL threads. Linux Linux In contrast to RTLinux, L4RTL does not contain a app app scheduler. Instead, it relies on the Fiasco microker- L4RTL library nel for scheduling. L4RTL is the subject of ongoing workand research. L4RTL task Currently, it does not implement all of the very rich RTLinux API. However, everything relevant to the L4RTL dynamic load module discussion in this paper (and more) has been imple- mented and works well, and we believe that the miss- L4 Linux server L4RTL library ing features have no influence on our measurements. User Kernel Fiasco microkernel 3 Cost of address spaces Using original RTLinux and L4RTL, we ran a min- FIGURE 1: L4RTL structure imal interrupt-latency benchmarkunder worst-case The L4RTL library implements the RTLinux API conditions. This experiment was meant to establish for real-time RTLinux applications. RTLinux appli- an upper bound for the overhead that can be expected cations run as user-mode threads in address spaces from providing address spaces. 2From L4Linux’s point of view, this is a “Linux kernel module,” but of course L4Linux runs as a user program and not in kernel mode. 3.1 Experimental setup try”). This measurement was intended to quantify the effect of critical code sections that disable inter- To induce worst-case system behavior, we have used rupts within the kernels4. By measuring both kernel- two strategies. level and real-time–thread latencies, we were able to First, prior to triggering the hardware event, we con- filter out overhead not induced by introducing ad- figure the system such that the kernel’s and the real- dress spaces but by artifacts of the kernels’ imple- time thread’s cache and TLB working sets they need mentations. to react to the event are completely swapped out to The diagrams in Figures 2 and 3 show the densities main memory (and the corresponding 1st-level and of the interrupt response times under the two load 2nd-level cache lines are dirty). For this purpose we conditions. Table 1 gives an summarization of the have written a Linux program that invalidates the worst-case measurement results. caches and TLB entries (cache flooder) Second, we exercise various code paths in RTLinux, kernel entry kernel path user entry L4Linux, and the Fiasco microkernel. These cover- L4RTL 53 µs 39 µs 85 µs age tests are a probabilistic way to reveal code paths RTLinux 53 µs 56 µs 68 µs with maximal execution time while interrupts are disabled. Additionally, they increase confidence that TABLE 1: Worst-case interrupt execution Drops the system is indeed completely preemptible times on L4RTL and RTLinux as we claimed in Section 2.1. To avoid missing criti- cal code paths because of pathologic timer synchro- The maximal time to invoke the Fiasco microker- nization, we varied the time between triggering two nel’s handler was 53 µs, and the maximal time to interrupts. start the corresponding L4RTL thread was 39 µs. For code coverage we use a benchmarking suite for As the sum of these separate maximums is close to Unix, hbench [1].

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    5 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us