A decision-tree approach to picking the right embedded multicore software architecture

Rob Oshana, Freescale

May 9, 2012

Rob Oshana, Freescale

Linux/Linux RT: A multicore fast-path alternative
An alternative fast path acceleration technique is to use Linux as a real-time operating system. A real-time system is one in which the correctness of the computations depends not only upon the logical correctness of the computation but also upon the time at which the result is produced.

If the timing constraints of the system are not met, the system will fail. Many embedded systems now have both real-time and non real-time tasks running on the OS (Figure 6).

It is very difficult to design a system that provides both low latency and high performance. However, real-world systems (such as Media, eNodeB, etc.) have both latency and throughput requirements.

For example, an eNodeB basestation has a 1 ms hard real time processing deadline for Transmission Time Interval (TTI) as well as a throughput requirement of 100 Mbps downlink (DL) and 50 Mbps (UL). This requires the need to tune the system for the right balance of latency and performance (Figure 6).

Figure 6. Linux as a Real-Time Operating System

Linux now provides soft real-time performance through a simple kernel configuration to make the kernel fully preemptable. In the standard Linux kernel, when a user space process makes a call into the kernel using a system call, it cannot be preempted.

This means that if a low-priority process makes a system call, a high-priority process must wait until that call is complete before it can gain access to the CPU.

The Linux configuration option CONFIG_PREEMPT changes this behavior of the kernel and allows Linux processes to be preempted if high-priority work is available, even if the process is in the middle of a system call.

RT-Linux also makes the system preemptive including more granular spin-locks, making the interrupt handlers kernel threads by default, and allowing higher priority tasks even if in user-space to preempt lower priority tasks at any point of time.

After working your our way through the multicore decision tree, we end up at a set of leaf nodes that describe the reference software architecture needed to implement the high level system software requirements (path through the decision tree) for the multicore system. Some of these examples are shown in Figure 7.


Click on image to enlarge.

Figure 7a: Multicore Software Reference Architecture requiring an open source virtualization solution (KVM), a Linux OS on the control plane with high performance user space I/O requirements and a fast path capability for required data flows.


Click on image to enlarge.

Figure 7b: Multicore Software Reference Architecture requiring an light weight embedded virtualization solution, two Linux OS partitions on the control plane with high performance user space I/O requirements and a fast path capability for required data flows.


Click on image to enlarge.

Figure 7c: Multicore Software Reference Architecture requiring a Linux SMP solution on the control plane with a light weight data plane environment and a fast path capability for required data flows.

We’ve discussed a number of multicore software architecture components as we assemble our multicore reference architectures. In fact we can view these architectural components as an set of building blocks or leggo bricks that can be put together in different ways to create the multicore software reference architecture (Figure 8).

Figure 8 Multicore Software Architecture is solution based on collaborating components

This approach can produce a scalable solution customized to the needs to the developer for a variety of multicore software solutions.

Rob Oshana is director of software R&D, Networking Systems Group, Freescale Semiconductor.

< Previous
Page 4 of 4
Next >

Loading comments...

Most Commented

  • Currently no items

Parts Search Datasheets.com

KNOWLEDGE CENTER