In this section, we provide a discussion of real-time operating systems (RTOSs), since we implement our cache-aware scheduler withinLITMUSRT, a Linux-based testbed that provides much of the functionality of a multiprocessor RTOS.
Most prior work on RTOSs has focused on uniprocessor systems—see [63] for a recent survey. In most such work, techniques for scheduling multiprocessor workloads are rarely discussed. The prevailing attitude seems to be that, on a multiprocessor platform, partitioning is the only viable choice, and therefore, scheduling reduces to a uniprocessor problem. Given this prior emphasis, we mostly limit our discussion of prior work to LITMUSRT and related research that pertains to Linux or that addresses multiprocessor systems more directly.
2.3.1 LITMUSRT
LITMUSRT [22], or the LInux Testbed for MUltiprocessor Scheduling in Real-Time sys- tems, is a Linux-based testbed that supports multiprocessor real-time scheduling and syn- chronization policies. The creation of LITMUSRT was crucial to demonstrate the potential viability of various scheduling methods being investigated by our group. Until the creation of LITMUSRT, such a testbed did not exist, and no implementations of global scheduling policies existed in real systems. The author of this dissertation led the original effort to create LITMUSRT and conduct the first empirical evaluation of global multiprocessor real- time scheduling policies [22], and was also involved in later studies that used LITMUSRT to explore synchronization [16] and scalability [15] issues. During our studies, our empirical evaluations provided a better understanding of the “common case” for a variety of scheduling and synchronization problems. By designing algorithms to perform well in the common case rather than under a myriad of theoretical corner cases, the resulting approaches tended to be simpler and easier to analyze. Thus, a recurring theme of this work was that simpler approaches often resulted in better performance in practice, since they resulted in lower over- heads or allowed for more accurate schedulability tests to be used. The most recent version of LITMUSRT, which is a patch against Linux kernel version 2.6.24, is publicly available [69].
2.3.2 RTLinux
Yodaiken and Barabanov [71] are responsible for an early effort at creating an RTOS, known as RTLinux, which has evolved over time into a commercial product. RTLinux runs real- time tasks in a thin real-time kernel, with Linux itself running on top of this kernel as a low-priority background task. This strategy prevents the Linux kernel from disrupting real- time tasks, but at the same time, restricts the ability of such tasks to invoke Linux kernel services, and may severely impact the performance of non-real-time tasks by forcing them to be scheduled at the lowest priority at all times. In contrast, LITMUSRT incorporates the scheduling algorithms that are required directly into Linux itself. RTLinux supports periodic threads, but scheduling is limited to FIFO, round-robin, and fixed-priority schemes. While various multiprocessor scheduling algorithms could potentially be incorporated within RTLinux, this would preclude supporting in a straightforward manner tasks that require the services of the Linux kernel.
2.3.3 Multiprocessor RTOSs
To our knowledge, multiprocessor-based RTOSs were first considered as part of work on the Spring kernel, created by Stankovic and Ramamritham [64]. The scope of Spring extended be- yond stand-alone multiprocessor systems and encompassed distributed systems comprised of several multiprocessing nodes and tasks with synchronization requirements; however, Spring predated almost all of the recent advances in multiprocessor scheduling. In particular, this includes advances in global multiprocessor scheduling algorithms, such as PD2, and results
related to soft real-time systems.
In other recent work concerning multiprocessors, Stohret al.[65] presented theREaltime with Commercial Off-The-ShelfMultiprocessor Systems (RECOMS) software architecture, which is a framework for running a general-purpose OS and an RTOS on the same multi- processor machine. This framework partitions the system by placing the general-purpose OS on its own processor and preventing I/O accesses from interfering with the RTOS. RECOMS was designed as an extension to the RealTime Application Interface, or RTAI [31], which is closely related to RTLinux, and therefore the work in [65] is different from LITMUSRT
in the same ways. The static partitioning of the system may allow tasks to perform better with the RECOMS architecture than RTLinux, especially if the non-real-time and real-time workloads are assigned to cores that share different sets of resources (e.g., caches), but is still less flexible than LITMUSRT. Additionally, the work in [65] suffers from the problem that real-time tasks cannot invoke Linux kernel services.
2.3.4 Linux Real-Time Preempt Patch
The Real-Time Preempt Patch [51] is a patch against mainline Linux, and represents a large- scale effort to create a version of Linux that is more suitable for real-time applications. The main feature that is provided as a part of this project is a fully preemptible kernel. The features to support a fully preemptible kernel include preemptible spin locks and critical sec- tions with support for priority inheritance, representation of interrupt handlers as preemptible kernel threads, and a new Linux timer API that supports user-space high-resolution POSIX timers. One goal of this project is to merge many of these features into the mainline kernel, so that more sophisticated real-time support can be provided natively—in fact, merging is in progress for some of the features listed here. This would eliminate the need for patches that must “keep up” with mainline Linux changes independently (meaning that the latest mainline Linux kernel features cannot be used until a patch is created for that kernel release).