DOCSLIB.ORG

Operating System Support for Parallel Processes by Barret Joseph

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Operating System Support for Parallel Processes by Barret Joseph Operating System Support for Parallel Processes by Barret Joseph Rhoden A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Eric Brewer, Chair Professor Krste Asanovi´c Professor David Culler Professor John Chuang Fall 2014 Operating System Support for Parallel Processes Copyright 2014 by Barret Joseph Rhoden 1 Abstract Operating System Support for Parallel Processes by Barret Joseph Rhoden Doctor of Philosophy in Computer Science University of California, Berkeley Professor Eric Brewer, Chair High-performance, parallel programs want uninterrupted access to physical resources. This characterization is true not only for traditional scientific computing, but also for high- priority data center applications that run on parallel processors. These applications require high, predictable performance and low latency, and they are important enough to warrant engineering effort at all levels of the software stack. Given the recent resurgence of interest in parallel computing as well as the increasing importance of data center applications, what changes can we make to operating system abstractions to support parallel programs? Akaros is a research operating system designed for single-node, large-scale SMP and many-core architectures. The primary feature of Akaros is a new process abstraction called the \Many-Core Process" (MCP) that embodies transparency, application control of physical resources, and performance isolation. The MCP is built on the idea of separating cores from threads: the operating system grants spatially partitioned cores to the MCP, and the application schedules its threads on those cores. Data centers typically have a mix of high- priority applications and background batch jobs, where the demands of the high-priority application can change over time. For this reason, an important part of Akaros is the provisioning, allocation, and preemption of resources, and the MCP must be able to handle having a resource revoked at any moment. In this work, I describe the MCP abstraction and the salient details of Akaros. I discuss how the kernel and user-level libraries work together to give an application control over its physical resources and to adapt to the revocation of cores at any time | even when the code is holding locks. I show an order of magnitude less interference for the MCP compared to Linux, more resilience to the loss of cores for an HPC application, and how a customized user-level scheduler can increase the performance of a simple webserver. i Contents Contents i List of Figures iii List of Tables v 1 Introduction 1 2 Background on Operating Systems 4 2.1 System Calls . 4 2.2 Threads, Concurrency, and Parallelism . 7 2.3 Scheduling and Competition . 20 2.4 Synchronization . 27 2.5 Performance Isolation . 30 3 The Basics of the Many-Core Process and Akaros 34 3.1 MCP Basics . 34 3.2 Akaros Details . 36 4 Life for a Many-Core Process 48 4.1 Procinfo and Procdata . 48 4.2 Virtual Cores . 49 4.3 MCPs from Creation to Entry . 52 4.4 User-level Scheduling . 57 4.5 Impact of Dedicated Cores . 70 5 Event Delivery 88 5.1 Concurrent Queues for Payloads . 89 5.2 The Event Delivery Subsystem . 100 5.3 Never Miss an Important Event . 108 6 Virtual Core Preemption 116 6.1 Preemption Basics . 118 ii 6.2 Preemption Detection and Recovery Locks . 123 6.3 Handling Preemption . 141 7 Applications 149 7.1 Fluidanimate . 149 7.2 Webserver . 151 8 Conclusion 160 Bibliography 162 iii List of Figures 4.1 FTQ Raw Output, c89, Linux, Core 7 . 71 4.2 FFT @ 3000 Hz, c89, Linux, Core 7 . 72 4.3 FFT @ 500 Hz, c89, Linux, Core 7 . 72 4.4 FFT @ 100 Hz, c89, Linux, Core 7 . 73 4.5 FFT @ 100 Hz, c89, Old Akaros, Core 7 . 74 4.6 FFT @ 100 Hz, c89, Akaros, Core 7 . 75 4.7 FFT @ 500 Hz, c89, Akaros, Core 7 . 75 4.8 FFT @ 3000 Hz, c89, Akaros, Core 7 . 76 4.9 FFT @ 3000 Hz, c89, Linux, Core 31 . 77 4.10 FFT @ 3000 Hz, c89, Akaros, Core 31 . 77 4.11 FFT @ 500 Hz, c89, Linux, Core 31 . 78 4.12 FFT @ 500 Hz, c89, Akaros, Core 31 . 78 4.13 FFT @ 100 Hz, c89, Linux, Core 31 . 79 4.14 FFT @ 100 Hz, c89, Akaros, Core 31 . 79 4.15 FTQ Raw Data, c89, Akaros, Core 7 . 80 4.16 FTQ Raw Data, c89, Akaros, Core 31 . 81 4.17 FFT @ 3000 Hz, hossin, Linux, Core 7 . 82 4.18 FFT @ 3000 Hz, hossin, Akaros, Core 7 . 82 4.19 FFT @ 500 Hz, hossin, Linux, Core 7 . 83 4.20 FFT @ 500 Hz, hossin, Akaros, Core 7 . 83 4.21 FFT @ 100 Hz, hossin, Linux, Core 7 . 84 4.22 FFT @ 100 Hz, hossin, Akaros, Core 7 . 84 4.23 FTQ Raw Data, hossin, Akaros, Core 7 . 85 4.24 FTQ Raw Data, hossin, Linux, Core 7 . 86 6.1 Akaros Spinlocks, 4 Threads, Acquisition Latency . 135 6.2 Linux Spinlocks, 31 Threads, Acquisition Times . 135 6.3 MCS locks, 31 Threads, Acquisition Times . 137 6.4 Akaros, Basic MCS locks, 31 Threads, Lock Throughput . 138 6.5 Akaros, MCS-PDRO locks, 31 Threads, Lock Throughput . 138 6.6 Akaros, MCS-PDRN locks, 31 Threads, Lock Throughput . 139 iv 7.1 Fluidanimate, Akaros, 64 Threads, 31 Cores . 151 7.2 Fluidanimate Performance on Akaros and Linux with Preemption . 152 7.3 Fluidanimate Relative Performance on Akaros and Linux with Preemption . 152 7.4 Akaros Kweb, Custom-2LS, Throughput vs. Workers . 156 7.5 Kweb and Fluidanimate Throughput with Preemption . 158 v List of Tables 4.1 Average Thread Context-Switch Latency (nsec) . 68 4.2 Akaros Context-Switch Latency (nsec) . 69 6.1 Spinlock Acquisition Latency (in ticks) . 134 6.2 MCS Lock Acquisition Latency (in ticks) . 136 7.1 Fluidanimate Runtime (seconds) . 150 7.2 Kweb Throughput, 100 connections of 100,000 calls each . 154 vi Acknowledgments I have been extremely fortunate over the past seven years. Not only did I have the oppor- tunity to pursue a project I found interesting, but I did so while working with excellent people. Both my research opportunity and the group environment are the product of my advisor: Eric Brewer. I would like to thank Eric for his inspiration and guidance | especially his implicit guidance as a role model. Although research is important, it is less important than a work-life balance and being \safe in your own skin." Eric gave me the breathing room necessary to work on Akaros and allowed me to \do the right thing," even if it took longer. I would also like to thank my committee, especially David Culler, for providing a much- needed historical perspective for my work. Additionally, David Wessel's music application was the original inspiration for the separation of provisioning and allocation in Akaros. The bulk of my time was spent with other graduate students and developers, and my work would not have been possible without them. Kevin Klues has been my partner in crime for a number of years now. It's hard to believe that the end of our era in Berkeley is finally here. David Zhu and I have had discussions since our first semester here together. Andrew Waterman is an impressive coder who tends to know what I am thinking before I say it. Paul Pearce developed Akaros's initial network drivers, and Andrew Gallatin vastly improved the more recent Plan 9 network stack. I would be lucky to work with any of them in the future. Ron Minnich and I met in 2009, but we did not work together until our serendipitous pairing as host and intern at Google in 2013. He was instrumental both in porting the guts of Plan 9 to Akaros and in using FTQ. Ron breathed new life into Akaros, greatly increasing its chances of having a life beyond graduate school. More importantly, Ron is the real deal | authentic and generous, and I hope to be more like him. My family has been very supportive over the years. They have always provided a home in Pittsburgh, complete with nieces and nephews, for whenever I was in town and needed to relax. Finally, I would like to thank my wife, Tamara Broderick. Not only did she help with FTQ and R, but she has been my biggest supporter. Whether it was coining the name \Akaros" or designing giraffe-themed merchandise, she has always been there for me, and I look forward to returning the favor. 1 Chapter 1 Introduction There are limitations to what we can do with computers. System designers make trade-offs, and over time certain designs should be reevaluated | especially when there is a change in the landscape of computing. One such change is the resurgence of interest in parallel computing due to the industry's failure to increase uniprocessor performance[5]. Given this environment, what changes can we make to operating systems to support parallel programs? Researchers and engineers have pursued parallel computing for decades. The existence of parallel computers is not new, although their ubiquity is on the rise. Another trend in computing is the creation of large-scale clusters of computers in data centers. The largest parallel machines are likely to be found in data centers. Any work on parallel computing ought to address data centers and their workloads, as well as the more traditional concerns of parallel applications. Typically, high-performance, parallel programs are tuned and want uninterrupted access to resources; after all, the purpose of parallelism is to speed up an application.
Load more

