DOCSLIB.ORG

Single System Image in a Linux-Based Replicated Operating System Kernel

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Single System Image in a Linux-Based Replicated Operating System Kernel Single System Image in a Linux-based Replicated Operating System Kernel Akshay Giridhar Ravichandran Thesis submitted to the Faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Binoy Ravindran, Chair Robert P. Broadwater Antonio Barbalace February 24, 2015 Blacksburg, Virginia Keywords: Linux, Multikernel, Thread synchronization, Signals, Process Management Copyright 2015, Akshay Giridhar Ravichandran Single System Image in a Linux-based Replicated Operating System Kernel Akshay Giridhar Ravichandran (ABSTRACT) Recent trends in the computer market suggest that emerging computing platforms will be increasingly parallel and heterogeneous, in order to satisfy the user demand for improved performance and superior energy savings. Heterogeneity is a promising technology to keep growing the number of cores per chip without breaking the power wall. However, existing system software is able to cope with homogeneous architectures, but it was not designed to run on heterogeneous architectures, therefore, new system software designs are necessary. One innovative design is the multikernel OS deployed by the Barrelfish operating system (OS) which partitions hardware resources to independent kernel instances that communi- cate exclusively by message passing, without exploiting the shared memory available amongst different CPUs in a multicore platform. Popcorn Linux implements an extension of the mul- tikernel OS design, called replicated-kernel OS, with the goal of providing a Linux-based single system image environment on top of multiple kernels, which can eventually run on dif- ferent ISA processors. A replicated-kernel OS replicates the state of various OS sub-systems amongst kernels that cooperate using message passing to distribute or access various services uniquely available on each kernel. In this thesis, we present mechanisms to distribute signals, namespaces, inter-thread syn- chronizations and socket state replication. These features are built on top of the existing messaging layer, process or thread migration and address space consistency protocol to pro- vide the application with an illusion of single system image and developers with the SMP programming environment they are most familiar with. The mechanisms developed were unit tested with micro benchmarks to validate their cor- rectness and to measure the gained speed up or additive overhead. Real-world applications were also used to benchmark the developed mechanisms on homogeneous and on heteroge- neous architectures. It is found that the contributed Popcorn synchronization mechanism exhibits overhead compared to vanilla Linux on multicore as Linux's equivalent mechanisms is tightly coupled with underlying hardware cache coherency protocol, therefore, faster than software message passing. On heterogeneous platforms, the developed mechanisms allow to transparently map each portion of the application to the processor in the platform on which the execution is faster. Optimizations are recommended to further improve the performance of the proposed synchronization mechanism. However, optimizations may force the user- space application and libraries to be rewritten in order to decouple their synchronization mechanisms of shared memory, therefore losing transparency, which is one of the primary goals of this work. Dedication This work is dedicated to my parents. iii Acknowledgments This work is supported in part by ONR under grant N00014-13-1-0317. Any opinions, find- ings, and conclusions expressed in this thesis are those of the author and do not necessarily reflect the views of ONR. iv Contents 1 Introduction1 1.1 Scalability Problem on Homogeneous ISA Platforms..............2 1.2 Scalability Problem on Heterogeneous ISA Platforms.............3 1.3 Research Contributions..............................3 1.4 Thesis Scope....................................4 1.5 Thesis Organization................................4 2 Related Work5 2.1 Single System Image on Multikernels......................5 2.1.1 K2.....................................5 2.1.2 Cerberus..................................6 2.1.3 Barrelfish Operating System.......................6 2.1.4 Factored Operating System.......................7 2.2 Single System Image on Multicellular Operating Systems...........8 2.2.1 Cellular IRIX...............................8 2.2.2 Disco....................................8 2.2.3 Hive....................................9 2.3 Single System Image on Clusters........................ 10 2.3.1 Kerrighed................................. 10 2.3.2 MOSIX.................................. 10 2.3.3 OpenSSI.................................. 11 v 2.3.4 Bproc................................... 11 2.3.5 Helios................................... 11 3 Popcorn Background 13 3.1 Popcorn System Overview............................ 13 3.2 Multikernel Boot................................. 13 3.3 CPU Partitioning................................. 14 3.4 Memory Partitioning............................... 14 3.5 Message Passing.................................. 14 3.6 Device Drivers................................... 15 3.7 Thread Migration................................. 15 3.8 Distributed File System............................. 16 4 Signals 17 4.1 Introduction.................................... 17 4.1.1 Signals During Start of a Thread.................... 17 4.1.2 Signals Delivery.............................. 17 4.2 Design Motivation................................ 18 4.3 Implementation.................................. 19 4.3.1 Signals Migration............................. 19 4.3.2 Signals Delivery.............................. 19 4.4 Evaluation..................................... 20 5 Futex 22 5.1 Introduction.................................... 22 5.1.1 Futex Wait................................ 24 5.1.2 Futex Wake................................ 24 5.1.3 Futex Requeue.............................. 24 5.2 Design Motivation................................ 24 5.3 Implementation.................................. 25 vi 5.3.1 Global Ticketing Mechanism....................... 27 5.3.2 Granting Entry into Critical Section.................. 28 5.3.3 Process Exit................................ 30 5.3.4 Real-time (Priority Inheritance) Support................ 32 5.3.5 Parallel Messaging Layer......................... 32 5.3.6 Issues in Scheduling............................ 32 5.3.7 Process Synchronization......................... 33 5.3.8 Issue of False Sharing........................... 33 5.4 Evaluation..................................... 33 5.4.1 Experimental Setup............................ 33 5.4.2 Microbenchmarks............................. 34 5.4.3 Macro Benchmarks............................ 40 6 Process Management 48 6.1 Introduction.................................... 48 6.2 Design Motivation................................ 48 6.3 Implementation.................................. 49 6.3.1 Kernel Discovery............................. 49 6.3.2 Single IP Address............................. 49 6.3.3 Unique Process ID............................ 50 6.3.4 Proc File System............................. 51 6.3.5 Namespaces................................ 52 7 Conclusion 53 7.1 Future Work.................................... 54 7.1.1 Shared Memory Synchronization Variants............... 54 7.1.2 Alternative Approach to Synchronization................ 54 7.1.3 Process Management........................... 54 Bibliography 56 vii List of Figures 3.1 Popcorn System Overview............................ 13 4.1 Distributed Signals control flow......................... 20 5.1 Kernel Space design of Futex in Linux. http://lwn.net/Articles/360699/ Used under fair use, 2015................................ 23 5.2 Data structure organization on the server side................. 27 5.3 Distributed Wait Control Flow.......................... 29 5.4 Distributed Wake Control Flow......................... 30 5.5 Distributed Requeue Control Flow....................... 31 5.6 Spinlock Vs Linux Vs Popcorn.......................... 36 5.7 Critical Section Access.............................. 38 5.8 Relative comparison of costs in heterogeneous and homogeneous....... 40 5.9 Performance comparison for IS-BOMP..................... 42 5.10 Performance comparison for CG-BOMP.................... 43 5.11 Performance comparison for FT-BOMP..................... 44 viii List of Tables 4.1 Test cases executed for evaluating signals.................... 21 4.2 Cost of signals sent by kill............................ 21 4.3 Cost of signals sent by killall........................... 21 5.1 Futex's user space variable state......................... 23 5.2 Test cases executed for evaluating Futex.................... 34 5.3 Lock Scalability.................................. 35 5.4 Perf results for scalability............................ 35 5.5 Barriers executed for 100 Rounds........................ 36 5.6 Producer-Consumer: Number of access into critical section.......... 37 5.7 Average syscalls and retries for producer-consumer.............. 37 5.8 Perf results for mutex between two threads................... 39 5.9 Mutex between two threads serialized by barriers............... 39 5.10 Mutex between two threads serialized by barriers in Heterogeneous..... 39 5.11 Average syscalls and retries for Mutex between two threads.......... 39 5.12 Syscall count comparison for IS-BOMP..................... 41 5.13 Cost breakdown for IS-BOMP.........................
Load more

