DOCSLIB.ORG

Linux and Realtime

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Linux and Realtime LINUX AND REALTIME 1 PRESENTATION Pierre Morel - MNIS Paris and Toulouse - France [email protected] Linux Port on new architectures, Realtime and Virtualization OCERA european project on Realtime components in cooperation with UPVLC, Santa-Anna and Prague UWEP mexican/franco project for the development of an ARM Hypervisor in cooperation with Siteldi LHA IBM research project for application virtualization in Linux 2 LINUX AND REALTIME Linux is not a Realtime Operating System "...and will never be" Linus Torwald Possible solutions Modification of Linux core Interrupt virtualization and co-kernel Complete Virtualization and co-domain 3 WHY IS LINUX NOT REALTIME 4 RECALL: LINUX 2.6 / 3.X Interrupt latency Context switch latency Scheduling Memory handling Spinlocks and preemption 5 INTERRUPT LATENCY This is the time between receiving an interrupt and starting associated action In realtime system the action is done by a realtime thread not the driver Let see what is happening in Linux kernel 6 INTERRUPT LATENCY 7 INTERRUPT LATENCY Tasklets and soft-interrupts may differ thread without any determinism including kernel threads Network implementation is particularly bad for realtime Even with the NAPI, it makes heavy use of soft- interrupt and interrupt disabling 8 CONTEXT SWITCH LATENCY With Linux 2.6 we have better preemptions politics A good choice is essential to lower the latency and that is even for co-kernel adaptions as we will see later 9 NO PREEMPTION 10 VOLUNTARY PREEMPTION 11 PREEMPTIBLE KERNEL 12 SPINLOCKS Spinlocks are used to synchronize data access from concurrent processor in SMP/SMT. Due to kernel preemption the Linux implementation also disable preemption when a spinlock is locked This of course increase context switch latency The biggest trouble is caused by the Big Kernel Lock which only disappear after 2.6.38 13 LINUX SCHEDULER Linux scheduler is O1 This means equal time to choose a task whatever the load is Sadly, available scheduling policies are very primitive Rate Monotonic FIFO and RR (Round Robin) with 99 priority levels This is POSIX 1003.1b compliant 14 O1 SCHEDULER 15 PRIORITY INVERSION "Handling of priority inversion may be solved by a good application programming" Victor Yodaiken (RTLinux) There are also possibilities to handle this in the kernel itself or in the libraries. What is it exactly? What really happened on mars? http://en.wikipedia.org/wiki/Priority_inversion 16 PRIORITY INVERSION 17 PRIORITY INVERSION 18 PRIORITY INVERSION 19 PRIORITY INVERSION Two measures Priority ceiling priority inheritance In the Linux kernel, only rt-mutex(9) handle priority inheritance. They are only used in the i2c driver... In user space, GLIBC handle P.I. using priority ceiling: pthread_mutex_setprioceiling(3p) 20 MODIFYING LINUX 21 UNIVERSITY PROJECTS Linux-RT (Thomas Gleixner) Free community project is open and GPL ART-Linux Japanese project but is not open source 22 COMMERCIAL PROJECTS SYSLinux (Thomas Gleixner) is partially open source and working in the same direction as Linux-RT. Montavista Took also the same direction. 23 LINUX-RT Tasklet and interrupt routines are re-implemented as threads Spinlocks are modified to allow preemption A new EDF scheduler is actually developed 24 THREADED INTERRUPTS Interrupt routines are reimplemented as threads You may modify the priorities of the threads with tools like chrt(8) or sched_setscheduler(2) Some good examples for the optimization of audio threads: irqPriorities.html on linux-rt wiki 25 SPINLOCKS MODIFICATIONS Linux vanilla spinlocks disable preemption when holding the lock. This increase context switch latency from this duration Linux-RT replace this by having more dedicated spinlocks and disabling migration in for SMP BKL has been eliminated 26 EDF SCHEDULER The Earliest Deadline First scheduler makes RT thread programming easier It also allow a better CPU usage for periodic tasks The implementation is done by University Santa Anna - Pisa (ReTIS Lab) and the Evidence spin-off Not yet in the kernel because priority inversion is not handled (but encouraged by T. Gleixner) 27 ART-LINUX ART-Linux is used in japanese robotic projects Major change is done by changing standard interrupt handling implementation with interrupt poling. Priority inheritance on kernel mutexes has been implemented 28 MEMORY HANDLING Take care of COW and lazy allocations bypass the Linux On demand Paging by using mmap(2) and MAP_POPULATE flag pre-fault memory for stack and text code Lock memory so no swap occurs using lock(2) You may also use a dedicated memory management like (TLSF) if you want to use dynamic alloc/free. 29 CO-KERNEL AND INTERRUPT VIRTUALIZATION 30 CO-KERNEL RT-Linux: Victor Yodaiken / Barbanov (FSMLabs) RTAI: Paolo Mantegazza (Aero-Polimiti Milano) Xenomai: Philippe Gerum 31 INTERRUPT VIRTUALIZATION 32 INTERRUPT VIRTUALIZATION 33 INTERRUPT VIRTUALIZATION 34 SECURITY AND MEMORY ACCESS In this implementation both co-kernel shared the same memory space Realtime applications also share the same memory space No protection against faults from Linux or from RTOS 35 ADEOS Adaptive Domain Environment for Operating Systems Karim Yagmour - Opersys who also done L.T.T. Virtualization of events - especially interruptions 36 ADEOS 37 ADEOS 38 ADEOS 39 ADEOS 40 ADEOS 41 XENOMAI/RTAI LXR 42 SECURITY AND MEMORY ACCESS At least in this implementation, realtime applications and standard Linux applications are protected against faults. But.. both kernel shared the same space 43 SCHEDULING By design, Xenomai scheduling must be full compatible with Linux scheduling Only SCHED_FIFO and SCHED_RR are supported 44 SCHEDULING LINUX 45 SCHEDULING XENOMAI 46 SCHEDULING LATENCY Scheduling latency is minimal with the usage of in kernel realtime tasks. For users space threads, the maximal scheduling latency is obtain when a Xenomai thread entered Linux scheduler until it reaches a preemption point. 47 MEMORY HANDLING In kernel memory allocation using standard Linux memory must on start. For example in _init() function of the RTLinux module You must use a dedicated memory management like (TLSF) if you want to use dynamic alloc/free. TLSF is implemented by Universidad Politecnica de Valencia 48 MEMORY HANDLING In user space take care of COW and lazy allocations bypass the Linux On demand Paging by using mmap(2) and MAP_POPULATE flag pre-fault memory for stack and text code Lock memory so no swap occurs using lock(2) You may also use a dedicated memory management like (TLSF) if you want to use dynamic alloc/free. 49 USEFUL FEATURES Emulation of different realtime operating systems VxWorks, PSOS+, VRTX, UITRON, POSIX, RTAI Comedi, a librairy of Analogic Digital converters Analogy, a library of sensors drivers RTNET, real time ethernet using TDMA 50 CONCLUSION Pro responsiveness, low latency Integration of RTNET RTOS emulations Contra: No good scheduler, only Linux schedulers 51 MEASURE AND TESTS 52 REAL-TIME HYPERVISORS 53 HYPERVISORS 54 HYPERVISORS Two types type 1: bare metal (xen, XtratuM, L4, ESX...) type 2: OS based (qemu, vmware workstation) Three families micro-kernels (L4) complete virtualization (xen) para-virtualization (xen, ESX, XtratuM) 55 HYPERVISORS Main features Spatial isolation, MMU virtualization CPU and Interrupt virtualization Peripherals virtualization Inter domain Communication Applications Security, cryptographic applications isolation System mobility, HAC, HPC 56 MMU 57 MMU VIRTUALIZATION 58 CPU VIRTUALIZATION end of 60th: IBM S360 first virtual machine Popeck and Goldberg define a virtualizable CPU CPU has two modes: normal and privileged "sensitive control instructions and sensitive behaving instruction must be privileged instructions" Privileged instructions in normal mode are trapped Most CPU respect this more or less but Intel CPU 2005: with VTX intel gains CPU virtualization 59 PRE VIRTUALIZATION 60 WHAT IF THE CPU CAN NOT BE VIRTUALIZED Para virtualization The source code is modified Pre virtualization The binary of the program is modified Binary rewriting The binary of the process is modified 61 PARA VIRTUALIZATION 62 PRE VIRTUALIZATION 63 GENERAL PURPOSE HYPERVISORS Qemu Qemu is also an emulator supporting ARM, MIPS, SH4, PowerPC... KVM, Virtualbox and Xen use Qemu Vmware, HyperV IBM, SUN and HP have their own solutions used for High Availabilities and High Performance Computing 64 SPATIAL ISOLATION 65 REAL-TIME HYPERVISORS Temporal isolation a domain can not delay the execution of another domain Hypervisor scheduler adds determinism, EDF, ARINC May or may not allow more than one RTOS 66 TEMPORAL ISOLATION 67 REAL-TIME HYPERVISORS VLX (Virtual Logix / Red Bend) L4 is a german project from Dresden and Karlsruhe OKL4 and Sysgo hypervisor are based on L4 XtratuM is a spanish project from Valencia Other projects: WindRiver, Freescale, Xen, Trangon/Vmware ... 68 XEN AS A REAL-TIME HYPERVISORS Corean Project - Chuck Yoo If all domains are scheduled by EDF schedulers and the Hypervisor uses EDF algorithm The tasks within each domain will be scheduled in deterministic manner. 69 DRIVER IMPLEMENTATION A domain has access to his own peripheral (VLX, XtratuM) A domain is dedicated as driver (L4, Xtratum) A domain is dedicated for all drivers (Xen) 70 DRIVER DOMAIN 71 COMPARING THE SOLUTIONS Next slides shows a comparison between the different solutions and where the different services are implemented: shared or private in user space, kernel space, domain or hypervisor 72 Linux Task Linux Task Linux syscall interface Scheduler IO Logic Tasklets IRQ routine Do_IRQ IRQ Vectors CPU Device PIC
Load more