Recommended publications
  • Openvms Record Management Services Reference Manual
    OpenVMS Record Management Services Reference Manual Order Number: AA-PV6RD-TK April 2001 This reference manual contains general information intended for use in any OpenVMS programming language, as well as specific information on writing programs that use OpenVMS Record Management Services (OpenVMS RMS). Revision/Update Information: This manual supersedes the OpenVMS Record Management Services Reference Manual, OpenVMS Alpha Version 7.2 and OpenVMS VAX Version 7.2 Software Version: OpenVMS Alpha Version 7.3 OpenVMS VAX Version 7.3 Compaq Computer Corporation Houston, Texas © 2001 Compaq Computer Corporation Compaq, AlphaServer, VAX, VMS, the Compaq logo Registered in U.S. Patent and Trademark Office. Alpha, PATHWORKS, DECnet, DEC, and OpenVMS are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX and X/Open are trademarks of The Open Group in the United States and other countries. All other product names mentioned herein may be the trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
    [Show full text]
  • Software Product Description and Quickspecs
    VSI OpenVMS Alpha Version 8.4-2L2 Operating System DO-DVASPQ-01A Software Product Description and QuickSpecs PRODUCT NAME: VSI OpenVMS Alpha Version 8.4-2L2 DO-DVASPQ-01A This SPD and QuickSpecs describes the VSI OpenVMS Alpha Performance Release Operating System software, Version 8.4-2L2 (hereafter referred to as VSI OpenVMS Alpha V8.4-2L2). DESCRIPTION OpenVMS is a general purpose, multiuser operating system that runs in both production and development environments. VSI OpenVMS Alpha Version 8.4-2L2 is the latest release of the OpenVMS Alpha computing environment by VMS Software, Inc (VSI). VSI OpenVMS Alpha V8.4-2L2 is compiled to take advantage of architectural features such as byte and word memory reference instructions, and floating-point improvements, which are available only in HPE AlphaServer EV6 or later processors. This optimized release improves performance by taking advantage of faster hardware-based instructions that were previously emulated in software. NOTE: VSI OpenVMS Alpha V8.4-2L2 does not work on, and is not supported on, HPE AlphaServer pre-EV6 systems. OpenVMS Alpha supports HPE’s AlphaServer series computers. OpenVMS software supports industry standards, facilitating application portability and interoperability. OpenVMS provides symmetric multiprocessing (SMP) support for multiprocessing systems. The OpenVMS operating system can be tuned to perform well in a wide variety of environments. This includes combinations of compute-intensive, I/O-intensive, client/server, real-time, and other environments. Actual system performance depends on the type of computer, available physical memory, and the number and type of active disk and tape drives. The OpenVMS operating system has well-integrated networking, distributed computing, client/server, windowing, multi-processing, and authentication capabilities.
    [Show full text]
  • Operating System Support for Parallel Processes
    Operating System Support for Parallel Processes Barret Rhoden Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2014-223 http://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-223.html December 18, 2014 Copyright © 2014, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Operating System Support for Parallel Processes by Barret Joseph Rhoden A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Science in the Graduate Division of the University of California, Berkeley Committee in charge: Professor Eric Brewer, Chair Professor Krste Asanovi´c Professor David Culler Professor John Chuang Fall 2014 Operating System Support for Parallel Processes Copyright 2014 by Barret Joseph Rhoden 1 Abstract Operating System Support for Parallel Processes by Barret Joseph Rhoden Doctor of Philosophy in Computer Science University of California, Berkeley Professor Eric Brewer, Chair High-performance, parallel programs want uninterrupted access to physical resources. This characterization is true not only for traditional scientific computing, but also for high- priority data center applications that run on parallel processors. These applications require high, predictable performance and low latency, and they are important enough to warrant engineering effort at all levels of the software stack.
    [Show full text]
  • Sched-ITS: an Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course
    Wright State University CORE Scholar Browse all Theses and Dissertations Theses and Dissertations 2017 Sched-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course Bharath Kumar Koya Wright State University Follow this and additional works at: https://corescholar.libraries.wright.edu/etd_all Part of the Computer Engineering Commons, and the Computer Sciences Commons Repository Citation Koya, Bharath Kumar, "Sched-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating Systems Course" (2017). Browse all Theses and Dissertations. 1745. https://corescholar.libraries.wright.edu/etd_all/1745 This Thesis is brought to you for free and open access by the Theses and Dissertations at CORE Scholar. It has been accepted for inclusion in Browse all Theses and Dissertations by an authorized administrator of CORE Scholar. For more information, please contact [email protected]. SCHED – ITS: AN INTERACTIVE TUTORING SYSTEM TO TEACH CPU SCHEDULING CONCEPTS IN AN OPERATING SYSTEMS COURSE A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science By BHARATH KUMAR KOYA B.E, Andhra University, India, 2015 2017 Wright State University WRIGHT STATE UNIVERSITY GRADUATE SCHOOL April 24, 2017 I HEREBY RECOMMEND THAT THE THESIS PREPARED UNDER MY SUPERVISION BY Bharath Kumar Koya ENTITLED SCHED-ITS: An Interactive Tutoring System to Teach CPU Scheduling Concepts in an Operating System Course BE ACCEPTED IN PARTIAL FULFILLMENT OF THE REQIREMENTS FOR THE DEGREE OF Master of Science. _____________________________________ Adam R. Bryant, Ph.D. Thesis Director _____________________________________ Mateen M. Rizki, Ph.D. Chair, Department of Computer Science and Engineering Committee on Final Examination _____________________________________ Adam R.
    [Show full text]
  • Scheduling: Introduction
    7 Scheduling: Introduction By now low-level mechanisms of running processes (e.g., context switch- ing) should be clear; if they are not, go back a chapter or two, and read the description of how that stuff works again. However, we have yet to un- derstand the high-level policies that an OS scheduler employs. We will now do just that, presenting a series of scheduling policies (sometimes called disciplines) that various smart and hard-working people have de- veloped over the years. The origins of scheduling, in fact, predate computer systems; early approaches were taken from the field of operations management and ap- plied to computers. This reality should be no surprise: assembly lines and many other human endeavors also require scheduling, and many of the same concerns exist therein, including a laser-like desire for efficiency. And thus, our problem: THE CRUX: HOW TO DEVELOP SCHEDULING POLICY How should we develop a basic framework for thinking about scheduling policies? What are the key assumptions? What metrics are important? What basic approaches have been used in the earliest of com- puter systems? 7.1 Workload Assumptions Before getting into the range of possible policies, let us first make a number of simplifying assumptions about the processes running in the system, sometimes collectively called the workload. Determining the workload is a critical part of building policies, and the more you know about workload, the more fine-tuned your policy can be. The workload assumptions we make here are mostly unrealistic, but that is alright (for now), because we will relax them as we go, and even- tually develop what we will refer to as ..
    [Show full text]
  • Systemprogrammierung Grundlage Von Betriebssystemen
    Systemprogrammierung Grundlage von Betriebssystemen Sachwortverzeichnis c Wolfgang Schr¨oder-Preikschat 27. Januar 2017 Die in der Vorlesung (mundlich¨ oder schriftlich) verwendeten Akronyme und Sachworte sind in der nachfolgenden Aufz¨ahlung zusammengefasst. Dabei werden die Akronyme nach den Sachwor- ten, fur¨ die sie die Verkurzung¨ bilden, aufgeschlusselt.¨ Fur¨ englischsprachige Sachw¨orter werden, soweit bekannt, die deutschsprachigen Entsprechungen angegeben. In der Beschreibung durch das "-Zeichen angefuhrte¨ Sachw¨orter zeigen einen Kreuzverweis an. Jedes Sachwort wird erkl¨art, wo- bei dies im Zusammenhang mit dem hier relevanten Kontext der "Systemprogrammierung und in Bezug auf Betriebssysteme geschieht. Die Formulierungen erheben nicht den Anspruch auf Gultigkeit¨ auch fur¨ andere Fachrichtungen in der Informatik. Ebenso erhebt die Aufz¨ahlung nicht den Anspruch auf Vollst¨andigkeit fur¨ das in der Vorlesung behandelte Fachgebiet. Der vorliegende Text ist ein Nachschlagewerk, dessen Lekture,¨ im Gegensatz zu einem Lehr- buch mit durchgehendem roten Faden, fur¨ gew¨ohnlich nicht von vorne nach hinten empfohlen ist. Vielmehr ist der Text Begleitmaterial zu den Vorlesungsfolien. Neben Systemprogrammierung sind hier insbesondere die Lehrveranstaltungen Betriebssysteme, Betriebssystemtechnik, Nebenl¨aufige Systeme und Echtzeitsysteme eingeschlossen. Daruber¨ hinaus kommen aber auch Lehrveranstal- tungen zu den Themen Rechnerorganisation und Rechnerarchitektur als Bezugspunkt in Frage. Viele der dort (mundlich¨ oder schriftlich)
    [Show full text]
  • Proceedings, ITC/USA
    THE EFFICIENT USE OF A VAX COMPUTER IN THE REAL-TIME TELEMETRY ENVIRONMENT Item Type text; Proceedings Authors Robbins, Robert B. Publisher International Foundation for Telemetering Journal International Telemetering Conference Proceedings Rights Copyright © International Foundation for Telemetering Download date 01/10/2021 10:32:25 Link to Item http://hdl.handle.net/10150/613377 THE EFFICIENT USE OF A VAX COMPUTER IN THE REAL-TIME TELEMETRY ENVIRONMENT Robert B. Robbins Sangamo-Weston Incorporated Data Systems Division Post Office Box 3041 Sarasota, Florida 33578 ABSTRACT The use of a Digital Equipment Corporation VAX computer under the VMS operating system, in a real-time telemetry environment, brings with it many advantages. These advantages pertain to its ability to handle real-time telemetry processing in an efficient and relatively straight forward manner. The author will use the TELSET, TELDAX and TELFOR telemetry software systems as the basis for demonstrating the techniques which have allowed the real-time telemetry user to take advantage of a 32-bit, virtual addressing, architecture. INTRODUCTION Many real-time telemetry computer users believe in the need for 32-bit processing of telemetry data once it has entered the central processor. We at Sangamo-Weston agree with this belief and have successfully designed a real-time telemetry data acquisition system which efficiently uses the VAX computer under the VMS operating system. SYSTEM SOFTWARE The software written for this system achieves three goals. TELSET, which sets up the telemetry front-end hardware units, is written in VAX-11 MACRO. TELDAX the real- time data acquisition executive and TELFOR the telemetry data acquisition formatted storage process are written in interactive VAX-11 FORTRAN and are menu driven.
    [Show full text]
  • RSX - 11 M-PLUS Mini-Reference
    RSX - 11 M-PLUS Mini-Reference Order No. AV-H435F-TC RSX - 11M-PLUS Mini-Reference Order Number. AV-H435F-TC RSX-ll M-PLUS Version 4.2 Digital Equipment Corporation Maynard, Massachusetts First Printing, September 1977 Revised, April 1982 Revised, April 1983 Revised, July 1985 R~vised, .September 1987 Revised, January 1989 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document. The software described in this document is furnished under a license and may be used or copied only in accordance with the terms of such license. No responsibility is assumed for the use or reliability of software on equipment that is not supplied by Digital Equipment Corporation or its affiliated companies. © Digital Equipment Corporation 1977, 1982, 1983, 1985, 1987, 1989. All Rights Reserved. Printed in U.S.A. The postpaid Reader's Comments forms at the end of this document request your critical evaluation to assist in preparing future documentation. The following are trademarks of Digital Equipment Corporation: DEC DIBOL UNIBUS DEC/CMS EduSystem VAX DEC/MMS lAS VAXcluster DECnet MASSBUS VMS DECsystem-lO PDP VT DECSYSTEM-20 PDT DECUS RSTS DECwriter RSX ~U~UIl~DTM ZK5077 Contents Preface vii Conventions ............................................... viii Online Help Files Online Help Files ............................................. 3 Command Line Interpreters Monitor Console Routine (MCR) Commands ......................... 7 Digital Command Language (DCL) ............................... 21 utilities BAD Command Summary ...................................... 67 iii BRU Command Summary ...................................... 69 CMP Command Summary ...................................... 74 DMP Command Summary .....................................
    [Show full text]
  • Digital Technical Journal, Number 5, September 1987: Vaxcluster Systems
    VAX clusterSystems Digital Technical Journal Digital Equipment Corporation Number 5 September 1987 Editorial Staff Ediwr- Richard W. Beane Production Staff Production Editor- Jane C. 131ake Designer- Charlotte Bell Interactive Page Makeup- Te rry Reed Advisory Board Samuel H. Fuller, Chairman Robert M. Glorioso John W. McCredie Mahendra R. Patel F. Grant Saviers William D. Strecker The Digital Te chnical journal is published by Digital Equipment Corporation, 77 Reed Road, Hudson, MassachusettS 01749. Changes of address should be sent to Digital Equipment Corporation, attention: Media Response Manager, 444 Whitney Street, NR02-1/J5, Northboro, M.A 01532-2599 Comments on the content of any paper are welcomed. Write to the editor at Mail Stop HL02-3/K11 at the published-by address. Comments can also be sent on the ENET to RDVAX::BEANE or on the ARPANET to BEANE%RDVAX.DEC@DECWRL. Copyright© 1987 Digital Equipment Corporation. Copying without fee is permiued provided that such copies are made for use in educational institutions by facuhy members and are not distributed for commercial advantage. Abstracting with credit of Digital Equipment Corporation's authorship is permitted Requests for other copies for a fee may be made to the Digital Press of Digital Equipment Corporation. All rights reserved. The information in this journal is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this document.
    [Show full text]
  • Contributions for Resource and Job Management in High Performance Computing Yiannis Georgiou
    Contributions for Resource and Job Management in High Performance Computing Yiannis Georgiou To cite this version: Yiannis Georgiou. Contributions for Resource and Job Management in High Performance Computing. Distributed, Parallel, and Cluster Computing [cs.DC]. Université de Grenoble, 2010. English. tel- 01499598 HAL Id: tel-01499598 https://hal-auf.archives-ouvertes.fr/tel-01499598 Submitted on 31 Mar 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Public Domain THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Informatique Arrêté ministériel : 7 août 2006 Présentée par « Yiannis GEORGIOU » Thèse dirigée par « Olivier RICHARD » et codirigée par « Jean-Francois MEHAUT » préparée au sein du Laboratoire d'Informatique de Grenoble dans l'École Doctorale de Mathématiques, Sciences et Technologies de l'Information, Informatique Contributions for Resource and Job Management in High Performance Computing Thèse soutenue publiquement le « 5 novembre 2010 », devant le jury composé de : M. Daniel, HAGIMONT Professeur à INPT/ENSEEIHT, France, Président M. Franck, CAPPELLO Directeur de Recherche à INRIA, France, Rapporteur M. William T.C., KRAMER Directeur de Recherche à NCSA, USA, Rapporteur M. Morris, JETTE Informaticien au LLNL, USA, Membre Mme.
    [Show full text]
  • Operating Systems Processes and Threads
    COS 318: Operating Systems Processes and Threads Prof. Margaret Martonosi Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall11/cos318 Today’s Topics Processes Concurrency Threads Reminder: Hope you’re all busy implementing your assignment 2 (Traditional) OS Abstractions Processes - thread of control with context Files- In Unix, this is “everything else” Regular file – named, linear stream of data bytes Sockets - endpoints of communication, possible between unrelated processes Pipes - unidirectional I/O stream, can be unnamed Devices Process Most fundamental concept in OS Process: a program in execution one or more threads (units of work) associated system resources Program vs. process program: a passive entity process: an active entity For a program to execute, a process is created for that program Program and Process main() main() { { heap ... ... foo() foo() ... ... } } stack bar() bar() { { registers ... ... PC } } Program Process 5 Process vs. Program Process > program Program is just part of process state Example: many users can run the same program • Each process has its own address space, i.e., even though program has single set of variable names, each process will have different values Process < program A program can invoke more than one process Example: Fork off processes 6 Simplest Process Sequential execution No concurrency inside a process Everything happens sequentially Some coordination may be required Process state Registers Main memory I/O devices • File system • Communication ports … 7 Process Abstraction Unit of scheduling One (or more*) sequential threads of control program counter, register values, call stack Unit of resource allocation address space (code and data), open files sometimes called tasks or jobs Operations on processes: fork (clone-style creation), wait (parent on child), exit (self-termination), signal, kill.
    [Show full text]
  • Processes, Address Spaces, and Context Switches
    Processes, Address Spaces, and Context Switches Chester Rebeiro IIT Madras Executing Apps (Process) • Process – A program in execution – Most important abstraction in an OS – Comprises of $gcc hello.c • Code from ELF In the • Data user space • Stack of process ELF • Heap Executable Process • State in the OS In the kernel (a.out) $./a.out • Kernel stack space – State contains : registers, list of open files, related processes, etc. 2 Program ≠ Process Program Process code + static and global data Dynamic instantiation of code + data + heap + stack + process state One program can create several A process is unique isolated entity processes 3 Process Address Space • Virtual Address Map MAX_SIZE – All memory a process can Stack address – Large contiguous array of addresses from 0 to Heap MAX_SIZE Data Text (instructions) 0 4 Process Address Space • Each process has a different address space • This is achieved by the use of virtual memory • Ie. 0 to MAX_SIZE are virtual memory addresses MAX_SIZE Stack Stack MAX_SIZE Heap Heap Data Data Process A Process B Process A Text Text Process B Page Table (instructions) (instructions) Page Table 0 0 5 Virtual Address Mapping Process A Process B Stack Stack Heap Heap Process A Process B Data Page Page Data Table Table Text Text (instructions) (instructions) Virtual Memory Physical Memory Virtual Memory 6 Advantages of Virtual Address Map • Isolation (private address space) – One process cannot access another process’ memory • Relocatable – Data and code within the process is relocatable • Size – Processes can be much larger than physical memory 7 Kernel can access User Process can access Address Map in xv6 Process DeviceMemory (instructions) Text + Data, Text Kernel Stack Heap Data Text (0x80000000) KERNBASE 0xFE000000 0 • every process address space address process every mapped kernel into Entire – – kernelspace Easyaccess userof datafrom duringsystem calls) usercode kernelto code(ie.
    [Show full text]