Recommended publications
  • User Guide Laplink® Diskimage™ 7 Professional
    http://www.laplink.com/contact 1 ™ E-mail us at [email protected] Laplink® DiskImage 7 Professional User Guide Tel (USA): +1 (425) 952-6001 Tel (UK): +44 (0) 870-2410-983 Fax (USA): +1 (425) 952-6002 Fax (UK): +44 (0) 870-2410-984 ™ Laplink® DiskImage 7 Professional Laplink Software, Inc. Customer Service/Technical Support: Web: http://www.laplink.com/contact E-mail: [email protected] Tel (USA): +1 (425) 952-6001 Fax (USA): +1 (425) 952-6002 Tel (UK): +44 (0) 870-2410-983 User Guide Fax (UK): +44 (0) 870-2410-984 Laplink Software, Inc. 600 108th Ave. NE, Suite 610 Bellevue, WA 98004 U.S.A. Copyright / Trademark Notice © Copyright 2013 Laplink Software, Inc. All rights reserved. Laplink, the Laplink logo, Connect Your World, and DiskImage are registered trademarks or trademarks of Laplink Software, Inc. in the United States and/or other countries. Other trademarks, product names, company names, and logos are the property of their respective holder(s). UG-DiskImagePro-EN-7 (REV. 5/2013) http://www.laplink.com/contact 2 ™ E-mail us at [email protected] Laplink® DiskImage 7 Professional User Guide Tel (USA): +1 (425) 952-6001 Tel (UK): +44 (0) 870-2410-983 Fax (USA): +1 (425) 952-6002 Fax (UK): +44 (0) 870-2410-984 Contents Installation and Registration System Requirements . 1 Installing Laplink DiskImage . 1 Registration . 2 Introduction to DiskImage Overview of Important Features . 2 Definitions . 3 Start Laplink DiskImage - Two Methods . 4 Windows Start . .4 Bootable CD . .4 DiskImage Tasks One-Click Imaging: Create an Image of the Entire Computer .
    [Show full text]
  • Ada Departmental Supercomputer Shared Memory GPU Cluster
    Ada Departmental Supercomputer Shared Memory GPU Cluster The Ada Departmental Supercomputer is designed to provide System Specifications near top 500 class supercomputing capabilities at your office Processors: Head Node: 2 AMD EPYC 7702 Processors or lab. (64 core-2.0/3.3 GHz) Compute Nodes: 1 AMD EPYC 7702P Proces- Ada is a hybrid supercomputer consisting of a large memory sor (64 core-2.2/3.2 GHz), 8 AMD Radeon head node and 2 to 5 compute nodes, each with eight AMD Instinct MI50 GPUs Radeon Instinct MI50 GPUs. With 5 compute nodes Ada con- Global Memory: 2TB or 4TB 3200 MHz DDR4 tains 448 AMD EPYC processor cores, 40 MI50 GPUs and 2 or 4 TB of globally shared memory. The compute nodes are Compute Node 128 GB 3200 MHz DDR4 (each) Memory: connected to the head node with 200 Gb/s Mellanox Infini- band. The Ada departmental supercomputer can be config- Storage: 1TB on-board M.2 OS SSD ured to deliver 1060 TFLOPS of FP16, 532 TFLOPS of FP32 12x 3.5" SATA/SAS hot-swap and 264 TFLOPS of FP64 GPU floating point performance SSD/HDD bays (head node) Additional 8x 2.5” SSD hot-swap bays on each capable of operating on large computational models. compute node Ada is a true symmetric multi-processing (SMP) computer Interconnect: ConnectX-6 VPI 200 Gb/s InfiniBand Dual Port with a large shared memory and a single operating system PCIe Gen 4 Host Bus Adapters user interface based on Centos 8 Linux. It provides a 1TB (No InfiniBand switch is needed) globally shared fast file system, and a large disk storage ar- I/O: 2x 1 Gb/s LAN ports ray.
    [Show full text]
  • Sprite File System There Are Three Important Aspects of the Sprite ®Le System: the Scale of the System, Location-Transparency, and Distributed State
    Naming, State Management, and User-Level Extensions in the Sprite Distributed File System Copyright 1990 Brent Ballinger Welch CHAPTER 1 Introduction ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ This dissertation concerns network computing environments. Advances in network and microprocessor technology have caused a shift from stand-alone timesharing systems to networks of powerful personal computers. Operating systems designed for stand-alone timesharing hosts do not adapt easily to a distributed environment. Resources like disk storage, printers, and tape drives are not concentrated at a single point. Instead, they are scattered around the network under the control of different hosts. New operating system mechanisms are needed to handle this sort of distribution so that users and application programs need not worry about the distributed nature of the underlying system. This dissertation explores the approach of centering a distributed computing environment around a shared network ®le system. The ®le system is chosen as a starting point because it is a heavily used service in stand-alone systems, and the read/write para- digm of the ®le system is a familiar one that can be applied to many system resources. The ®le system described in this dissertation provides a distributed name space for sys- tem resources, and it provides remote access facilities so all resources are available throughout the network. Resources accessible via the ®le system include disk storage, other types of peripheral devices, and user-implemented service applications. The result- ing system is one where resources are named and accessed via the shared ®le system, and the underlying distribution of the system among a collection of hosts is not important to users.
    [Show full text]
  • Vis: Virtualization Enhanced Live Forensics Acquisition for Native System
    Vis: Virtualization Enhanced Live Forensics Acquisition for Native System Miao Yu, Zhengwei Qi, Qian Lin, Xianming Zhong, Bingyu Li, Haibing Guan Shanghai Key Laboratory of Scalable Computing and Systems Shanghai Jiao Tong University f superymk, qizhwei, linqian, zhongxianming, justasmallfish, hbguan g @ sjtu.edu.cn Abstract Focusing on obtaining in-memory evidence, current live acquisition efforts either fail to provide accurate native system physical memory acquisition at the given time point or require suspending the machine and altering the execution environment drastically. To address this issue, we propose Vis, a light-weight virtualization approach to provide accurate retrieving of physical memory content while preserving the execution of target native system. Our experimental results indicate that Vis is capable of reliably retrieving an accurate system image. Moreover, Vis accomplishes live acquisition within 97.09∼105.86 seconds, which shows that Vis is much more efficient than previous remote live acquisition tools that take hours and static acquisition that takes days. In average, Vis incurs only 9.62% performance overhead to the target system. Keywords: Vis, Live acquisition, Accuracy, Virtualization 1. Introduction After forensic scopes and medias are determined, a typical computer forensics scenario has three steps: acquisition, analyzing and reporting [47, 9]. Focusing on the stages of acquisition and analyzing, computer forensics pro- poses two key challenges: how to obtain the complete system state and how to analyze the retrieved image effectively [39]. Missing image of memory Preprint submitted to Digital Investigation February 16, 2012 content leads to an incomplete or wrong investigation result, even with an incomparable analyzing technology. Transcending static acquisition strategies, live acquisition extends the information gathering range of forensics examiner, i.e., involving with the volatile data.
    [Show full text]
  • A User Guide for the FRED Family of Forensic Systems Thank You for Your Recent Order
    A User Guide for the FRED Family of Forensic Systems Thank you for your recent order. We hope you like your new FRED! Please do not hesitate to contact us if you have any questions or require any additional information. Although we welcome a phone call anytime, our preferred method of contact is via our website www.digitalintelligence.com . The sales and technical support ticketing system is easy to use and allow us to track all requests and responses. To create your user account click on the User Icon on the top right of the web page banner and click on Sign Up. Here you can register your FRED system as well as track your web order history and support tickets. Please note your system serial number is the unique identifier for your system. It is helpful if you use the system serial number in your correspondence. If you have a sales related question or technical support issue, simply navigate to www.digitalintelligence.com/support A searchable knowledge base, links to other help or informational topics as well as a “Open A Ticket” button link can be found near the bottom of the page. We want to remind you, regardless of your warranty status, we will always be willing to assist with any technical questions you have regarding any Digital Intelligence product. *** Read me first *** Forensic Recovery of Evidence Device This document contains important information about the configuration and operation of your FRED system. FAILURE TO FOLLOW THESE GUIDELINES MAY RESULT IN PHYSICAL DAMAGE TO YOUR EQUIPMENT WHICH IS NOT COVERED UNDER WARRANTY.
    [Show full text]
  • Network RAM Based Process Migration for HPC Clusters
    Journal of Information Systems and Telecommunication, Vol. 1, No. 1, Jan – March 2013 39 Network RAM Based Process Migration for HPC Clusters Hamid Sharifian* Department of Computer Engineering, Iran University of Science and Technology, Tehran, Iran [email protected] Mohsen Sharifi Department of Computer Engineering, Iran University of Science and Technology, Tehran, Iran [email protected] Received: 04/Dec/2012 Accepted: 09/Feb/2013 Abstract Process migration is critical to dynamic balancing of workloads on cluster nodes in any high performance computing cluster to achieve high overall throughput and performance. Most existing process migration mechanisms are however unsuccessful in achieving this goal proper because they either allow once-only migration of processes or have complex implementations of address space transfer that degrade process migration performance. We propose a new process migration mechanism for HPC clusters that allows multiple migrations of each process by using the network RAM feature of clusters to transfer the address spaces of processes upon their multiple migrations. We show experimentally that the superiority of our proposed mechanism in attaining higher performance compared to existing comparable mechanisms is due to effective management of residual data dependencies. Keywords: High Performance Computing (HPC) Clusters, Process Migration, Network RAM, Load Balancing, Address Space Transfer. 1. Introduction and data access locality in addition to an enhanced degree of dynamic load distribution [1]. A standard approach to reducing the runtime Upon migration of a process, the process of any high performance scientific computing must be suspended and its context information in application on a high performance computing the source node extracted and transferred to the (HPC) cluster is to partition the application into destination node.
    [Show full text]
  • Clustering with Openmosix
    Clustering with openMosix Maurizio Davini (Department of Physics and INFN Pisa) Presented by Enrico Mazzoni (INFN Pisa) Introduction • What is openMosix? – Single-System Image – Preemptive Process Migration – The openMosix File System (MFS) • Application Fields • openMosix vs Beowulf • The people behind openMosix • The openMosix GNU project • Fork of openMosix code 12/06/2003 HTASC 2 The openMosix Project MileStones • Born early 80s on PDP-11/70. One full PDP and disk-less PDP, therefore process migration idea. • First implementation on BSD/pdp as MS.c thesis. • VAX 11/780 implementation (different word size, different memory architecture) • Motorola / VME bus implementation as Ph.D. thesis in 1993 for under contract from IDF (Israeli Defence Forces) • 1994 BSDi version • GNU and Linux since 1997 • Contributed dozens of patches to the standard Linux kernel • Split Mosix / openMosix November 2001 • Mosix standard in Linux 2.5? 12/06/2003 HTASC 3 What is openMOSIX • Linux kernel extension (2.4.20) for clustering • Single System Image - like an SMP, for: – No need to modify applications – Adaptive resource management to dynamic load characteristics (CPU intensive, RAM intensive, I/O etc.) – Linear scalability (unlike SMP) 12/06/2003 HTASC 4 A two tier technology 1. Information gathering and dissemination – Support scalable configurations by probabilistic dissemination algorithms – Same overhead for 16 nodes or 2056 nodes 2. Pre-emptive process migration that can migrate any process, anywhere, anytime - transparently – Supervised by adaptive
    [Show full text]
  • Distributed Virtual Machines: a System Architecture for Network Computing
    Distributed Virtual Machines: A System Architecture for Network Computing Emin Gün Sirer, Robert Grimm, Arthur J. Gregory, Nathan Anderson, Brian N. Bershad {egs,rgrimm,artjg,nra,bershad}@cs.washington.edu http://kimera.cs.washington.edu Dept. of Computer Science & Engineering University of Washington Seattle, WA 98195-2350 Abstract Modern virtual machines, such as Java and Inferno, are emerging as network computing platforms. While these virtual machines provide higher-level abstractions and more sophisticated services than their predecessors from twenty years ago, their architecture has essentially remained unchanged. State of the art virtual machines are still monolithic, that is, they are comprised of closely-coupled service components, which are thus replicated over all computers in an organization. This crude replication of services forms one of the weakest points in today’s networked systems, as it creates widely acknowledged and well-publicized problems of security, manageability and performance. We have designed and implemented a new system architecture for network computing based on distributed virtual machines. In our system, virtual machine services that perform rule checking and code transformation are factored out of clients and are located in enterprise- wide network servers. The services operate by intercepting application code and modifying it on the fly to provide additional service functionality. This architecture reduces client resource demands and the size of the trusted computing base, establishes physical isolation between virtual machine services and creates a single point of administration. We demonstrate that such a distributed virtual machine architecture can provide substantially better integrity and manageability than a monolithic architecture, scales well with increasing numbers of clients, and does not entail high overhead.
    [Show full text]
  • Dynamic Scheduling with Process Migration*
    Dynamic Scheduling with Process Migration* Cong Du, Xian-He Sun, and Ming Wu Department of Computer Science Illinois Institute of Technology Chicago, IL 60616, USA {ducong, sun, wuming}@iit.edu Abstract* computing resources. In addition, besides load balance, migration-based dynamic scheduling also benefits Process migration is essential for runtime load dynamic Grid management [19] in the cases of new balancing. In Grid and shared networked machines joining or leaving, resource cost variation, environments, load imbalance is not only caused by the and local task preemption. dynamic nature of underlying applications, but also by An appropriate rescheduling should consider the the fluctuation of resource availability. In a shared migration costs. This is especially true in distributed environment, tasks need to be rescheduled frequently and heterogeneous environments, where plenty of to adapt the variation of resources availability. Unlike computing resources are available at any given time conventional task scheduling, dynamic rescheduling but the associated migration costs may vary largely. An has to consider process migration costs in its effective and broadly applicable solution for modeling formulation. In this study, we first model the migration and estimating migration costs, however, has been cost and introduce an effective method to predict the elusive. Even if an estimate is available, integrating cost. We then introduce a dynamic scheduling migration cost into a dynamic scheduling system is still mechanism that considers migration cost as well as a challenging task. Based on our years of experience in other conventional influential factors for performance process migration [8] and task scheduling [24], we optimization in a shared, heterogeneous environment.
    [Show full text]
  • Workstation Operating Systems Mac OS 9
    15-410 “Now that we've covered the 1970's...” Plan 9 Nov. 25, 2019 Dave Eckhardt 1 L11_P9 15-412, F'19 Overview “The land that time forgot” What style of computing? The death of timesharing The “Unix workstation problem” Design principles Name spaces File servers The TCP file system... Runtime environment 3 15-412, F'19 The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) The Land That Time Forgot The “multi-core revolution” already happened once 1982: VAX-11/782 (dual-core) 1984: Sequent Balance 8000 (12 x NS32032) 1985: Encore MultiMax (20 x NS32032) 1990: Omron Luna88k workstation (4 x Motorola 88100) 1991: KSR1 (1088 x KSR1) 1991: “MCS” paper on multi-processor locking algorithms 1995: BeBox workstation (2 x PowerPC 603) Wow! Why was 1995-2004 ruled by single-core machines? What operating systems did those multi-core machines run? The Land That Time Forgot Why was 1995-2004 ruled by single-core machines? In 1995 Intel + Microsoft made it feasible to buy a fast processor that fit on one chip, a fast I/O bus, multiple megabytes of RAM, and an OS with memory protection. Everybody could afford a “workstation”, so everybody bought one. Massive economies of scale existed in the single- processor “Wintel” universe.
    [Show full text]
  • Distributed Operating Systems
    Distributed Operating Systems ANDREW S. TANENBAUM and ROBBERT VAN RENESSE Department of Mathematics and Computer Science, Vrije Universiteit, Amsterdam, The Netherlands Distributed operating systems have many aspects in common with centralized ones, but they also differ in certain ways. This paper is intended as an introduction to distributed operating systems, and especially to current university research about them. After a discussion of what constitutes a distributed operating system and how it is distinguished from a computer network, various key design issues are discussed. Then several examples of current research projects are examined in some detail, namely, the Cambridge Distributed Computing System, Amoeba, V, and Eden. Categories and Subject Descriptors: C.2.4 [Computer-Communications Networks]: Distributed Systems-network operating system; D.4.3 [Operating Systems]: File Systems Management-distributed file systems; D.4.5 [Operating Systems]: Reliability-fault tolerance; D.4.6 [Operating Systems]: Security and Protection-access controls; D.4.7 [Operating Systems]: Organization and Design-distributed systems General Terms: Algorithms, Design, Experimentation, Reliability, Security Additional Key Words and Phrases: File server INTRODUCTION more convenient to use than the bare ma- chine. Examples of well-known centralized Everyone agrees that distributed systems (i.e., not distributed) operating systems are are going to be very important in the future. CP/M,’ MS-DOS,’ and UNIX.3 Unfortunately, not everyone agrees on A distributed operating system is one that what they mean by the term “distributed looks to its users like an ordinary central- system.” In this paper we present a view- ized operating system but runs on multi- point widely held within academia about ple, independent central processing units what is and is not a distributed system, we (CPUs).
    [Show full text]
  • Containers: a Sound Basis for a True Single System Image
    Containers : A Sound Basis For a True Single System Image Renaud Lottiaux, Christine Morin To cite this version: Renaud Lottiaux, Christine Morin. Containers : A Sound Basis For a True Single System Image. [Research Report] RR-4085, INRIA. 2000. inria-00072548 HAL Id: inria-00072548 https://hal.inria.fr/inria-00072548 Submitted on 24 May 2006 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. INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE Containers : A Sound Basis For a True Single System Image Renaud Lottiaux, Christine Morin N˚4085 Novembre 2000 THÈME 1 apport de recherche ISRN INRIA/RR--4085--FR+ENG ISSN 0249-6399 Containers : A Sound Basis For a True Single System Image Renaud Lottiaux , Christine Morin Thème 1 — Réseaux et systèmes Projet PARIS Rapport de recherche n˚4085 — Novembre 2000 — 19 pages Abstract: Clusters of SMPs are attractive for executing shared memory parallel appli- cations but reconciling high performance and ease of programming remains an open issue. A possible approach is to provide an efficient Single System Image (SSI) operating system giving the illusion of an SMP machine. In this paper, we introduce the concept of container as a mechanism to unify global resource management at the lowest operating system level.
    [Show full text]