| A comparison of real-time Linux approaches |
by Paul E. McKenney (Jun. 10, 2005)
Foreword -- Paul McKenney recently summarized seven approaches to real-time Linux, in an epic 6,000-word post to the Linux Kernel Mailing List (lkml). McKenney's original post is reproduced below; curious readers are invited to consult the lkml archives, and follow up in the TalkBack at the end of this story. Enjoy . . . !
Date Tue, 7 Jun 2005 19:26:46 -0700 From "Paul E. McKenney" Subject Attempted summary of "RT patch acceptance" thread
Hello!
Midway through the recent "RT patch acceptance" thread, someone mentioned that it might be good to summarize the various approaches. The following is an attempt to do just this, with an eye to providing a reasonable framework for future discussion.
Thoughts? Errors? Omissions?
[Quickly donning the asbestos suit with tungsten pinstripes...]
Thanx, Paul
CONTENTS - INTRODUCTION
- DESIRABLE PROPERTIES
- LINUX REALTIME APPROACHES
- SUMMARY
Search for a line beginning with the corresponding capital letter followed by a period to jump to the corresponding section.
A. INTRODUCTION
Common wisdom dictates that realtime operating systems, particularly hard-realtime operating systems, must be designed from ground up; that serious realtime support cannot be simply grafted onto an existing general-purpose operating system. Although this common wisdom was not arrived at lightly, it is often worthwhile to look for important exceptions to this sort of general rule of thumb. Candidate exceptions include:
- Many realtime applications use a very restricted subset of the services provided by a general-purpose OS like Linux. Some applications require realtime support only for scheduling user-mode code, for example, an application that directly accesses MMIO registers mapped into its address space. This observation leads to the possibility of providing very limited realtime support.
- Computer performance and capacity has increased dramatically over the past few decades, quite literally by multiple orders of magnitude. A small embedded system can easily be much more capable than a mid-70s supercomputer, for example, the vaunted Cray-1, introduced in 1976, ran at 160MFLOPs and sported 8MB of main memory. In today's terms, this would be a modest embedded system -- and just you try running Linux on an 8MB system! This dramatic increase in performance permits some applications that would have required heavy-duty RTOS support in the 70s to run reasonably well on unmodified general-purpose OSes.
There are still limits to the degree of realtime support that one can expect from a general-purpose OS -- there are some extremely demanding applications that can be satisfied only by hand-coded assembly running on bare metal. In fact, there are applications that can be satisfied only by custom hardware implementations.
Nevertheless, it is clear that Linux can support significant realtime requirements, as it is already being used heavily in the realtime arena. But how far should Linux extend its realtime support, and what is the best way to extend Linux in this direction? Can one approach to realtime satisfy all reasonable requirements, or would it be better to support multiple approaches, each with its area of applicability?
The answers to these questions are not yet clear, and have been the subject of much spirited discussion, for example, see the more than 300 messages in the following LKML thread:
http://lkml.org/lkml/2005/5/23/156 http://marc.theaimsgroup.com/?l=linux-kernel&m=111689227213061&w=2
This document looks at some strategies that have been proposed for realtime Linux, comparing and contrasting their capabilities. But, to evaluate these strategies, it is first necessary to determine what exactly one might want in a realtime Linux. If you would rather skip straight to the comparing and contrasting, click to "LINUX REALTIME APPROACHES".
Otherwise, continue HERE . . .
Story Navigation - INTRODUCTION
- DESIRABLE PROPERTIES
- LINUX REALTIME APPROACHES
- SUMMARY
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|