Recommended publications
  • Industrial Control Via Application Containers: Migrating from Bare-Metal to IAAS
    Industrial Control via Application Containers: Migrating from Bare-Metal to IAAS Florian Hofer, Student Member, IEEE Martin A. Sehr Antonio Iannopollo, Member, IEEE Faculty of Computer Science Corporate Technology EECS Department Free University of Bolzano-Bozen Siemens Corporation University of California Bolzano, Italy Berkeley, CA 94704, USA Berkeley, CA 94720, USA fl[email protected] [email protected] [email protected] Ines Ugalde Alberto Sangiovanni-Vincentelli, Fellow, IEEE Barbara Russo Corporate Technology EECS Department Faculty of Computer Science Siemens Corporation University of California Free University of Bolzano-Bozen Berkeley, CA 94704, USA Berkeley, CA 94720, USA Bolzano, Italy [email protected] [email protected] [email protected] Abstract—We explore the challenges and opportunities of control design full authority over the environment in which shifting industrial control software from dedicated hardware to its software will run, it is not straightforward to determine bare-metal servers or cloud computing platforms using off the under what conditions the software can be executed on cloud shelf technologies. In particular, we demonstrate that executing time-critical applications on cloud platforms is viable based on computing platforms due to resource virtualization. Yet, we a series of dedicated latency tests targeting relevant real-time believe that the principles of Industry 4.0 present a unique configurations. opportunity to explore complementing traditional automation Index Terms—Industrial Control Systems, Real-Time, IAAS, components with a novel control architecture [3]. Containers, Determinism We believe that modern virtualization techniques such as application containerization [3]–[5] are essential for adequate I. INTRODUCTION utilization of cloud computing resources in industrial con- Emerging technologies such as the Internet of Things and trol systems.
    [Show full text]
  • Linux Scheduler Documentation
    Linux Scheduler Documentation The kernel development community Jul 14, 2020 CONTENTS i ii CHAPTER ONE COMPLETIONS - “WAIT FOR COMPLETION”BARRIER APIS 1.1 Introduction: If you have one or more threads that must wait for some kernel activity to have reached a point or a specific state, completions can provide a race-free solution to this problem. Semantically they are somewhat like a pthread_barrier() and have similar use-cases. Completions are a code synchronization mechanism which is preferable to any misuse of locks/semaphores and busy-loops. Any time you think of using yield() or some quirky msleep(1) loop to allow something else to proceed, you probably want to look into using one of the wait_for_completion*() calls and complete() instead. The advantage of using completions is that they have a well defined, focused pur- pose which makes it very easy to see the intent of the code, but they also result in more efficient code as all threads can continue execution until the result isactually needed, and both the waiting and the signalling is highly efficient using low level scheduler sleep/wakeup facilities. Completions are built on top of the waitqueue and wakeup infrastructure of the Linux scheduler. The event the threads on the waitqueue are waiting for is reduced to a simple flag in ‘struct completion’, appropriately called “done”. As completions are scheduling related, the code can be found in ker- nel/sched/completion.c. 1.2 Usage: There are three main parts to using completions: • the initialization of the ‘struct completion’synchronization object • the waiting part through a call to one of the variants of wait_for_completion(), • the signaling side through a call to complete() or complete_all().
    [Show full text]
  • RTAI-Lab Tutorial: Scicoslab, Comedi, and Real-Time Control
    RTAI-Lab tutorial: Scicoslab, Comedi, and real-time control Roberto Bucher 1 Simone Mannori Thomas Netter 2 May 24, 2010 Summary RTAI-Lab is a tool chain for real-time software and control system development. This tutorial shows how to install the various components: the RTAI real-time Linux kernel, the Comedi interface for control and measurement hardware, the Scicoslab GUI-based CACSD modeling software and associated RTAI-Lab blocks, and the xrtailab interactive oscilloscope. RTAI-Lab’s Scicos blocks are detailed and examples show how to develop elementary block diagrams, automatically generate real-time executables, and add custom elements. 1Main RTAI-Lab developer, person to contact for technical questions: roberto.bucher at supsi.ch, see page 46 Contents 1 Introduction 4 1.1 RTAI-Lab tool chain . .4 1.2 Commercial software . .4 2 Installation 5 2.1 Requirements . .5 2.1.1 Hardware requirements . .5 2.1.2 Software requirements . .6 2.2 Mesa library . .7 2.3 EFLTK library . .7 2.4 Linux kernel and RTAI patch . .7 2.5 Comedilib . .8 2.6 RTAI (1st pass) . .8 2.7 RTAI tests . .9 2.8 Comedi . .9 2.9 RTAI (2nd pass) . 10 2.10 ScicosLab . 11 2.11 RTAI-Lab add-ons to Scicoslab-4.4 . 11 2.12 User configuration for scicoslab-4.4 . 11 2.13 Load the modules . 11 3 Development with RTAI-Lab 13 3.1 Boot Linux-RTAI . 13 3.2 Start Scicos . 13 3.3 RTAI-Lib palette . 14 3.4 Real-time sinewave: step by step . 16 3.4.1 Create block diagram .
    [Show full text]
  • Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data
    Studies in Big Data 22 Constandinos X. Mavromoustakis George Mastorakis Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data Volume 22 Series editor Janusz Kacprzyk, Polish Academy of Sciences, Warsaw, Poland e-mail: [email protected] About this Series The series “Studies in Big Data” (SBD) publishes new developments and advances in the various areas of Big Data-quickly and with a high quality. The intent is to cover the theory, research, development, and applications of Big Data, as embedded in the fields of engineering, computer science, physics, economics and life sciences. The books of the series refer to the analysis and understanding of large, complex, and/or distributed data sets generated from recent digital sources coming from sensors or other physical instruments as well as simulations, crowd sourcing, social networks or other internet transactions, such as emails or video click streams and other. The series contains monographs, lecture notes and edited volumes in Big Data spanning the areas of computational intelligence incl. neural networks, evolutionary computation, soft computing, fuzzy systems, as well as artificial intelligence, data mining, modern statistics and Operations research, as well as self-organizing systems. Of particular value to both the contributors and the readership are the short publication timeframe and the world-wide distribution, which enable both wide and rapid dissemination of research output. More information about this series at http://www.springer.com/series/11970 Constandinos X. Mavromoustakis George Mastorakis ⋅ Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era 123 Editors Constandinos X.
    [Show full text]
  • On the Defectiveness of SCHED DEADLINE W.R.T. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H
    On the Defectiveness of SCHED_DEADLINE w.r.t. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H. Anderson [email protected] {sytang,anderson}@cs.unc.edu Scuola Superiore Sant’Anna University of North Carolina at Chapel Hill Pisa, Italy Chapel Hill, USA ABSTRACT create new DL tasks until existing DL tasks reduce their bandwidth SCHED_DEADLINE (DL for short) is an Earliest-Deadline-First consumption. Note that preventing over-utilization is only a neces- sary condition for guaranteeing that tasks meet deadlines. (EDF) scheduler included in the Linux kernel. A question motivated Instead of guaranteeing that deadlines will be met, AC satisfes by DL is how EDF should be implemented in the presence of CPU afnities to maintain optimal bounded tardiness guarantees. Recent two goals [3]. The frst goal is to provide performance guarantees. works have shown that under arbitrary afnities, DL does not main- Specifcally, AC guarantees to each DL task that its long-run con- tain such guarantees. Such works have also shown that repairing sumption of CPU bandwidth remains within a bounded margin DL to maintain these guarantees would likely require an impractical of error from a requested rate. The second goal is to avoid the overhaul of the existing code. In this work, we show that for the starvation of lower-priority non-DL workloads. Specifcally, AC special case where afnities are semi-partitioned, DL can be modi- guarantees that some user-specifed amount of CPU bandwidth fed to maintain tardiness guarantees with minor changes. We also will remain for the execution of non-DL workloads.
    [Show full text]
  • Xtratum User Manual
    XtratuM Hypervisor for LEON4 Volume 2: XtratuM User Manual Miguel Masmano, Alfons Crespo, Javier Coronel November, 2012 Reference: xm-4-usermanual-047d This page is intentionally left blank. iii/134 DOCUMENT CONTROL PAGE TITLE: XtratuM Hypervisor for LEON4: Volume 2: XtratuM User Manual AUTHOR/S: Miguel Masmano, Alfons Crespo, Javier Coronel LAST PAGE NUMBER: 134 VERSION OF SOURCE CODE: XtratuM 4 for LEON3 () REFERENCE ID: xm-4-usermanual-047d SUMMARY: This guide describes the fundamental concepts and the features provided by the API of the XtratuM hypervisor. DISCLAIMER: This documentation is currently under active development. Therefore, there are no explicit or implied warranties regarding any properties, including, but not limited to, correctness and fitness for purpose. Contributions to this documentation (new material, suggestions or corrections) are welcome. REFERENCING THIS DOCUMENT: @techreport fxm-4-usermanual-047d, title = fXtratuM Hypervisor for LEON4: Volume 2: XtratuM User Manualg, author = f Miguel Masmano and Alfons Crespo and Javier Coronelg, institution = fUniversidad Polit´ecnicade Valenciag, number = fxm-4-usermanual-047dg, year=fNovember, 2012g, g Copyright c November, 2012 Miguel Masmano, Alfons Crespo, Javier Coronel Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ”GNU Free Documentation License”. Changes: Version Date Comments 0.1 November, 2011 [xm-4-usermanual-047] Initial document 0.2 March, 2012 [xm-4-usermanual-047b] IOMMU included.
    [Show full text]
  • RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (Built 15Th February 2018)
    RTEMS C User Documentation Release 4.11.3 ©Copyright 2016, RTEMS Project (built 15th February 2018) CONTENTS I RTEMS C User’s Guide1 1 Preface 5 2 Overview 9 2.1 Introduction...................................... 10 2.2 Real-time Application Systems............................ 11 2.3 Real-time Executive.................................. 12 2.4 RTEMS Application Architecture........................... 13 2.5 RTEMS Internal Architecture............................. 14 2.6 User Customization and Extensibility......................... 15 2.7 Portability....................................... 16 2.8 Memory Requirements................................. 17 2.9 Audience........................................ 18 2.10 Conventions...................................... 19 2.11 Manual Organization................................. 20 3 Key Concepts 23 3.1 Introduction...................................... 24 3.2 Objects......................................... 25 3.2.1 Object Names................................. 25 3.2.2 Object IDs................................... 25 3.2.2.1 Thirty-Two Object ID Format.................... 25 3.2.2.2 Sixteen Bit Object ID Format.................... 26 3.2.3 Object ID Description............................. 26 3.3 Communication and Synchronization........................ 27 3.4 Time.......................................... 28 3.5 Memory Management................................. 29 4 RTEMS Data Types 31 4.1 Introduction...................................... 32 4.2 List of Data Types..................................
    [Show full text]
  • TECOM Project Results Leaflet
    Project Results TECOM (ITEA2 ~ 06038) Delivering trust in embedded ••••••••••••••• systems n Partners Offering secure and dependable solutions Atego EADS DS for a wide range of applications Fagor ••••••••••••••••••••••••••••••••••••• Ikerlan Technicolor Technikon The TECOM (Trusted Embedded ABSTRACT ARCHITECTURES Trialog Computing) project has developed TECOM focused on the growing demand Universidad Politécnica de Madrid architectures and solutions combining for execution platforms in embedded Universidad Politécnica de Valencia embedded trust services and trusted systems that address both integrity and Visual Tools operating system technologies to security concerns. It developed abstract ensure security and dependability in architectures based on generic modules a wide range of complex and dynamic involving on one side an embedded trust n Countries involved embedded systems. The project focused services layer offering hardware security, on enabling multiple applications to and on the other trusted operating Austria be run safely on the same systems system technology involving system and France and processors while acting totally middleware space. The result can be Spain independently of each other. customised to a specific application. Applications range from protecting film rights in video-on-demand applications The state-of-the art approach to trust at n Project start to ensuring bug-free software upgrades systems level, close to the processor, is September 2007 in domestic appliances. some form of hypervisor or virtualisation application for securely partitioning the n Project end Industry and society are increasingly applications. While this has already been August 2010 dependent on embedded systems that are developed for use on PCs where it was becoming ever more complex, dynamic and possible to run two windows independently open, while interacting with progressively at the same time, it has not been available more demanding and heterogeneous for embedded systems.
    [Show full text]
  • Enabling Mobile Service Continuity Across Orchestrated Edge Networks
    This is a postprint version of the following published document: Abdullaziz, O. I., Wang, L. C., Chundrigar, S. B. y Huang, K. L. (2019). Enabling Mobile Service Continuity across Orchestrated Edge Networks. IEEE Transactions on Network Science and Engineering, 7(3), pp. 1774-1787. DOI: https://doi.org/10.1109/TNSE.2019.2953129 © 2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Enabling Mobile Service Continuity across Orchestrated Edge Networks Osamah Ibrahiem Abdullaziz, Student Member, IEEE, Li-Chun Wang, Fellow, IEEE, Shahzoob Bilal Chundrigar and Kuei-Li Huang Abstract—Edge networking has become an important technology for providing low-latency services to end users. However, deploying an edge network does not guarantee continuous service for mobile users. Mobility can cause frequent interruptions and network delays as users leave the initial serving edge. In this paper, we propose a solution to provide transparent service continuity for mobile users in large-scale WiFi networks. The contribution of this work has three parts. First, we propose ARNAB architecture to achieve mobile service continuity. The term ARNAB means rabbit in Arabic, which represents an Architecture for Transparent Service Continuity via Double-tier Migration. The first tier migrates user connectivity, while the second tier migrates user containerized applications. ARNAB provides mobile services just like rabbits hop through the WiFi infrastructure.
    [Show full text]
  • Spatial Isolation Refers to the System Ability to Detect and Avoid the Possibility That a Partition Can Access to Another Partition for Reading Or Writing
    Virtualización Apolinar González Alfons Crespo OUTLINE Introduction Virtualisation techniques Hypervisors and real-time TSP Roles and functions Scheduling issues Case study: XtratuM 2 Conceptos previos Máquina virtual (VM): software que implementa una máquina (computadora) como el comportamiento real. Hipervisor (también virtual machine monitor VMM) es una capa de software (o combinación de software/hardware) que permite ejecutar varios entornos de ejecución independientes o particiones en un computador. Partición: Entorno de ejecución de programas. Ejemplos: Linux + aplicaciones; un sistema operativo de tiempo real + tareas; … 3 Conceptos previos Partition Hypervisor 4 INTRODUCTION: Isolation Temporal isolation refers to the system ability to execute several executable partitions guaranteeing: • the timing constraints of the partition tasks • the execution of each partition does not depend on the temporal behaviour of other partitions. The temporal isolation enforcement is achieved by means of a scheduling policy: • Cyclic scheduling, the ARINC 653 • Periodic Priority Server • EDF Server • Priority 5 PARTITIONED SYSTEMS Temporal Isolation: duration Origin relative to MAF Slot (temporal window) P1P1 P2P2 P1P1 P3P3 P2P2 P2P2 P2P2 MAF (Major Frame) SlotP1P1 id = 3 start = 400ms duration = 100 partition: P1 Execution MAF 1 MAF 2 MAF 3 MAF 4 6 INTRODUCTION: Isolation Spatial isolation refers to the system ability to detect and avoid the possibility that a partition can access to another partition for reading or writing. The hardware
    [Show full text]
  • Hugo Gonzálezgonzález
    This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/ HugoHugo GonzálezGonzález @hugo_glez http://atit.upslp.edu.mx/~hugo/ Linux en sistemas de tiempo realLinux en sistemas de tiempo real Hugo Francisco González Robledo [email protected] presenta: Sistema Operativo de Tiempo Real ● Un sistema operativo de tiempo real (SOTR o RTOS ­Real Time Operating System en inglés), ha sido desarrollado para aplicaciones de tiempo real. Se le exige corrección en sus respuestas bajo ciertas restricciones de tiempo. Para garantizar el comportamiento correcto en el tiempo requerido se necesita que el sistema sea predecible (determinista). 1 [1] Fuente: Wikipedia. http://es.wikipedia.org/wiki/Sistemas_operativos_de_tiempo_real ¿Qué es tiempo real ? ● Tiempo real en los sistemas operativos: ● La habilidad del sistema operativo para proveer un determinado nivel de servicio bajo un tiempo de respuesta definido.2 [2] ­ POSIX Standard 1003.1 Catacterísticas ● Usado típicamente para aplicaciones integradas, normalmente tiene las siguientes características: – No utiliza mucha memoria – Cualquier evento en el soporte físico puede hacer que se ejecute una tarea – Multi­arquitectura (puertos de código para otro tipo de CPU) – Muchos tienen tiempos de respuesta predecibles para eventos electrónicos Características deseables 3 ● Multi­threaded y pre­emptible ● Thread priority has to exist because no deadline driven
    [Show full text]
  • Virtualization Technologies Overview Course: CS 490 by Mendel
    Virtualization technologies overview Course: CS 490 by Mendel Rosenblum Name Can boot USB GUI Live 3D Snaps Live an OS on mem acceleration hot of migration another ory runnin disk alloc g partition ation system as guest Bochs partially partially Yes No Container s Cooperati Yes[1] Yes No No ve Linux (supporte d through X11 over networkin g) Denali DOSBox Partial (the Yes No No host OS can provide DOSBox services with USB devices) DOSEMU No No No FreeVPS GXemul No No Hercules Hyper-V iCore Yes Yes No Yes No Virtual Accounts Imperas Yes Yes Yes Yes OVP (Eclipse) Tools Integrity Yes No Yes Yes No Yes (HP-UX Virtual (Integrity guests only, Machines Virtual Linux and Machine Windows 2K3 Manager in near future) (add-on) Jail No Yes partially Yes No No No KVM Yes [3] Yes Yes [4] Yes Supported Yes [5] with VMGL [6] Linux- VServer LynxSec ure Mac-on- Yes Yes No No Linux Mac-on- No No Mac OpenVZ Yes Yes Yes Yes No Yes (using Xvnc and/or XDMCP) Oracle Yes Yes Yes Yes Yes VM (manage d by Oracle VM Manager) OVPsim Yes Yes Yes Yes (Eclipse) Padded Yes Yes Yes Cell for x86 (Green Hills Software) Padded Yes Yes Yes No Cell for PowerPC (Green Hills Software) Parallels Yes, if Boot Yes Yes Yes DirectX 9 Desktop Camp is and for Mac installed OpenGL 2.0 Parallels No Yes Yes No partially Workstati on PearPC POWER Yes Yes No Yes No Yes (on Hypervis POWER 6- or (PHYP) based systems, requires PowerVM Enterprise Licensing) QEMU Yes Yes Yes [4] Some code Yes done [7]; Also supported with VMGL [6] QEMU w/ Yes Yes Yes Some code Yes kqemu done [7]; Also module supported
    [Show full text]