Operating Systems in Depth This Page Intentionally Left Blank OPERATING SYSTEMS in DEPTH

Total Page:16

File Type:pdf, Size:1020Kb

Operating Systems in Depth This Page Intentionally Left Blank OPERATING SYSTEMS in DEPTH This page intentionally left blank Operating Systems in Depth This page intentionally left blank OPERATING SYSTEMS IN DEPTH Thomas W. Doeppner Brown University JOHN WILEY & SONS, INC. vice-president & executive publisher Donald Fowley executive editor Beth Lang Golub executive marketing manager Christopher Ruel production editor Barbara Russiello editorial program assistant Mike Berlin senior marketing assistant Diana Smith executive media editor Thomas Kulesa cover design Wendy Lai cover photo Thomas W. Doeppner Cover photo is of Banggai Cardinalfi sh (Pterapogon kauderni), taken in the Lembeh Strait, North Sulawesi, Indonesia. This book was set in 10/12 Times Roman. The book was composed by MPS Limited, A Macmillan Company and printed and bound by Hamilton Printing Company. This book is printed on acid free paper. ϱ Founded in 1807, John Wiley & Sons, Inc. has been a valued source of knowledge and understanding for more than 200 years, helping people around the world meet their needs and fulfi ll their aspirations. Our company is built on a foundation of principles that include responsibility to the communities we serve and where we live and work. In 2008, we launched a Corporate Citizenship Initiative, a global effort to address the environmental, social, economic, and ethical challenges we face in our business. Among the issues we are addressing are carbon impact, paper specifi cations and procurement, ethical conduct within our business and among our vendors, and community and charitable support. For more information, please visit our website: www.wiley.com/go/citizenship. Copyright © 2011 by John Wiley & Sons, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923 (Web site: www.copyright.com). Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030-5774, (201) 748-6011, fax (201) 748-6008, or online at: www. wiley.com/go/permissions. Evaluation copies are provided to qualifi ed academics and professionals for review purposes only, for use in their courses during the next academic year. These copies are licensed and may not be sold or transferred to a third party. Upon completion of the review period, please return the evaluation copy to Wiley. Return instructions and a free of charge return shipping label are available at: www.wiley.com/ go/returnlabel. Outside of the United States, please contact your local representative. Library of Congress Cataloging in Publication Data: Doeppner, Thomas W. Operating systems in depth / Thomas W. Doeppner. p. cm. Includes index. ISBN 978-0-471-68723-8 (hardback) 1. Operating systems (Computers) I. Title. QA76.76.O63D64 2010 005.4’3—dc22 2010034669 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 To the memory of my father, Thomas W. Doeppner Sr. This page intentionally left blank Preface he goal of this book is to bring together and explain current practice in operating systems. TThis includes much of what is traditionally covered in operating-system textbooks: concur- rency, scheduling, linking and loading, storage management (both real and virtual), fi le systems, and security. However, I also cover issues that come up every day in operating-systems design and implementation but are not often taught in undergraduate courses. For example, I cover: • Deferred work, which includes deferred and asynchronous procedure calls in Windows, tasklets in Linux, and interrupt threads in Solaris. • The intricacies of thread switching, on both uniprocessor and multiprocessor systems. • Modern fi le systems, such as ZFS and WAFL. • Distributed fi le systems, including CIFS and NFS version 4. AUDIENCE This book is based on material I’ve developed over the past 30+ years for my operating-systems course at Brown University and is suitable for a one-semester course for advanced undergradu- ates and beginning graduate students. Students taking the course at Brown have generally had an introductory course on computer architecture and an advanced programming course. The course investigates in depth what’s done in current operating systems, and its signifi cant programming projects make students come to grips with major operating-system components and attain an intimate understanding of how they work. But certainly not all students in an OS course want to go on to concentrate in the area, let alone work in it. A course based on this text must be accessible to these students as well. This issue is handled at Brown by letting students choose one of two projects (discussed later in this preface). The fi rst, relatively straightforward, project involves writing a user-level threads library, a fi le-system cache manager, and a simple fi le system. The second, for the truly interested gung-ho students, is to implement a good portion of a simple but fully functional operating system. (Those portions that are not pedagogically useful for students to write are provided to them.) Students completing this latter project get a half course of additional credit (Brown’s full courses and half courses are equivalent to four-credit and two-credit courses in schools using the credit system). TOPIC COVERAGE Part of the challenge in writing a textbook is not only choosing the topics to cover but also determining the order of presentation. There is the usual conundrum: to appreciate the individual viivii viii PREFACE topics one must fi rst know how they fi t together, but to appreciate how they fi t together one must fi rst know the individual topics. Compounding this problem is my belief that students must complete a comprehensive programming project in order to understand and appreciate how operating systems work. Thus the material must be presented so as to make such a project possible. Chapter 1, Introduction, introduces the reader to what an operating system is. It discusses at an abstract level both how they’re structured and what they do and provides a brief history. Then, to make things concrete and to introduce the notions of processes and fi les, I briefl y describe early Unix (Sixth Edition, from 1975). This 35-year-old OS is attractive both because of its simplicity and elegance and because, at the level presented here, it’s not all that different from either modern Unix systems or modern Windows. Exploring the concept of a process has traditionally been a fundamental part of an operating systems course. However, the meaning of this term has changed over the years. As used in most of today’s operating systems, a process is what was originally called a computation. Most systems now use the term thread to refer to what was originally meant by process. Our introduction to the process concept in Chapter 1 uses the contemporary notion of a process; we spend most of Chapter 2, Multithreaded Programming, discussing threads. It’s really important that students doing an operating-systems project understand concurrency—and by “understand” I mean not simply comprehending the concepts but also becoming profi cient in multithreaded programming. Chapter 2 is a tutorial on how to write multithreaded programs, both using POSIX threads and Windows threads. Though the material covers such programming from an application-program perspective, both the concepts and the practice apply to programming within an operating system. In this chapter, I go over the notion of deadlocks. Earlier operating-systems textbooks have spent a great deal of time on deadlocks, describing algorithms for deadlock detection and avoidance. In practice, such algorithms have little or no role in operating systems, so I simply discuss deadlock avoidance. Chapter 3, Basic Concepts, covers a collection of topics students may have met in previous courses; they aren’t all strictly operating-systems material, but they are essential for understanding operating systems. Included here is a discussion of procedure calls and various forms of context switching at an assembler-language level. We talk a lot about context switching and its cost when discussing operating systems, so students really must understand what’s involved. This discussion is given both in terms of x86 assembler language and SPARC assembler language. The latter is done to balance the x86-orientation of this part of the chapter but may safely be skipped. Also included in the chapter is a rather simple discussion of I/O architectures, important both for programming projects and for understanding I/O handling in operating systems. I cover dynamic storage-allocation algorithms, following in part Knuth’s classic treatment, with additional material on slab allocation. Though this topic could well be considered appropriate for an algorithms course, it doesn’t seem to be taught there and it’s defi nitely important in operating systems. I discuss linkers and loaders, concepts that also seem to be much neglected elsewhere in the curriculum. Finally, I go over how a system is booted. Up to Chapter 4, Operating-System Design, I really haven’t explained what’s in an operating system, except briefl y in the introduction. In Chapter 4, I go over standard operating-system components, discuss fl ow of control in terms of both threads and interrupt handling, and introduce structuring techniques for operating systems such as monolithic kernels, microkernels, and virtual machines. I talk about some of the layering that’s used, such as the virtual fi le system (VFS) layer in Unix systems and its equivalent in Windows.
Recommended publications
  • Digital Technical Journal, Number 3, September 1986: Networking
    Netwo;king Products Digital TechnicalJournal Digital Equipment Corporation Number 3 September I 986 Contents 8 Foreword William R. Johnson, Jr. New Products 10 Digital Network Architecture Overview Anthony G. Lauck, David R. Oran, and Radia J. Perlman 2 5 PerformanceAn alysis andModeling of Digital's Networking Architecture Raj Jain and William R. Hawe 35 The DECnetjSNA Gateway Product-A Case Study in Cross Vendor Networking John P:.. �orency, David Poner, Richard P. Pitkin, and David R. Oran ._ 54 The Extended Local Area Network Architecture and LANBridge 100 William R. Hawe, Mark F. Kempf, and Alan). Kirby 7 3 Terminal Servers on Ethernet Local Area Networks Bruce E. Mann, Colin Strutt, and Mark F. Kempf 88 The DECnet-VAXProduct -A n IntegratedAp proach to Networking Paul R. Beck and James A. Krycka 100 The DECnet-ULTRIXSoftware John Forecast, James L. Jackson, and Jeffrey A. Schriesheim 108 The DECnet-DOS System Peter 0. Mierswa, David). Mitton, and Ma�ha L. Spence 117 The Evolution of Network Management Products Nancy R. La Pelle, Mark). Seger, and Mark W. Sylor 129 The NMCCjDECnet Monitor Design Mark W. Sylor 1 Editor's Introduction The paper by Bill Hawe, Mark Kempf, and AI Kirby reports how studies of potential new broad­ band products led to the development of the Extended LAN Architecture. The design of the LANBridge 100, the first product incorporating that architecture, is described, along with the trade-offs made to achieve high performance. The speed of communication between terminals and systems depends on how they are connected. Bruce Mann, Colin Strutt, and Mark Kempf explain how they developed the LAT protocol to connect terminals to hosts on an Ethernet.
    [Show full text]
  • Development of a Verified Flash File System ⋆
    Development of a Verified Flash File System ? Gerhard Schellhorn, Gidon Ernst, J¨orgPf¨ahler,Dominik Haneberg, and Wolfgang Reif Institute for Software & Systems Engineering University of Augsburg, Germany fschellhorn,ernst,joerg.pfaehler,haneberg,reifg @informatik.uni-augsburg.de Abstract. This paper gives an overview over the development of a for- mally verified file system for flash memory. We describe our approach that is based on Abstract State Machines and incremental modular re- finement. Some of the important intermediate levels and the features they introduce are given. We report on the verification challenges addressed so far, and point to open problems and future work. We furthermore draw preliminary conclusions on the methodology and the required tool support. 1 Introduction Flaws in the design and implementation of file systems already lead to serious problems in mission-critical systems. A prominent example is the Mars Explo- ration Rover Spirit [34] that got stuck in a reset cycle. In 2013, the Mars Rover Curiosity also had a bug in its file system implementation, that triggered an au- tomatic switch to safe mode. The first incident prompted a proposal to formally verify a file system for flash memory [24,18] as a pilot project for Hoare's Grand Challenge [22]. We are developing a verified flash file system (FFS). This paper reports on our progress and discusses some of the aspects of the project. We describe parts of the design, the formal models, and proofs, pointing out challenges and solutions. The main characteristic of flash memory that guides the design is that data cannot be overwritten in place, instead space can only be reused by erasing whole blocks.
    [Show full text]
  • Membrane: Operating System Support for Restartable File Systems Swaminathan Sundararaman, Sriram Subramanian, Abhishek Rajimwale, Andrea C
    Membrane: Operating System Support for Restartable File Systems Swaminathan Sundararaman, Sriram Subramanian, Abhishek Rajimwale, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, Michael M. Swift Computer Sciences Department, University of Wisconsin, Madison Abstract and most complex code bases in the kernel. Further, We introduce Membrane, a set of changes to the oper- file systems are still under active development, and new ating system to support restartable file systems. Mem- ones are introduced quite frequently. For example, Linux brane allows an operating system to tolerate a broad has many established file systems, including ext2 [34], class of file system failures and does so while remain- ext3 [35], reiserfs [27], and still there is great interest in ing transparent to running applications; upon failure, the next-generation file systems such as Linux ext4 and btrfs. file system restarts, its state is restored, and pending ap- Thus, file systems are large, complex, and under develop- plication requests are serviced as if no failure had oc- ment, the perfect storm for numerous bugs to arise. curred. Membrane provides transparent recovery through Because of the likely presence of flaws in their imple- a lightweight logging and checkpoint infrastructure, and mentation, it is critical to consider how to recover from includes novel techniques to improve performance and file system crashes as well. Unfortunately, we cannot di- correctness of its fault-anticipation and recovery machin- rectly apply previous work from the device-driver litera- ery. We tested Membrane with ext2, ext3, and VFAT. ture to improving file-system fault recovery. File systems, Through experimentation, we show that Membrane in- unlike device drivers, are extremely stateful, as they man- duces little performance overhead and can tolerate a wide age vast amounts of both in-memory and persistent data; range of file system crashes.
    [Show full text]
  • Name Description Files Notes See Also Colophon
    PTS(4) Linux Programmer’sManual PTS(4) NAME ptmx, pts − pseudoterminal master and slave DESCRIPTION The file /dev/ptmx is a character file with major number 5 and minor number 2, usually with mode 0666 and ownership root:root. It is used to create a pseudoterminal master and slave pair. When a process opens /dev/ptmx,itgets a file descriptor for a pseudoterminal master (PTM), and a pseu- doterminal slave (PTS) device is created in the /dev/pts directory.Each file descriptor obtained by opening /dev/ptmx is an independent PTM with its own associated PTS, whose path can be found by passing the file descriptor to ptsname(3). Before opening the pseudoterminal slave,you must pass the master’sfile descriptor to grantpt(3) and un- lockpt(3). Once both the pseudoterminal master and slave are open, the slave provides processes with an interface that is identical to that of a real terminal. Data written to the slave ispresented on the master file descriptor as input. Data written to the master is presented to the slave asinput. In practice, pseudoterminals are used for implementing terminal emulators such as xterm(1), in which data read from the pseudoterminal master is interpreted by the application in the same way a real terminal would interpret the data, and for implementing remote-login programs such as sshd(8), in which data read from the pseudoterminal master is sent across the network to a client program that is connected to a terminal or terminal emulator. Pseudoterminals can also be used to send input to programs that normally refuse to read input from pipes (such as su(1), and passwd(1)).
    [Show full text]
  • A Multiplatform Pseudo Terminal
    A Multi-Platform Pseudo Terminal API Project Report Submitted in Partial Fulfillment for the Masters' Degree in Computer Science By Qutaiba Mahmoud Supervised By Dr. Clinton Jeffery ABSTRACT This project is the construction of a pseudo-terminal API, which will provide a pseudo-terminal interface access to interactive programs. The API is aimed at developing an extension to the Unicon language to allow Unicon programs to easily utilize applications that require user interaction via a terminal. A pseudo-terminal is a pair of virtual devices that provide a bidirectional communication channel. This project was constructed to enable an enhancement to a collaborative virtual environment, because it will allow external tools such to be utilized within the same environment. In general the purpose of this API is to allow the UNICON runtime system to act as the user via the terminal which is provided by the API, the terminal is in turn connected to a client process such as a compiler, debugger, or an editor. It can also be viewed as a way for the UNICON environment to control and customize the input and output of external programs. Table of Contents: 1. Introduction 1.1 Pseudo Terminals 1.2 Other Terminals 1.3 Relation To Other Pseudo Terminal Applications. 2. Methodology 2.1 Pseudo Terminal API Function Description 3. Results 3.1 UNIX Implementation 3.2 Windows Implementation 4. Conclusion 5. Recommendations 6. References Acknowledgments I would like to thank my advisor, Dr. Clinton Jeffery, for his support, patience and understanding. Dr. Jeffery has always been prompt in delivering and sharing his knowledge and in providing his assistance.
    [Show full text]
  • PC-BSD 9 Turns a New Page
    CONTENTS Dear Readers, Here is the November issue. We are happy that we didn’t make you wait for it as long as for October one. Thanks to contributors and supporters we are back and ready to give you some usefull piece of knowledge. We hope you will Editor in Chief: Patrycja Przybyłowicz enjoy it as much as we did by creating the magazine. [email protected] The opening text will tell you What’s New in BSD world. It’s a review of PC-BSD 9 by Mark VonFange. Good reading, Contributing: especially for PC-BSD users. Next in section Get Started you Mark VonFange, Toby Richards, Kris Moore, Lars R. Noldan, will �nd a great piece for novice – A Beginner’s Guide To PF Rob Somerville, Erwin Kooi, Paul McMath, Bill Harris, Jeroen van Nieuwenhuizen by Toby Richards. In Developers Corner Kris Moore will teach you how to set up and maintain your own repository on a Proofreaders: FreeBSD system. It’s a must read for eager learners. Tristan Karstens, Barry Grumbine, Zander Hill, The How To section in this issue is for those who enjoy Christopher J. Umina experimenting. Speed Daemons by Lars R Noldan is a very good and practical text. By reading it you can learn Special Thanks: how to build a highly available web application server Denise Ebery with advanced networking mechanisms in FreeBSD. The Art Director: following article is the �nal one of our GIS series. The author Ireneusz Pogroszewski will explain how to successfully manage and commission a DTP: complex GIS project.
    [Show full text]
  • Elinos Product Overview
    SYSGO Product Overview ELinOS 7 Industrial Grade Linux ELinOS is a SYSGO Linux distribution to help developers save time and effort by focusing on their application. Our Industrial Grade Linux with user-friendly IDE goes along with the best selection of software packages to meet our cog linux Qt LOCK customers needs, and with the comfort of world-class technical support. ELinOS now includes Docker support Feature LTS Qt Open SSH Configurator Kernel embedded Open VPN in order to isolate applications running on the same system. laptop Q Bug Shield-Virus Docker Eclipse-based QEMU-based Application Integrated Docker IDE HW Emulators Debugging Firewall Support ELINOS FEATURES MANAGING EMBEDDED LINUX VERSATILITY • Industrial Grade Creating an Embedded Linux based system is like solving a puzzle and putting • Eclipse-based IDE for embedded the right pieces together. This requires a deep knowledge of Linux’s versatility Systems (CODEO) and takes time for the selection of components, development of Board Support • Multiple Linux kernel versions Packages and drivers, and testing of the whole system – not only for newcomers. incl. Kernel 4.19 LTS with real-time enhancements With ELinOS, SYSGO offers an ‘out-of-the-box’ experience which allows to focus • Quick and easy target on the development of competitive applications itself. ELinOS incorporates the system configuration appropriate tools, such as a feature configurator to help you build the system and • Hardware Emulation (QEMU) boost your project success, including a graphical configuration front-end with a • Extensive file system support built-in integrity validation. • Application debugging • Target analysis APPLICATION & CONFIGURATION ENVIRONMENT • Runs out-of-the-box on PikeOS • Validated and tested for In addition to standard tools, remote debugging, target system monitoring and PowerPC, x86, ARM timing behaviour analyses are essential for application development.
    [Show full text]
  • The Journal of AUUG Inc. Volume 25 ¯ Number 3 September 2004
    The Journal of AUUG Inc. Volume 25 ¯ Number 3 September 2004 Features: mychart Charting System for Recreational Boats 8 Lions Commentary, part 1 17 Managing Debian 24 SEQUENT: Asynchronous Distributed Data Exchange 51 Framework News: Minutes to AUUG board meeting of 5 May 2004 13 Liberal license for ancient UNIX sources 16 First Australian UNIX Developer’s Symposium: CFP 60 First Digital Pest Symposium 61 Regulars: Editorial 1 President’s Column 3 About AUUGN 4 My Home Network 5 AUUG Corporate Members 23 A Hacker’s Diary 29 Letters to AUUG 58 Chapter Meetings and Contact Details 62 AUUG Membership AppLication Form 63 ISSN 1035-7521 Print post approved by Australia Post - PP2391500002 AUUGN The journal of AUUG Inc. Volume 25, Number 3 September 2004 Editor ial Gr eg Lehey <[email protected]> After last quarter's spectacularly late delivery of For those newcomers who don't recall the “Lions AUUGN, things aregradually getting back to nor- Book”, this is the “Commentary on the Sixth Edi- mal. I had hoped to have this on your desk by tion UNIX Operating System” that John Lions the end of September,but it wasn't to be. Given wr ote for classes at UNSW back in 1977. Suppos- that that was only a couple of weeks after the “Ju- edly they werethe most-photocopied of all UNIX- ly” edition, this doesn’t seem to be such a prob- related documents. Ihad mislaid my photocopy, lem. I'm fully expecting to get the December is- poor as it was (weren't they all?) some time earli- sue out in time to keep you from boredom over er,soIwas delighted to have an easy to read ver- the Christmas break.
    [Show full text]
  • Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO
    Filesystems HOWTO Filesystems HOWTO Table of Contents Filesystems HOWTO..........................................................................................................................................1 Martin Hinner < [email protected]>, http://martin.hinner.info............................................................1 1. Introduction..........................................................................................................................................1 2. Volumes...............................................................................................................................................1 3. DOS FAT 12/16/32, VFAT.................................................................................................................2 4. High Performance FileSystem (HPFS)................................................................................................2 5. New Technology FileSystem (NTFS).................................................................................................2 6. Extended filesystems (Ext, Ext2, Ext3)...............................................................................................2 7. Macintosh Hierarchical Filesystem − HFS..........................................................................................3 8. ISO 9660 − CD−ROM filesystem.......................................................................................................3 9. Other filesystems.................................................................................................................................3
    [Show full text]
  • Some Results Recall: FAT Properties FAT Assessment – Issues
    Recall: A Little Queuing Theory: Some Results • Assumptions: CS162 – System in equilibrium; No limit to the queue Operating Systems and – Time between successive arrivals is random and memoryless Systems Programming Queue Server Lecture 19 Arrival Rate Service Rate μ=1/Tser File Systems (Con’t), • Parameters that describe our system: MMAP, Buffer Cache – : mean number of arriving customers/second –Tser: mean time to service a customer (“m1”) –C: squared coefficient of variance = 2/m12 –μ: service rate = 1/Tser th April 11 , 2019 –u: server utilization (0u1): u = /μ = Tser • Parameters we wish to compute: Prof. Ion Stoica –Tq: Time spent in queue http://cs162.eecs.Berkeley.edu –Lq: Length of queue = Tq (by Little’s law) • Results: –Memoryless service distribution (C = 1): » Called M/M/1 queue: Tq = Tser x u/(1 – u) –General service distribution (no restrictions), 1 server: » Called M/G/1 queue: Tq = Tser x ½(1+C) x u/(1 – u)) 4/11/19 Kubiatowicz CS162 © UCB Spring 2019 Lec 19.2 Recall: FAT Properties FAT Assessment – Issues • File is collection of disk blocks • Time to find block (large files) ?? (Microsoft calls them “clusters”) FAT Disk Blocks FAT Disk Blocks • FAT is array of integers mapped • Block layout for file ??? 1-1 with disk blocks 0: 0: 0: 0: File #1 File #1 – Each integer is either: • Sequential Access ??? » Pointer to next block in file; or 31: File 31, Block 0 31: File 31, Block 0 » End of file flag; or File 31, Block 1 File 31, Block 1 » Free block flag File 63, Block 1 • Random Access ??? File 63, Block 1 • File Number
    [Show full text]
  • Virtual Memory
    M08_STAL6329_06_SE_C08.QXD 2/21/08 9:31 PM Page 345 CHAPTER VIRTUAL MEMORY 8.1 Hardware and Control Structures Locality and Virtual Memory Paging Segmentation Combined Paging and Segmentation Protection and Sharing 8.2 Operating System Software Fetch Policy Placement Policy Replacement Policy Resident Set Management Cleaning Policy Load Control 8.3 UNIX and Solaris Memory Management Paging System Kernel Memory Allocator 8.4 Linux Memory Management Linux Virtual Memory Kernel Memory Allocation 8.5 Windows Memory Management Windows Virtual Address Map Windows Paging 8.6 Summary 8.7 Recommended Reading and Web Sites 8.8 Key Terms, Review Questions, and Problems APPENDIX 8A Hash Tables 345 M08_STAL6329_06_SE_C08.QXD 2/21/08 9:31 PM Page 346 346 CHAPTER 8 / VIRTUAL MEMORY Table 8.1 Virtual Memory Terminology Virtual memory A storage allocation scheme in which secondary memory can be addressed as though it were part of main memory.The addresses a program may use to reference mem- ory are distinguished from the addresses the memory system uses to identify physi- cal storage sites, and program-generated addresses are translated automatically to the corresponding machine addresses. The size of virtual storage is limited by the ad- dressing scheme of the computer system and by the amount of secondary memory available and not by the actual number of main storage locations. Virtual address The address assigned to a location in virtual memory to allow that location to be ac- cessed as though it were part of main memory. Virtual address space The virtual storage assigned to a process. Address space The range of memory addresses available to a process.
    [Show full text]
  • Mechanism: Limited Direct Execution
    6 Mechanism: Limited Direct Execution In order to virtualize the CPU, the operating system needs to some- how share the physical CPU among many jobs running seemingly at the same time. The basic idea is simple: run one process for a little while, then run another one, and so forth. By time sharing the CPU in this manner, virtualization is achieved. There are a few challenges, however, in building such virtualiza- tion machinery. The first is performance: how can we implement vir- tualization without adding excessive overhead to the system? The second is control: how can we run processes efficiently while retain- ing control over the CPU? Control is particularly important to the OS, as it is in charge of resources; without it, a process could simply run forever and take over the machine, or access information that it shouldn’t be allowed to access. Attaining performance while main- taining control is thus one of the central challenges in building an operating system. THE CRUX: HOW TO EFFICIENTLY VIRTUALIZE THE CPU WITH CONTROL The OS must virtualize the CPU in an efficient manner, but while retaining control over the system. To do so, both hardware and op- erating systems support will be required. The OS will often use a judicious bit of hardware support in order to accomplish its work effectively. 1 2 MECHANISM:LIMITED DIRECT EXECUTION 6.1 Basic Technique: Limited Direct Execution To make a program run as fast as one might expect, not surpris- ingly OS developers came up with a simple technique, which we call limited direct execution.
    [Show full text]