A decision-tree approach to picking the right embedded multicore software architecture
Decision 2: Choose the Operating System Framework
If AMP is chosen, the next step is to determine which Multicore Operating System Framework is required.
Unsupervised AMP runs multiple operating systems on the cores. This has the advantage of being able to keep the system 'up' if one of the OSs crashes. Establishing the separation of multiple OSs on top of a single processor with shared memory can be problematic.
AMP partitioning can solve the scalability problem of SMP, but only if the algorithm is well parallellizable. This is usually a problem left for the system integrator.
If unsupervised AMP is not the right choice then there are a number of “supervised” AMP options as shown in Figure 1. There are three primary supervised AMP options using virtualization.
Virtualization provides a software management layer that provides software protection between the different partitions as well as core management in order to optimize power efficiency. The CPUs are run as multiple independent partitions running their own OS and application.
For applications designed using multiple components that are independent and CPU bound with little contention to shared resources, this is the way to go.
Legacy software changes are not needed when using virtualization to partition multiple OSs to run within virtual machines (VMs). The Virtual Machine Manager (VMM) manages the assignment and access between the VMs and platform resources. A number of software technologies are available to enable virtualization in embedded systems:
* OS-level virtualization: uses the capabilities of an operating system kernel to enable multiple isolated instances of user-space. Each user space instance has its own private, isolated set of standard operating system resources, and applications run in this isolated “container”.
Linux containers are an example of OS-level virtualization. Containers are used in situations that require application consolidation, sandboxing, or dynamic resource management and all the software domains involved are Linux applications. It is not possible to boot an operating system in a container.
* “Type 1” hypervisors: A “type 1” hypervisor runs directly on system hardware, and is not part of a general purpose operating system a type 2 hypervisor. These are generally small, efficient hypervisors that enable the secure partitioning of a system’s resources.
A system’s CPUs, memory, and I/O devices are statically partitioned, with each partition being capable of running a guest operating system. Hypervisor do not use schedulers and simply spatially partition the CPUs.
* “Type 2” hypervisors: Type 2 hypervisors use an operating system as the basis for the virtualization layer. Virtual machines run alongside other OS applications. An example of a type 2 hypervisor is KVM (Kernel-based virtual machine).
KVM is an open source software virtualization technology also based on the Linux kernel. KVM enables Linux to act as a virtual machine monitor. KVM is essentially a Linux kernel driver that collaborates with a QEMU user space application to create and run virtual machines.
Click on image to enlarge.
Virtualization and partitioning in embedded systems enable some benefit to be gained from multi-core processors independent of explicit OS support. The ideal situation is to have symmetric multiprocessing and asymmetric multiprocessing, including virtualization, at your disposal. A summary of these primary multicore software configurations is shown in Figure 2.
Loading comments... Write a comment