Part 2: Resource Allocation

Embedded systems, even in their high-end variants, are resource constraint systems by desktop or server standards. At the same time, complexity of operations require many optimization strategies that were designed for server and desktop systems to be utilized in embedded systems as well. As standard GNU/Linux targets interactive usage and optimized average response, some of these strategies are not ideal for embedded systems. Considerations for more predictable resource allocation are required in resource constraint systems — resources in question being not only RAM and CPU consumption, but also timing and well-defined system response to critical tasks.

Standard Linux

Linux has a record of squeezing a lot of performance out of little or old hardware. This is done by relying extensively on strategies that will favor interactive over non-interactive events. For instance, writes to disk can be delayed substantially and Linux will buffer data and reorder it, writing it in a continuous manner with respect to the disks location, and out of order from the user's standpoint. These and other strategies are well-suited to improve average performance but can potentially introduce substantial delays to a specific tasks execution. This is to say that peak delays of a second or even more can occur in GNU/Linux without this indicating any faulty behavior. As embedded systems are generally resource constraint systems such optimization strategies are an improvement in most cases, but increasing system complexity and the potential of a networked system reaching very high loads (just imagine a network on which many other probably faster systems are broadcasting all kinds of important server announcements . . . ) can degrade the system's response to high priority events dramatically. This is to say that an embedded GNU/Linux system better not have any timing constraints at all and should not rely on the system's catching a specific event. If there are no such constraints with respect to timing, then an embedded system running a scaled down standard GNU/Linux will well suit most purposes and operate very efficiently.

Soft Real-time

There are many definitions floating around what soft-real-time is. I'm not an authority on this section, but give the definition used here to prevent any misunderstandings. Under Soft-real-time a system is capable of responding to a certain class of events with a certain statistical probability and an average delay. There is, however, no guarantee of handling every event, nor is there any guarantee for a maximum worst case delay in the system. In this sense every system is a soft real-time system. Of course, the term is used for systems that have enhanced capabilities in this area. In most cases this will mean:

• high-resolution timers
  
• a high-probability of reacting to a specific class of events. High probability in this sense means 'higher than regular Linux'.
  
• low average latency, again low relative to regular Linux.

Soft real-time systems are well-suited for cases where quality depends on average response time and delays, like video-conference and sound processing systems, and if the system will not fail or get into a critical state if the one or other event is lost or delayed strongly. Simply speaking, soft-real-time will improve quality of time related processing problems, but will give you no guarantee. So you can't have safety critical events depend on a soft-real-time system. There are multiple implementations of soft-real-time for Linux, starting out at simply running a thread under the SCHED_FIFO or SCHED_RR scheduling policy in standard Linux all the way to the low-latency kernel patches that make the Linux kernel partially preemptive (please no flames . . . thanks). Soft Real-time variants of Linux include RED Linux, KURT, RK-Linux and the low-latency patch of Ingo Molnar.

Hard Real-time

There are many systems that obviously have hard-real-time requirements, such as control or data-acquisition systems. But there also are a large number of systems that don't have quite so obvious hard-real-time demands: those systems that need to react to special events in a defined small time interval. These systems may be performing non-time-critical tasks in general, but emergency shutdown routines must still be serviced with a very small delay independent of the current machine state.

In such cases, a hard-real-time system is required to guarantee that no such critical event will ever be missed, even if the system goes up to an enormous system load or a user-space application blocks altogether. The criteria for requiring hard-real-time as opposed to soft-real-time are the following:

• No event of a specific category may be missed under any circumstances (e.g. emergency shutdown procedure)
  
• the system should have low latency in response to a specific type of event.
  
• periodic events should be generated with a worst case deviation guaranteed.

Note that these three criteria do overlap in a certain respect and could be reduced to a single one, that being to guarantee worst case timing variance of a specific event class, but that's not what I would call a self-explanatory definition.

RTLinux and a derivative of it called RTAI fall into the class of hard-real-time Linux variants (if you know of any others let me know). These are based on three principles:

• Unconditional Interrupt interception.
  
• delivery of non-real-time interrupts to the general-purpose OS as soft-interrupts.
  
• Run the general-purpose OS as the idle task of the RTOS.

— Continued —

---

Story navigation . . .

• Part 1: The main challenges in High-end Embedded OSes
  
• Part 2: Resource Allocation
  
• Part 3: Operational Concepts
  
• Part 4: Compatibility and Standards Issues

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.