Asymmetric real-time multiprocessing on multi-core CPUs
By Paul Fischer, TenAsys
The latest multi-core processors are ideal for imple menting multi-OS embedded applications. Virtualisation technology makes it possible for a multi-core system to easily support multiple operating systems on a single computer platform.
■ Many real-time embedded applications can be cost-reduced through the use of multi-core processors, integrating applications previously composed of multiple discrete real-time sub systems into single computing platforms with different real-time tasks running on different processor cores. The key to support different real-time OS tasks on different cores is to use a real-time operating system environment that supports virtualisation. Contrary to popular thought, in most hard real-time systems only a small subset of the processor tasks must be ca pable of delivering hard real-time, or deter ministic, performance. By partitioning a soft ware system into subsets that must perform time-critical processing from those which are not time-critical, critical software tasks can be assigned to dedicated hardware resources, ensuring a robust and responsive system design.
Partitioning resources is not a new idea. It is a common design practice. What is new, espe cially for embedded systems, is the nature of the hardware resources. In the past, an entire processor board or I/O board, such as a dedi cated DSP card, would have been allocated for the purpose of real-time data collection, pro cessing, and control. Expensive communication links would have been used to coordinate these stand-alone dedicated real-time hardware resources with high-level supervisory con trollers. Now that multi-core processors are available, rather than allocating time-critical software to a dedicated processor or I/O board, embedded system designers can assign a real time task to a dedicated processor core. In fact, allocating I/O resources to a specific processor core (or cores) on a multi-core processor has the same effect as dedicating a separate proces sor board, but without the expense of the extra hardware and communications overhead needed to interface the discrete modules.
Having CPU cores that are dedicated to executing their own RTOS and real-time applications, with other CPU core(s) hosting a general-purpose OS such as Windows or Linux, the system designer can not only optimise hard ware resources, he or she can optimise software engineering resources as well. Such a system is an asymmetric multiprocessing system since the processor cores are not being load-shared across a single OS but are dedicated to specific tasks, in this case simultaneously running multiple operating systems.
Real-time programmers know how to work with low-level hardware and they understand how to tune control systems. User-interface, database, and networking programmers know how to work with high-level APIs and they un derstand complex data exchange protocols. By giving each discipline the environment they need to get their job done - a real-time oper ating system for the former and a general purpose operating system for the latter - and hosting both on a single low-cost multi-core platform, one can minimize cost and time-to-market, and maximise the use of one's engi neering resources and software technologies. An added advantage is the ability to host legacy real-time applications on separate core (s), min imising software changes to proven code while simultaneously allowing new application code to be hosted on other cores.
Running legacy RTOS code in a virtual real time machine can also be used to migrate proven real-time applications from obsolete hardware to modern embedded platforms. Be cause I/O can be virtualised, it is possible to simulate old hardware devices, minimising rewrite of proven legacy code. For example, a VMEbus system could be converted to a less ex pensive single-board computer system by in tercepting I/O requests to legacy VMEbus I/O and redirecting those requests to equivalent on board I/O devices. To simplify the development of both real-time and human-directed appli cation elements on the same platform, engi neers should seek out integrated development environments that support both types of pro gramming. For example, Microsoft Visual Stu dio can be used to create both Windows applications and real-time tasks that run on TenAsys' INtime OS, within a single solution file, for
31
Two virtual PCI devices created by the real-time hypervisor are used to implement a shared memory interface between two virtual machines.
With a real-time hypervisor, a quad-core processor can host multiple RTOS and GPOS operating environments.
maximum efficiency. The latest multi-core processors are ideal for implementing multi-OS embedded applications. Virtualisation tech nology, embedded in the processors, makes it possible for a multi-core system to easily sup port multiple operating systems on a single computer platform. For example, all Intel Core microarchitecture processors include hard ware assistance for implementing virtual hard ware systems. A collection of instructions, traps, and a new privileged operating mode is referred to collectively as Intel virtualisation technology, or Intel VT. Intel VT is used by vir tual machine manager (VMM) software to host multiple virtual machines on a single hardware platform. Virtualisation technology fills gaps in standard Intel architecture processors making it easier for a VMM to monitor and control ac cess to the supervisory elements of the Intel ar chitecture processor. In other words, virtuali-sation technology simplifies and assists the process of simultaneously running multiple protected-mode operating systems on a single hardware platform. Virtualisation hardware, such as that integrated into the latest multi-core processors, improves the ability to control ac cess to system level registers, trap interrupts (re gardless of masking state), monitor page tables, and control access to the memory used by each operating system on the platform. Virtualisa-tion enables multiple control loops to run si multaneously and improves the ability to isolate I/O and memory, ensuring a distinct boundary between real-time processes and threads from non-deterministic code. Dedicating one core of a multi-core processor to an RTOS and its ap plications ensures 100% of the CPU instruction cycles of that core are dedicated to real-time processing.
The remaining core(s) are used exclusively by other operating system(s), which could be ei ther a GPOS or another RTOS. Because each processor core is dedicated to an operating sys tem and its tasks, contention for key CPU re sources, such as pipelines and the FPU, are avoided, maximising performance and re sponsiveness of both operating systems. Coor dination between the RTOS virtual machine(s) and the GPOS virtual machine(s) is managed by using shared-memory and the built-in inter-processor interrupts, eliminating inter-OS context switch times.
Removing contention for resources in a multi-OS platform has a dramatic impact on real time performance metrics, such as interrupt l atency. TenAsys has measured a 10 to 1 im provement for interrupt latency on dual-core multi-OS platforms compared to equivalent clock speed single-core multi-OS platforms. La tencies measured in the 10-30 microseconds range on single-core systems have been reduced by an order of magnitude to 1-3 microseconds on dual-core systems. With such low latencies real-time application control loops can execute in the 50-200 microsecond range with very high precision, while simultaneously supporting a general purpose OS, such as Windows! An example of an operating environment that supports asymmetric multiprocessing systems is the TenAsys INtime RTOS for Windows.
If you confuse virtual memory with virtual machines, you might conclude that it is not possible to build a deterministic real-time system using virtualisation technology. The two ideas only share a common adjective. One has nothing to do with the other. In fact, in a virtual real-time machine all resources are real and physical: memory, I/O, and CPU cycles. With out this, one could never guarantee the performance or latencies required to call the system hard real-time. Low interrupt latency, direct access to specialized I/O, and a schedul ing policy that ensures determinism and priority of real-time functions are key require ments of a real-time virtual machine. Multi-core CPUs and the virtualisation technology built into them are ideal platforms for mixing operating systems on a single system.
By utilising a hybrid approach to allocating re sources, compared to conventional virtual ma chine managers, it is possible to satisfy the needs of two very different environments. In an asymmetric multiprocessing system hosted on a multi-core processor platform, there is no rea son to share resources between operating sys tems. Instead, key physical resources are stati cally allocated to each virtual machine, based on the needs defined by the embedded system de signer. In a conventional VMM access to re sources is evenly multiplexed between the vir tual machines, in order to maximise use of the machine. This is, however, not a good solution for real-time systems. When determinism and performance are more important than equal access, the VMM must distinguish between re sources that must be isolated for use by a spe cific virtual machine and its guest OS and those I/O resources that are shared between multiple virtual machines.
For example, user interface I/O is usually not associated with time-critical events, so devices like the keyboard, mouse, console, disk, and an enterprise Ethernet interface can be shared be tween virtual machines. However, hardware that is specific to a real-time control applica tion, such as a video capture card, a fieldbus interface, or an Ethernet network interface con troller (NIC) designated for communication with real-time I/O devices, should not be mul tiplexed between virtual machines. This notion of applying I/O exclusively to a specific virtual machine is essential to guarantee real-time responsiveness, because it allows a real-time virtual machine to have direct physical access to its dedicated I/O. Without exclusive physical assignment of pertinent I/O one runs the risk of waiting indeterminately for access to key devices, which can cause failure of time-deter ministic processes depending on that I/O operation.
Having consolidated two or more operating systems on one platform, the VMM can facili tate inter-OS communication using shared memory. Since one or more CPUs are dedicat ed to each operating system, message sig nalling can be provided by way of inter-proces sor interrupts (IPIs) between the CPUs. This shared-memory interface is capable of provid-
32
ing very high performance communication. More complex protocols may then be built on top of this base. Virtual devices can be used as the interface for inter-OS protocols, especially for integration within legacy operating systems and applications. In this case, the inter-OS pro tocol can be implemented entirely within a virtual hardware interface
For example, all guest operating systems can be configured to share a single area of shared memory to post common data. After each guest updates its data structure it signals the other guests to indicate that a data update has oc curred. The shared memory can be presented via a virtual PCI device interface and a register that generates an inter-OS signal via IPI to the other guest operating systems. The VMM, also called a real-time hypervisor, allocates the shared memory area and presents a virtual PCI device to each guest via the guest OS PCI configuration space. Each virtual PCI device includes information on how each guest OS accesses the shared memory and a register to generate the inter-OS signals. In the example above, the virtual PCI device presents two memory ranges to each guest. The first memo ry range, pointed to by PCI configuration reg ister BAR0, maps the shared memory buffer to an accessible address range within the guest OS.
The second range, pointed to by BAR1, presents an I/O address to the guest OS. When an ap plication within the guest OS accesses the BAR1 I/O address, a trap is made into the vir tual device driver hosted by the hypervisor. The virtual device driver then injects a virtual IRQ into the target guest OS which responds by ac cessing the shared memory area for updated data.
Modern processors contain instructions de signed to efficiently perform DSP arithmetic operations. As a group these are known as SIMD instructions (single instruction, multiple data). On Intel architecture processors the SIMD instructions are referred to as the MMX and SSE instructions. MMX instructions were introduced first and are limited to integer op erations. SSE instructions were introduced later and can efficiently handle floating point DSP operations and vector arithmetic. These SIMD instructions are ideal for implementing digital filters, the basis of complex digital con trol algorithms, pattern recognition systems, and video streaming and mixing applications.
Rather than dedicate a costly DSP board inside a dedicated RTOS platform and/or a GPOS box to implement a complex control system, it makes more economic sense to combine these functions into a single hardware platform. Where previously a GPOS system was used for human interface and enterprise network access, an RTOS box for primary machine control, and a DSP board for high-performance data acqui sition and filtering, it is now possible to combine them on a single multi-core processor system. By applying asymmetric multiprocessing, one can simultaneously operate three virtual machines on a single platform, dedicating a CPU core to each function, without the cost and complicated development and test associated with multiple separate pieces of hardware. ■
33
Комментариев нет:
Отправить комментарий