DOCSLIB.ORG

On the Construction of Dynamic and Adaptive Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

DISS. ETH NO. 24811 On the Construction of Dynamic and Adaptive Operating Systems A thesis submitted to attain the degree of DOCTOR OF SCIENCES of ETH ZURICH (Dr. sc. ETH Zurich) presented by Gerd Zellweger Master of Science ETH in Computer Science, ETH Zurich born on 26.06.1987 citizen of Switzerland accepted on the recommendation of Prof. Dr. Timothy Roscoe (ETH Zurich), examiner Prof. Dr. Gustavo Alonso (ETH Zurich), co-examiner Prof. Dr. Jonathan Appavoo (Boston University), co-examiner 2017 Abstract Trends in hardware development indicate that computer architectures will go through considerable changes in the near future. One reason for this is the end of Moore’s Law. It implies that CPUs can no longer just become faster or made more complex due to having more and smaller transistors in a new chip. Instead, applications either have to use multiple cores or specialized hardware to achieve performance gains. Another reason is the end of Dennard scaling which means that as transistors get smaller, the consumed power per chip area does no longer remain constant. The implications are that large areas of a chip have to be powered down most of the time and system software has to dynamically enable and disable the hardware that applications want to use. Operating systems as of today were not designed for such a future, and rather assume homogeneous hardware that remains in the same static configuration during its runtime. In this dissertation, we study how operating systems must change to handle dynamic hardware, where cores and other devices in the system can power on and off individually. Furthermore, we examine how operating systems can be made more adaptive to suit the needs of applications better or specialize themselves for the underlying hardware. First, we present Barrelfish/DC, which decouples physical cores from the OS, and the OS itself from application state. The resulting design allows the OS to treat all available cores in the system as fully dynamic. Next, we present Badis, an OS architecture that enables applications to execute on top of adapted OS kernels and services. We show that the flexibility to run specialized kernels helps applications by optimizing the OS for the workload requirements, but also allows the OS to optimize for the complexity and heterogeneity present in modern and future machines. Finally, we propose a mechanism that promotes virtual address spaces to first-class citizens, thus enabling a process to attach to, detach from, and switch between multiple virtual address spaces. The system enables applications to quickly and dynamically change their logical view of the memory system, and we show how this can increase performance considerably. Zusammenfassung Trends der Hardwareentwicklung zeigen, dass Computerarchitekturen in naher Zukunft beachtliche Veränderungen erfahren werden. Ein Grund dafür ist das Ende von Moore’s Law. Es bedeutet dass zukünftige CPUs nicht mehr einfach schneller oder komplexer werden indem man sich darauf verlässt immer kleinere und deswegen mehr Transistoren zur Verfügung zu haben. Stattdessen müssen Programme mehrere CPUs oder spezial- isierte Hardware verwenden um ihre Leistung zu verbessern. Ein weiterer Grund ist das Ende der Dennard Skalierung, was bedeutet dass mit kleiner werdenden Transistoren der Stromverbrauch nicht mehr nur von der eingenommenen Chipfläche abhängt. Die Auswirkung davon ist dass in Zukunft grosse Flächen eines Chips ausgeschaltet sein müssen, und die Systemsoftware dynamisch jene Hardware welche eine Applikation verwenden will einschalten muss. Heutige Betriebssysteme wurden entwickelt für homogene Hardware welche während ihrer Laufzeit in der gleichen, statischen Konfiguration bleibt. In dieser Dissertation studieren wir wie Betriebssysteme sich verändern müssen um mit dynamischer Hardware, in welcher CPUs oder andere Geräte individuell an und ausgeschaltet werden, umzugehen. Desweiteren analysieren wir wie Betriebssysteme anpassungsfähiger entwickelt werden können, um besser den Anforderungen von Applikationen gerecht zu werden oder um sich besser an die verwendete Hardware anzupassen. Zuerst präsentieren wir Barrelfish/DC, ein System welches physische CPUs von dem OS und das OS selber von dem Applikationsstate entkoppelt. Das resultierende Design erlaubt es dem OS alle CPU-Cores eines Systems als dynamisch zu behandeln. Als nächstes präsentieren wir Badis, eine OS Architektur welche es Applikationen erlaubt unter angepassten OS Kernels und Systemdiensten zu laufen. Wir zeigen wie diese Flexibilität hilft um die Anforderungen von Applikationen besser zu erfüllen, aber es zugleich auch erlaubt das OS zu optimieren für komplexe und heterogenen Hardware. Schlussendlich stellen wir einen Mechanismus vor welcher virtuelle Adressräume als Objekte erster Klasse behandelt und es Prozessen erlaubt diese zu erstellen, zu teilen, und zwischen ihnen zu wechseln. Der Mechanismus erlaubt Applikationen schnell und dynamisch ihre Sichtweise auf den verfügbaren Speicher zu wechseln, was wiederum verschiedene Leistungssteigerungen ermöglicht. Acknowledgments The work presented in this dissertation was shaped, created and described through collaboration and interactions with many wonderful and exceptional friends and col- leagues. First of all, I would like to express my gratitude to my advisor Timothy Roscoe for always believing in me, supporting me and mentoring me during my masters and doctoral studies. Your optimism and joyful approach to everything you do make it truly a pleasure to work with you. Likewise, I thank Gustavo Alonso for being a fantastic and encouraging co-advisor that always gave insightful advice on my research and this dissertation. Finally, thanks to you Jonathan for taking part in my committee and all the reassuring feedback that you have given me. During my studies and internships, I had the opportunity to collaborate with many incredibly smart and dedicated colleagues who directly and indirectly contributed to this dissertation: Adrian Schüpbach, Alexander Merritt, Besmira Nushi, Dejan Milojicic, Denny Lin, Gabriel Kliot, Izzat El Hajj, Jana Giceva, Kornilios Kourtis, Paolo Faraboschi, Reto Achermann, Simon Gerber and Wen-mei Hwu. A special thanks also goes to all the friends I have gained during my time in the Systems Group: Akhi, Andreas, Anja, Besmira, Claude, Darko, Georgios, Gitalee, Ingo, Lefteris, Lukas, Marco, Moritz, Nina, Pratanu, Pravin, Reto, Renato, Roni, Simon and Stefan. Our ski-trips, vacations, and events are unforgettable and made the last five years a pleasure to be part of the group. Finally, for all great things I have been able to do in life, I thank my parents Irène and Max and my brother Urs. They have been supportive like no one else and always encouraged me to do what I enjoy. Contents 1 Introduction 1 1.1 Problem statement . .3 1.2 Contributions . .4 1.3 Background: Barrelfish . .5 1.3.1 CPU Driver and Monitor . .6 1.3.2 Capabilities . .7 1.3.3 Scheduling . .8 1.3.4 Device management . .9 1.4 Evaluation methodology . .9 1.5 Overview . 10 2 Decoupling Cores, Kernels and Operating Systems 11 2.1 Motivation . 12 2.1.1 Hardware . 13 2.1.2 Software . 14 2.2 Related work . 15 2.2.1 CPU Hotplug . 15 2.2.2 Kernel updates . 16 2.2.3 Multikernels . 18 2.2.4 Virtualization . 19 2.3 Design and Implementation . 19 Contents 2.3.1 Booting a new core . 20 2.3.2 Per-core state . 21 2.3.3 Capabilities in Barrelfish/DC . 23 2.3.4 Kernel Control Blocks . 24 2.3.5 Replacing a kernel . 25 2.3.6 Kernel sharing and core shutdown . 26 2.3.7 Dealing with time . 26 2.3.8 Dealing with interrupts . 27 2.3.9 Application support . 28 2.3.10 Discussion . 29 2.4 Evaluation . 30 2.4.1 Core management operations . 31 2.4.2 Applications . 35 2.4.2.1 Ethernet driver . 35 2.4.2.2 Web server . 36 2.4.2.3 PostgreSQL . 36 2.5 Concluding remarks . 39 3 A Framework for an Adaptive OS Architecture 41 3.1 Motivation . 42 3.1.1 Use-case: Coordinated parallel data processing . 42 3.1.2 Use-case: Eliminating OS noise . 44 3.2 Related work . 46 3.2.1 Operating System customization . 46 3.2.2 High-performance computing . 47 3.2.3 Scheduling parallel workloads . 48 3.2.4 OS abstractions for parallel execution . 49 3.3 Customization Goals . 50 3.3.1 Run-to-completion execution . 50 viii Contents 3.3.2 Co-scheduling . 52 3.3.3 Spatial isolation of tasks and threads . 52 3.3.4 OS interfaces . 53 3.3.5 Data aware task placement . 54 3.4 Design and Implementation . 54 3.4.1 Control plane . 55 3.4.2 Compute plane . 57 3.4.3 Discussion . 59 3.5 Basslet: A kernel based, task-parallel runtime system . 59 3.5.1 Task-parallel compute plane kernel . 60 3.5.2 Compute plane configuration . 61 3.5.3 Basslet runtime libraries . 62 3.5.3.1 Porting pthreads to Basslet . 63 3.5.3.2 Porting OpenMP to Basslet . 63 3.5.4 Basslet code size . 65 3.6 bfrt: A real-time OS kernel . 65 3.7 Evaluation . 65 3.7.1 Basslet runtime . 66 3.7.1.1 Interference between a pair of parallel jobs . 66 3.7.1.2 System throughput scale-out . 68 3.7.1.3 Standalone runtime comparison . 70 3.7.2 Performance isolation with bfrt . 71 3.7.3 Badis OS architecture . 73 3.7.3.1 Control plane applications . 73 3.7.3.2 Overhead of Badis enqueuing . 74 3.8 Concluding remarks . 75 ix Contents 4 Using Multiple Address Spaces in Applications 77 4.1 Motivation . 79 4.1.1 Memory technology . 79 4.1.2 Preserving pointer-based data structures . 80 4.1.3 Large-scale sharing of memory . 80 4.1.4 Problems with legacy methods . 80 4.2 Related work . 82 4.2.1 Operating systems . 82 4.2.2 Memory management . 83 4.2.3 Communication and Sharing .
Recommended publications
  • Definition Process Scheduling Queues

    Definition Process Scheduling Queues

    Dear Students Due to the unprecedented situation, Knowledgeplus Training center is mobilized and will keep accompanying and supporting our students through this difficult time. Our Staff will be continuously, sending notes and exercises on a weekly basis through what’s app and email. Students are requested to copy the notes and do the exercises on their copybooks. The answers to the questions below will be made available on our website on knowledgeplus.mu/support.php. Please note that these are extra work and notes that we are providing our students and all classes will be replaced during the winter vacation. We thank you for your trust and are convinced that, together, we will overcome these troubled times Operating System - Process Scheduling Definition The process scheduling is the activity of the process manager that handles the removal of the running process from the CPU and the selection of another process on the basis of a particular strategy. Process scheduling is an essential part of a Multiprogramming operating systems. Such operating systems allow more than one process to be loaded into the executable memory at a time and the loaded process shares the CPU using time multiplexing. Process Scheduling Queues The OS maintains all PCBs in Process Scheduling Queues. The OS maintains a separate queue for each of the process states and PCBs of all processes in the same execution state are placed in the same queue. When the state of a process is changed, its PCB is unlinked from its current queue and moved to its new state queue. The Operating System maintains the following important process scheduling queues − • Job queue − This queue keeps all the processes in the system.
  • Intra-Unikernel Isolation with Intel Memory Protection Keys

    Intra-Unikernel Isolation with Intel Memory Protection Keys

    Intra-Unikernel Isolation with Intel Memory Protection Keys Mincheol Sung Pierre Olivier∗ Virginia Tech, USA The University of Manchester, United Kingdom [email protected] [email protected] Stefan Lankes Binoy Ravindran RWTH Aachen University, Germany Virginia Tech, USA [email protected] [email protected] Abstract ACM Reference Format: Mincheol Sung, Pierre Olivier, Stefan Lankes, and Binoy Ravin- Unikernels are minimal, single-purpose virtual machines. dran. 2020. Intra-Unikernel Isolation with Intel Memory Protec- This new operating system model promises numerous bene- tion Keys. In 16th ACM SIGPLAN/SIGOPS International Conference fits within many application domains in terms of lightweight- on Virtual Execution Environments (VEE ’20), March 17, 2020, Lau- ness, performance, and security. Although the isolation be- sanne, Switzerland. ACM, New York, NY, USA, 14 pages. https: tween unikernels is generally recognized as strong, there //doi.org/10.1145/3381052.3381326 is no isolation within a unikernel itself. This is due to the use of a single, unprotected address space, a basic principle 1 Introduction of unikernels that provide their lightweightness and perfor- Unikernels have gained attention in the academic research mance benefits. In this paper, we propose a new design that community, offering multiple benefits in terms of improved brings memory isolation inside a unikernel instance while performance, increased security, reduced costs, etc. As a keeping a single address space. We leverage Intel’s Memory result,
  • A Linux in Unikernel Clothing Lupine

    A Linux in Unikernel Clothing Lupine

    A Linux in Unikernel Clothing Hsuan-Chi Kuo+, Dan Williams*, Ricardo Koller* and Sibin Mohan+ +University of Illinois at Urbana-Champaign *IBM Research Lupine Unikernels are great BUT: Unikernels lack full Linux Support App ● Hermitux: supports only 97 system calls Kernel LibOS + App ● OSv: ○ Fork() , execve() are not supported Hypervisor Hypervisor ○ Special files are not supported such as /proc ○ Signal mechanism is not complete ● Small kernel size ● Rumprun: only 37 curated applications ● Heavy ● Fast boot time ● Community is too small to keep it rolling ● Inefficient ● Improved performance ● Better security 2 Can Linux behave like a unikernel? 3 Lupine Linux 4 Lupine Linux ● Kernel mode Linux (KML) ○ Enables normal user process to run in kernel mode ○ Processes can still use system services such as paging and scheduling ○ App calls kernel routines directly without privilege transition costs ● Minimal patch to libc ○ Replace syscall instruction to call ○ The address of the called function is exported by the patched KML kernel using the vsyscall ○ No application changes/recompilation required 5 Boot time Evaluation Metrics Image size Based on: Unikernel benefits Memory footprint Application performance Syscall overhead 6 Configuration diversity ● 20 top apps on Docker hub (83% of all downloads) ● Only 19 configuration options required to run all 20 applications: lupine-general 7 Evaluation - Comparison configurations Lupine Cloud Operating Systems [Lupine-base + app-specific options] OSv general Linux-based Unikernels Kernel for 20 apps
  • Unikernel Monitors: Extending Minimalism Outside of the Box

    Unikernel Monitors: Extending Minimalism Outside of the Box

    Unikernel Monitors: Extending Minimalism Outside of the Box Dan Williams Ricardo Koller IBM T.J. Watson Research Center Abstract Recently, unikernels have emerged as an exploration of minimalist software stacks to improve the security of ap- plications in the cloud. In this paper, we propose ex- tending the notion of minimalism beyond an individual virtual machine to include the underlying monitor and the interface it exposes. We propose unikernel monitors. Each unikernel is bundled with a tiny, specialized mon- itor that only contains what the unikernel needs both in terms of interface and implementation. Unikernel mon- itors improve isolation through minimal interfaces, re- Figure 1: The unit of execution in the cloud as (a) a duce complexity, and boot unikernels quickly. Our ini- unikernel, built from only what it needs, running on a tial prototype, ukvm, is less than 5% the code size of a VM abstraction; or (b) a unikernel running on a spe- traditional monitor, and boots MirageOS unikernels in as cialized unikernel monitor implementing only what the little as 10ms (8× faster than a traditional monitor). unikernel needs. 1 Introduction the application (unikernel) and the rest of the system, as defined by the virtual hardware abstraction, minimal? Minimal software stacks are changing the way we think Can application dependencies be tracked through the in- about assembling applications for the cloud. A minimal terface and even define a minimal virtual machine mon- amount of software implies a reduced attack surface and itor (or in this case a unikernel monitor) for the applica- a better understanding of the system, leading to increased tion, thus producing a maximally isolated, minimal exe- security.
  • Assessing Unikernel Security April 2, 2019 – Version 1.0

    Assessing Unikernel Security April 2, 2019 – Version 1.0

    NCC Group Whitepaper Assessing Unikernel Security April 2, 2019 – Version 1.0 Prepared by Spencer Michaels Jeff Dileo Abstract Unikernels are small, specialized, single-address-space machine images constructed by treating component applications and drivers like libraries and compiling them, along with a kernel and a thin OS layer, into a single binary blob. Proponents of unikernels claim that their smaller codebase and lack of excess services make them more efficient and secure than full-OS virtual machines and containers. We surveyed two major unikernels, Rumprun and IncludeOS, and found that this was decidedly not the case: unikernels, which in many ways resemble embedded systems, appear to have a similarly minimal level of security. Features like ASLR, W^X, stack canaries, heap integrity checks and more are either completely absent or seriously flawed. If an application running on such a system contains a memory corruption vulnerability, it is often possible for attackers to gain code execution, even in cases where the applica- tion’s source and binary are unknown. Furthermore, because the application and the kernel run together as a single process, an attacker who compromises a unikernel can immediately exploit functionality that would require privilege escalation on a regular OS, e.g. arbitrary packet I/O. We demonstrate such attacks on both Rumprun and IncludeOS unikernels, and recommend measures to mitigate them. Table of Contents 1 Introduction to Unikernels . 4 2 Threat Model Considerations . 5 2.1 Unikernel Capabilities ................................................................ 5 2.2 Unikernels Versus Containers .......................................................... 5 3 Hypothesis . 6 4 Testing Methodology . 7 4.1 ASLR ................................................................................ 7 4.2 Page Protections ....................................................................
  • “A Linux in Unikernel Clothing”

    “A Linux in Unikernel Clothing”

    Lupine Linux “A Linux in Unikernel Clothing” Dan Williams (IBM) With Hsuan-Chi (Austin) Kuo (UIUC + IBM), Ricardo Koller (IBM), Sibin Mohan (UIUC) Roadmap • Context • Containers and isolation • Unikernels • Nabla containers • Lupine Linux • A linux in unikernel clothing • Concluding thoughts 2 Containers are great! • Have changed how applications are packaged, deployed and developed • Normal processes, but “contained” • Namespaces, cgroups, chroot • Lightweight • Start quickly, “bare metal” • Easy image management (layered fs) • Tooling/orchestration ecosystem 3 But… High level of • Large attack surface to the host abstraction (e.g., system • Limits adoption of container-first architecture calls) app • Fortunately, we know how to reduce attack surface! Host Kernel with namespacing (e.g., Linux) Containers 4 Deprivileging and unsharing kernel functionality Low level of High level of • Virtual machines (VMs) abstraction abstraction • Guest kernel (e.g., virtual (e.g., system app hardware) calls) • Thin interface Guest Kernel app (e.g., Linux) Monitor Process (e.g., QEMU) Host Kernel with Host Kernel/Hypervisor namespacing (e.g., Linux/KVM) (e.g., Linux) VMs Containers 5 Deprivileging and unsharing kernel functionality Low level of High level of • Virtual machines (VMs) abstraction abstraction • Guest kernel (e.g., virtual (e.g., system app hardware) calls) • Thin interface • Userspace kernel Guest Kernel app • Performance issues (e.g., Linux) Monitor Process (e.g., QEMU) Host Kernel with Host Kernel/Hypervisor namespacing (e.g., Linux/KVM)
  • Scheduling Algorithm for Grid Computing Using Shortest Job First with Time Quantum

    Scheduling Algorithm for Grid Computing Using Shortest Job First with Time Quantum

    Sudan University of Science and Technology Collage of Graduate Studies College of Engineering Scheduling Algorithm for Grid Computing using Shortest Job First with Time Quantum خوارزمية الجدولة للحوسبة الشبكية بإستخدام العمليات اﻷقصر أوﻻ مع الزمن الكمي A thesis submitted in partial fulfillment of the requirements for the degree of M.SC.in computer and networks engineering By: Raham Hashim Yosuf Supervised by: Dr. Rania A. Mokhtar August 2017 Initiation اﻷية قال هللا تعالى: {أَ َّم ْن ُه َو َقانِ ٌت آنَا َء اللَّ ْي ِل َسا ِجدًا َو َقائِ ًما َي ْحذَ ُر ا ْْل ِخ َرةَ َويَ ْر ُجو َر ْح َمةَ َربِ ِه قُ ْل َه ْل يَ ْستَ ِوي الَّ ِذي َن يَ ْع َل ُمو َن َوالَّ ِذي َن َﻻ َي ْع َل ُمو َن إِنَّ َما يَتَذَ َّك ُر أُولُو ا ْﻷَْلبَا ِب } صدق هللا العظيم سورة الزمر اْلية )9( I Dedication Dedicated to My parents, my sisters And to my friends To everyone who tried to guide me to A better life….. With my love II Acknowledgement My thanks for Allah After that I would like to thanks my university Sudan University of science and Technology and my college of Graduate Studies Electronics Engineering Department. And my teachers for inspiring me this project. I owe my profound gratitude to my thesis supervisor Dr. Rania A.Mokhtar for her valuable guidance, supervision and persistent encouragement. Due to the approach adopted by her in handling my thesis and the way she gave me freedom to think about different things, I was able to do the constructive thesis.
  • Comprehensive Examinations in Computer Science 1872 - 1878

    Comprehensive Examinations in Computer Science 1872 - 1878

    COMPREHENSIVE EXAMINATIONS IN COMPUTER SCIENCE 1872 - 1878 edited by Frank M. Liang STAN-CS-78-677 NOVEMBER 1078 (second Printing, August 1979) COMPUTER SCIENCE DEPARTMENT School of Humanities and Sciences STANFORD UNIVERSITY COMPUTER SC l ENCE COMPREHENSIVE EXAMINATIONS 1972 - 1978 b Y the faculty and students of the Stanford University Computer Science Department edited by Frank M. Liang Abstract Since Spring 1972, the Stanford Computer Science Department has periodically given a "comprehensive examination" as one of the qualifying exams for graduate students. Such exams generally have consisted of a six-hour written test followed by a several-day programming problem. Their intent is to make it possible to assess whether a student is sufficiently prepared in all the important aspects of computer science. This report presents the examination questions from thirteen comprehensive examinations, along with their solutions. The preparation of this report has been supported in part by NSF grant MCS 77-23738 and in part by IBM Corporation. Foreword This report probably contains as much concentrated computer science per page as any document In existence - it is the result of thousands of person-hours of creative work by the entire staff of Stanford's Computer Science Department, together with dozens of h~ghly-talented students who also helped to compose the questions. Many of these questions have never before been published. Thus I think every person interested in computer science will find it stimulating and helpful to study these pages. Of course, the material is so concentrated it is best not taken in one gulp; perhaps the wisest policy would be to keep a copy on hand in the bathroom at all times, for those occasional moments when inspirational reading is desirable.
  • Jails and Unikernels

    Jails and Unikernels

    Virtualisation: Jails and Unikernels Advanced Operating Systems Lecture 18 Colin Perkins | https://csperkins.org/ | Copyright © 2017 | This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Lecture Outline • Alternatives to full virtualisation • Sandboxing processes: • FreeBSD jails and Linux containers • Container management • Unikernels and library operating systems Colin Perkins | https://csperkins.org/ | Copyright © 2017 2 Alternatives to Full Virtualisation • Full operating system virtualisation is expensive • Need to run a hypervisor • Need to run a complete guest operating system instance for each VM • High memory and storage overhead, high CPU load from running multiple OS instances on a single machine – but excellent isolation between VMs • Running multiple services on a single OS instance can offer insufficient isolation • All must share the same OS • A bug in a privileged service can easily compromise entire system – all services running on the host, and any unrelated data • A sandbox is desirable – to isolate multiple services running on a single operating system Colin Perkins | https://csperkins.org/ | Copyright © 2017 3 Sandboxing: Jails and Containers • Concept – lightweight virtualisation • A single operating system kernel • Multiple services /bin • Each service runs within a jail a service specific container, running just what’s needed /bin /dev for that application /dev /etc /etc /mail /home /home /jail /www /lib • Jail restricted to see only a subset of the / /lib /local /usr filesystem and processes of the host /usr /lib /sbin • A sandbox within the operating system /sbin /sbin /tmp /tmp /share /var • Partially virtualised /var Colin Perkins | https://csperkins.org/ | Copyright © 2017 4 Example: FreeBSD Jail subsystem Jails: Confining the omnipotent root.
  • State Spill in Modern Operating Systems

    State Spill in Modern Operating Systems

    A Characterization of State Spill in Modern Operating Systems Kevin Boos, Emilio Del Vecchio, and Lin Zhong Rice University fkevinaboos, edd5, [email protected] Abstract states change and propagate throughout the system, showing that modularity is necessary but insufficient. For example, Understanding and managing the propagation of states in several process migration works have cited “residual depen- operating systems has become an intractable problem due dencies” that remain on the source system as an obstacle to to their sheer size and complexity. Despite modularization post-migration correctness on the target system [38, 55, 34]. efforts, it remains a significant barrier to many contemporary Fault isolation and fault tolerance literature has long realized computing goals: process migration, fault isolation and the undesirable effects of fate sharing among software mod- tolerance, live update, software virtualization, and more. ules as well as the difficulty of restoring a process or whole Though many previous OS research endeavors have achieved machine statefully after a failure, due to the sprawl of states these goals through ad-hoc, tedious methods, we argue that spread among different system components [28, 26, 52, 51]. they have missed the underlying reason why these goals are Live update and hot-swapping research has long sought to overcome the state maintenance issues and inter-module de- so challenging: state spill. pendencies that plague their implementations when transi- State spill occurs when a software entity’s state undergoes tioning from an old to a new version, forcing developers to lasting changes as a result of a transaction from another entity. write complex state transfer functions [7, 25, 27, 48, 5].
  • Organisasi Komputer

    Organisasi Komputer

    STMIK JAKARTA STI&K ORGANISASI KOMPUTER BUKU AJAR Aqwam Rosadi Kardian. 2009 ORGANISASI KOMPUTER 2009 BUKU AJAR ORGANISASI KOMPUTER STMIK JAKARTA STI&K 2009 Organisasi Komputer - Aqwam Rosadi Kardian. Hal- 2 ORGANISASI KOMPUTER 2009 EVOLUSI ABAD INFORMASI DAN SEJARAH KOMPUTER I. EVOLUSI ABAD INFORMASI A. ASPEK ABAD PERTANIAN Periode < 1800 Pekerja Petani Perpaduan Manusia & tanah Peralatan Tangan B. ASPEK ABAD INDUSTRI Periode 1800 – 1957 Pekerja Pegawai pabrik Perpaduan Manusia & mesin Peralatan Mesin C. ASPEK ABAD INFORMASI Periode 1957 – sekarang Pekerja Pekerja terdidik Perpaduan Manusia & manusia Peralatan Teknologi Informasi D. MASYARAKAT INFORMASI suatu masyarakat dimana lebih banyak orang bekerja dalam bidang penanganan informasi dari pada bidang pertanian dan industri. E. KARAKTERISTIK ABAD INFORMASI Munculnya masyarakat berbasis informasi Bisnis tergantung pada TI Adanya transformasi proses kerja Re-engineers proses bisnis yang konvensional Keberhasilannya bergantung pada efektivitas pemanfaatannya. TI melekat pada banyak produk & pelayanan Organisasi Komputer - Aqwam Rosadi Kardian. Hal- 3 ORGANISASI KOMPUTER 2009 F. DEFINISI TEKNOLOGI INFORMASI Teknologi Informasi suatu istilah yang menunjukkan berbagai macam hal dan kemampuan yang digunakan dalam pembentukan, penyimpanan, dan penyebaran informasi. TI mencakup : Komputer Jaringan Komunikasi Consumer Electronics ‘Know-How’ F.1. KOMPUTER Komputer suatu sistem elektronik yang dapat di-program (di-instruksi) untuk menerima, memproses, menyimpan dan menyajikan data dan informasi Sejarah Singkat Komputer A. Sejarah perkembangan komputer dari tahun sebelum masehi antara lain : Tahun 3000 SM, bilangan mulai dipakai. Tahun 2600 SM, dikembangakan suatu alat bantu untuk menghitung yaitu “ABACUS”. Tahun 1642 BLAISE PASCAL berhasil membuat alat hitung mekanik yang dapat melaksanakan penambahan dan pengurangan sampai bilangan terdiri dari 6 angka. Tahun 1694 GOTFRIED WILHELM LEIBITZ berhasil menemukan mesin yang dapat mengendalikan.
  • In the Context of the CS3551 Spire Class Project

    In the Context of the CS3551 Spire Class Project

    Unikernels: Library Operating Systems for the Cloud Anil Madhavapeddy, Richard Mortier, Charalampos Rotsos, David Scott, Balraj Singh, Thomas Gazagnaire, Steven Smith, Steven Hand and Jon Crowcroft ASPLOS’13 In The Context of the CS3551 Spire Class Project Brad Whitehead and Mike Boby February 25, 2020 Teaching Moment - What is a Unikernel? To answer that question, we have to take a look at the structure of a modern operating system Doesn’t matter if it’s Microsoft Windows, Linux, UNIX, Mac OS X OS X macOS, etc. All the mainstream operating systems have the same fundamental anatomy The Anatomy of an Operating System “The Kernel” Runs in Special Hardware Mode “Userland” – “Ring 0” Where Applications Run Only Program That Can Access or Allocate Resources No Privileges Copies Data Between Can Not Access Resources Programs Can Not “Talk” to Other Programs Growth of Operating Systems Linux Kernel is now 28 million lines of source code! Windows is estimated at 50 million lines of code!! With an industry average of 15-50 defects per 1000 lines of code*: Linux (Just the kernel) = 420 thousand to 1.4 million defects Windows = 750 thousand to 2.5 million defects * Steve McConnel, “Code Complete 2”, 2005 It Gets Worse The “Userland” support software is often 10 to 20 times larger than the kernel Red Hat Enterprise Linux (RHEL) Userland is approximately 420 million lines of code Try not to think about the 6.7 to 22 million defects running on the SCADA server controlling your power grid and drinking water Can It Get Even Worse?