DOCSLIB.ORG

The Flux OS Toolkit: Reusable Components for OS Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Flux OS Toolkit: Reusable Components for OS Implementation The Flux OS Toolkit: Reusable Components for OS Implementation Bryan Ford Kevin Van Maren Jay Lepreau Stephen Clawson Bart Robinson Jeff Turnery Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract 1 Introduction To an unappreciated degree, research both in operating As operating system functionality continues to expand systems and their programming languages has been severely and diversify, it is increasingly impractical for a small group hampered by the lack of cleanly reusable code providing to implement even a basic useful OS coreÐe.g., the func- mundanelow-levelOS infrastructuresuch as bootstrapcode tionality traditionally found in the Unix kernelÐentirely and device drivers. The Flux OS Toolkit solves this problem from scratch. Furthermore, in most research domains, only by providing a set of clean, well-documented components. a few speci®c areas provide fodder for interesting research These componentscan be used as basicbuildingblocks both topics. For example, from reading an OS conference pro- for operating systems and for booting language run-time ceedings, one might be given the impression that build- systems directly on the hardware. The toolkit's implementa- ing an OS ªonlyº involves writing a virtual memory sys- tion itself embodies reuse techniques by incorporating com- tem, an IPC system, a ®le system, a scheduler, some fast ponents such as device drivers, ®le systems, and network- local-area network code, and a pro®ler to produce nice bar ing code, unchanged, from other sources. We believe the kit charts. However, as any experienced OS builder knows, also makes feasiblethe production of highlyassured embed- many of the problems involved in building an OS have al- ded and operating systems: by enabling reuse of low-level ready been solved countless times, and just aren't interest- code, the high cost of detailed veri®cation of that code can ing to researchers. For example, any realistic OS, in or- be amortized over many systems for critical environments. der to be useful even for research, typically includes boot The OS toolkit is already heavily used in several different loader code, kernel startup code, variousdevice drivers, ker- OS and programming language projects, and has already nel printf and malloc code, a kernel debugger, etc. A catalyzed research and development that would otherwise research project starting a new OS completely from scratch never have been attempted. would invariably spend at least the ®rst six months simply writing such infrastructureªgrungeº before even starting on the interesting aspects of the OS. 1.1 Related work Most OS researchers have realized this problem of high Thisresearchwas supportedin partbytheDefenseAdvancedResearch Projects Agency,monitored by the Department of the Army under contract startup cost, and have resorted to cannibalizing BSD, Mach, number DABT63±94±C±0058, and Rome Laboratory, Air Force Material or other freely available OSes rather than reinventing the Command,USAF, underagreementnumberF30602±96±2±0269. The U.S. wheel. Mach used BSD, Linux [13], and vendors' device Government is authorized to reproduceand distribute reprints for Govern- drivers; SPIN [3] uses device drivers from FreeBSD; and mental purposes notwithstanding any copyright annotation hereon. y U.S. Department of Defense VINO [17] takes its device drivers, bootstrap code, and low- Copyright 1997IEEE. Personal use of this material is permitted. How- level support for virtual memory from NetBSD. ever, permission to reprint/republish this material for advertising or promo- While this approach saves time, the developer must man- tional purposesor for creatingnew collective worksfor resale or redistribu- tion to servers or lists, or to reuse any copyrightedcomponent of this work ually examine and dissect the old OS; it would save even in other works must be obtained from the IEEE. more time if the developer could simply obtain a set of 1 clearly-documented components. It would also enable re- in Fluke'satomicoperations[18]), which tookonlya month. search by those whose primary expertise is in areas other We have found this ability to prototype radical designs in a than operating systems, e.g., programming language re- ªrealº kernel tobe crucial to choosingdesignsthat are worth searchers who wish to explore the effects of higher-level lan- fully developing. guages runningdirectlyon the hardware. Thisis thepurpose of the Flux OS Toolkit. Recent research projects such as Exokernel [6], SPIN [3], 2 Toolkit design and VINO [17], focus on creating extensible systems which allow applications to modify the behavior of the core OS to suit their particular needs. However, these systems still de- ®ne a particular, ®xed set of ªcoreº functionality and a set of The Flux OS Toolkit is a framework and set of modular- policies by which the core can be used and extended. The ized librarycode, together withextensive documentation[9] OS Toolkit, in contrast, makes no attempt to be a useful OS for the construction of operating system kernels, servers, initself and doesnot de®neany particularset of ªcoreº func- and other core OS functionality. The goal is for develop- tionality, but merely provides a suite of components from ers to take the OS Kit and immediately have a starting point which real OSes can be built. for investigating ªrealº OS issues such as scheduling, VM, Other approaches involved creating an operating system IPC, ®le systems, or security. Researchers in programming built from a complex object-oriented framework, such as languages for systems software bene®t as well, as the toolkit in the Choices[5] or Taligent [15] work. Although such makes it easy to run language systems on the bare hardware. efforts have been in¯uential in other OS projects, such as The intention of this toolkit is not to ªwrite the OS for Spring,theydonotappear tohave been widelyused. Incon- youº; we certainly want to leave the OS writing to the OS trast, the OS Kit exhibits a less ambitious, but more prag- writer. The dividing line between the ªOSº and the ªOS matic, and we believe more effective, approach to software Toolkit,º as we see it, is basically the line between what OS design and re-use. Gabriel distinguished two approaches writers want to write and what they would otherwise have to software design and implementation, sardonically label- to write but don't really want to. Naturally this will vary ing them ªThe Right Thingº and ªWorse is Betterº [12]. among different OS groups and developers. If you really The former is characterized by interface perfection at the want to write yourown x86 protected-mode startup code, or cost of implementation complexity (e.g., Lisp with CLOS), have found a clever way to do it ªbetter,º you are perfectly whereas the latter sacri®ces interface elegance and com- free to do so and simply not use the corresponding code in pleteness for simplicity of implementation (e.g., Unix and our toolkit. However, the OS Kit is modular enough so that C). Gabriel makes a strong case that ªWorse is Betterº is the you can still easily use other parts of it to ®ll in other func- more sucessful approach, and we believe that the OS Kit ex- tional areas you don't want to have to deal with yourself (or empli®es this lesson. areas that you just don't have time to do ªyet.º) As such, the toolkit is designed to be usable either as a 1.2 Historical genesis of the OS Toolkit whole or in arbitrary subsets, as requirements dictate. It is useful not only for kernels but also for other OS-related pro- We followedthe cannibalization approach in our own OS grams, such as boot loaders or servers running on top of a research for some time. However, starting in 1995, that ap- microkernel. proach gradually evolved, resultingin what became theFlux While the OS Kit currently runs on x86 PCs, it is de- OS Toolkit, or ªOS Kitº. Because we were ®nding our ver- signed to be portable to other architectures, and most of the sion of Mach [11] too constraining a vehicle in which to OS Kit's exported interfaces are architecture-neutral. Most prototype new ideas, we developed a series of experimen- of the heavily architecture-speci®c aspects of the OS Kit are tal kernels to try out ideas before designing our Fluke ker- isolated in a single component, the low-level kernel support nel [10]. In doing so, we gradually modularized and for- library, whose purpose is to provide easy access to the raw malized the libraries of support code we developed, proto- privileged-mode hardware facilities without adding over- typing the OS Kit along the way. These experimental ker- head or obscuring the underlying abstractions. For exam- nels embodied radical changes to fundamental aspects of OS ple, on the x86, the kernel support library includes functions structure which would have been impossible to explore in to directly create and manipulate x86 page tables and seg- an existing operating system. One of these kernels explored ment registers. Other OS Kit components can, and often implementations of high performance kernel-mediated ca- do, provide higher-level architecture-neutral facilities built pabilities and IPC paths, and took about 2 weeks to develop on these low-level mechanisms; however, the architecture- from scratch; theotherexploredinterruptibilityof kernelop- speci®c interfaces always remain accessible in order to pro- erations at arbitrary points (®nding a more ®nal expression vide maximum ¯exibility. 2 3 Sample components boots from standard boot loaders is as easy as writingan or- dinary ªHello Worldº application in C. The toolkit currently contains ®fteen major libraries, The OS Kit also provides the necessary code to initialize ranging from uniprocessor and multiprocessor bootstrap and start multiple processors in a symmetric multiprocess- code, through memory management, to support for popular ing (SMP) system.
Load more

Recommended publications
  • A Programmable Microkernel for Real-Time Systems∗
    A Programmable Microkernel for Real-Time Systems∗ Christoph M. Kirsch Marco A.A. Sanvido Thomas A. Henzinger University of Salzburg VMWare Inc. EPFL and UC Berkeley [email protected] tah@epfl.ch ABSTRACT Categories and Subject Descriptors We present a new software system architecture for the im- D.4.7 [Operating Systems]: Organization and Design— plementation of hard real-time applications. The core of the Real-time systems and embedded systems system is a microkernel whose reactivity (interrupt handling as in synchronous reactive programs) and proactivity (task General Terms scheduling as in traditional RTOSs) are fully programma- Languages ble. The microkernel, which we implemented on a Strong- ARM processor, consists of two interacting domain-specific Keywords virtual machines, a reactive E (Embedded) machine and a proactive S (Scheduling) machine. The microkernel code (or Real Time, Operating System, Virtual Machine microcode) that runs on the microkernel is partitioned into E and S code. E code manages the interaction of the system 1. INTRODUCTION with the physical environment: the execution of E code is In [9], we advocated the E (Embedded) machine as a triggered by environment interrupts, which signal external portable target for compiling hard real-time code, and in- events such as the arrival of a message or sensor value, and it troduced, in [11], the S (Scheduling) machine as a universal releases application tasks to the S machine. S code manages target for generating schedules according to arbitrary and the interaction of the system with the processor: the exe- possibly non-trivial strategies such as nonpreemptive and cution of S code is triggered by hardware interrupts, which multiprocessor scheduling.
    [Show full text]
  • The Design of the EMPS Multiprocessor Executive for Distributed Computing
    The design of the EMPS multiprocessor executive for distributed computing Citation for published version (APA): van Dijk, G. J. W. (1993). The design of the EMPS multiprocessor executive for distributed computing. Technische Universiteit Eindhoven. https://doi.org/10.6100/IR393185 DOI: 10.6100/IR393185 Document status and date: Published: 01/01/1993 Document Version: Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers) Please check the document version of this publication: • A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website. • The final author version and the galley proof are versions of the publication after peer review. • The final published version features the final layout of the paper including the volume, issue and page numbers. Link to publication General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.
    [Show full text]
  • Performance Best Practices for Vmware Workstation Vmware Workstation 7.0
    Performance Best Practices for VMware Workstation VMware Workstation 7.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs. EN-000294-00 Performance Best Practices for VMware Workstation You can find the most up-to-date technical documentation on the VMware Web site at: http://www.vmware.com/support/ The VMware Web site also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected] Copyright © 2007–2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com 2 VMware, Inc. Contents About This Book 5 Terminology 5 Intended Audience 5 Document Feedback 5 Technical Support and Education Resources 5 Online and Telephone Support 5 Support Offerings 5 VMware Professional Services 6 1 Hardware for VMware Workstation 7 CPUs for VMware Workstation 7 Hyperthreading 7 Hardware-Assisted Virtualization 7 Hardware-Assisted CPU Virtualization (Intel VT-x and AMD AMD-V)
    [Show full text]
  • Chapter 1. Origins of Mac OS X
    1 Chapter 1. Origins of Mac OS X "Most ideas come from previous ideas." Alan Curtis Kay The Mac OS X operating system represents a rather successful coming together of paradigms, ideologies, and technologies that have often resisted each other in the past. A good example is the cordial relationship that exists between the command-line and graphical interfaces in Mac OS X. The system is a result of the trials and tribulations of Apple and NeXT, as well as their user and developer communities. Mac OS X exemplifies how a capable system can result from the direct or indirect efforts of corporations, academic and research communities, the Open Source and Free Software movements, and, of course, individuals. Apple has been around since 1976, and many accounts of its history have been told. If the story of Apple as a company is fascinating, so is the technical history of Apple's operating systems. In this chapter,[1] we will trace the history of Mac OS X, discussing several technologies whose confluence eventually led to the modern-day Apple operating system. [1] This book's accompanying web site (www.osxbook.com) provides a more detailed technical history of all of Apple's operating systems. 1 2 2 1 1.1. Apple's Quest for the[2] Operating System [2] Whereas the word "the" is used here to designate prominence and desirability, it is an interesting coincidence that "THE" was the name of a multiprogramming system described by Edsger W. Dijkstra in a 1968 paper. It was March 1988. The Macintosh had been around for four years.
    [Show full text]
  • Zenon Manual Programming Interfaces
    zenon manual Programming interfaces v.7.11 ©2014 Ing. Punzenberger COPA-DATA GmbH All rights reserved. Distribution and/or reproduction of this document or parts thereof in any form are permitted solely with the written permission of the company COPA-DATA. The technical data contained herein has been provided solely for informational purposes and is not legally binding. Subject to change, technical or otherwise. Contents 1. Welcome to COPA-DATA help ...................................................................................................... 6 2. Programming interfaces ............................................................................................................... 6 3. Process Control Engine (PCE) ........................................................................................................ 9 3.1 The PCE Editor ............................................................................................................................................. 9 3.1.1 The Taskmanager ....................................................................................................................... 10 3.1.2 The editing area .......................................................................................................................... 10 3.1.3 The output window .................................................................................................................... 11 3.1.4 The menus of the PCE Editor .....................................................................................................
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Operating System Architectures
    Operating System Architectures • Learning objectives: • Explain how OS functionality is orthogonal to where you place services relative to processor modes. • Describe some alternative ways to structure the operating system. • Operating systems evolve over time, but that evolution is frequently in terms of their architecture: how they structure functionality relative to protection boundaries. • We’ll review some of the basic architectures: • Executives • Monolithic kernels • Micro kernels • Exo kernels • Extensible operating systems 2/3/15 CS161 Spring 2015 1 OS Executives • Think MS-DOS: With no hardware protection, the OS is simply a set of services: • Live in memory • Applications can invoke them • Requires a software trap to invoke them. • Live in same address space as application 1-2-3 QBasic WP Applications Command Software Traps Operating System routlines 2/3/15 CS161 Spring 2015 2 Monolithic Operating System • Traditional architecture • Applications and operating system run in different address spaces. • Operating system runs in privileged mode; applications run in user mode. Applications Operating System file system processes networking Device drivers virtual memory 2/3/15 CS161 Spring 2015 3 Microkernels (late 80’s and on) • Put as little of OS as possible in privileged mode (the microkernel). • Implement most core OS services as user-level servers. • Only microkernel really knows about hardware • File system, device drivers, virtual memory all implemented in unprivileged servers. • Must use IPC (interprocess communication) to communicate among different servers. Applications Process Virtual management memory file system networking Microkernel 2/3/15 CS161 Spring 2015 4 Microkernels: Past and Present • Much research and debate in late 80’s early 90’s • Pioneering effort in Mach (CMU).
    [Show full text]
  • Microkernel Construction Introduction
    Microkernel Construction Introduction Nils Asmussen 04/09/2020 1 / 32 Normal Organization Thursday, 4th DS, 2 SWS Slides: www.tudos.org ! Studies ! Lectures ! MKC Subscribe to our mailing list: www.tudos.org/mailman/listinfo/mkc2020 In winter term: Microkernel-based operating systems (MOS) Various labs 2 / 32 Organization due to COVID-19 Slides and video recordings of lectures will be published Questions can be asked on the mailing list Subscribe to the mailing list! Practical exercises are planed for the end of the semester Depending on how COVID-19 continues, exercises are in person or we use some video-conferencing tool 3 / 32 Goals 1 Provide deeper understanding of OS mechanisms 2 Look at the implementation details of microkernels 3 Make you become enthusiastic microkernel hackers 4 Propaganda for OS research done at TU Dresden and Barkhausen Institut 4 / 32 Outline Organization Monolithic vs. Microkernel Kernel design comparison Examples for microkernel-based systems Vision vs. Reality Challenges Overview About L4/NOVA 5 / 32 Monolithic Kernel System Design u s Application Application Application e r k Kernel e r File Network n e Systems Stacks l m Memory Process o Drivers Management Management d e Hardware 6 / 32 Monolithic Kernel OS (Propaganda) System components run in privileged mode No protection between system components Faulty driver can crash the whole system Malicious app could exploit bug in faulty driver More than 2=3 of today's OS code are drivers No need for good system design Direct access to data structures Undocumented
    [Show full text]
  • Access Control for the SPIN Extensible Operating System
    Access Control for the SPIN Extensible Operating System Robert Grimm Brian N. Bershad Dept. of Computer Science and Engineering University of Washington Seattle, WA 98195, U.S.A. Extensible systems, such as SPIN or Java, raise new se- on extensions and threads, are enforced at link time (when curity concerns. In these systems, code can be added to a an extension wants to link against other extensions) and at running system in almost arbitrary fashion, and it can inter- call time (when a thread wants to call an extension). Ac- act through low latency (but type safe) interfaces with other cess restrictions on objects are enforced by the extension code. Consequently, it is necessary to devise and apply that provides an object’s abstraction (if an extension is not security mechanisms that allow the expression of policies trusted to enforce access control on its objects but is ex- controlling an extension’s access to other extensions and its pected to do so, DTE can be used to prevent other exten- ability to extend, or override, the behavior of already exist- sions from linking against the untrusted extension). ing services. In the SPIN operating system [3, 4] built at the Due to the fine grained composition of extensions in University of Washington, we are experimenting with a ver- SPIN, it is important to minimize the performance overhead sion of domain and type enforcement (DTE) [1, 2] that has of call time access control. We are therefore exploring opti- been extended to address the security concerns of extensible mization that make it possible to avoid some dynamic ac- systems.
    [Show full text]
  • Designing a Concurrent File Server
    Communicating Process Architectures 2012 1 P.H. Welch et al. (Eds.) Open Channel Publishing Ltd., 2012 c 2012 The authors and Open Channel Publishing Ltd. All rights reserved. Designing a Concurrent File Server James WHITEHEAD II Department of Computer Science, University of Oxford, Wolfson Building, Parks Road, Oxford, OX1 3QD, United Kingdom; [email protected] Abstract. In this paper we present a design and architecture for a concurrent file sys- tem server. This architecture is a compromise between the fully concurrent V6 UNIX implementation, and the simple sequential implementation in the MINIX operating system. The design of the server is made easier through the use of a disciplined model of concurrency, based on the CSP process algebra. By viewing the problem through this restricted lens, without traditional explicit locking mechanisms, we can construct the system as a process network of components with explicit connections and depen- dencies. This provides us with insight into the problem domain, and allows us to anal- yse the issues present in concurrent file system implementation. Keywords. file system, Go, CSP, UNIX, MINIX. Introduction Modern operating systems allow multiple users and programs to share the computing re- sources on a single machine. They also serve as an intermediary between programs and the physical computing hardware, such as persistent storage devices. In the UNIX family of op- erating systems, disk access is accomplished by interacting with files and directories through a hierarchical file system, using system calls. Managing access to the file system in a concurrent environment is a challenging problem. An implementation must ensure that a program cannot corrupt the state of the file system, or the data stored on disk.
    [Show full text]
  • Linux on the OSF Mach3 Microkernel
    Linux on top of the OSF Mach3 Microkernel Linux on top of the OSF Mach3 Microkernel Linux on top of OSF MK The Mach3.0 Microkernel: Design • microkernel abstractions François Barbou des Places ([email protected]) • task, thread, port, message, memory object Nick Stephen ([email protected]) • resources and services represented as ports OSF Research Institute - Grenoble • interfaces implemented via RPC to an object port Task Message • Objectives: • widen the audience for the free OSF micro-kernel Ports • provide a complete and free platform to develop new Threads servers, applications or kernel extensions • provide Apple with a freely redistributable microkernel-based operating system for the Memory Apple/PowerMac platform Object Freely Redistributable Software Conference - 5 Feb 1996 - Cambridge 1/17 Freely Redistributable Software Conference - 5 Feb 1996 - Cambridge 2/17 Linux on top of the OSF Mach3 Microkernel Linux on top of the OSF Mach3 Microkernel The Mach3.0 microkernel: Benefits OSF MK Improvements • portability (modular design) • performance • symmetric multi-processing support • kernel-loaded servers (collocation) • thread migration • scalability (from desktop PCs to high-end multi-computers) • short-circuited RPC • extensibility • real-time • OS-neutrality • preemptable kernel • support for OS personalities running as user tasks • real-time RPC, priority inheritance • pageable, preemptable • distributed system (clusters and multi-computers) • more portable: isolated from hardware • DIPC: transparent Distributed IPC • simpler:
    [Show full text]
  • Scalability of Microkernel-Based Systems
    Scalability of Microkernel-Based Systems Zur Erlangung des akademischen Grades eines DOKTORS DER INGENIERWISSENSCHAFTEN von der Fakultat¨ fur¨ Informatik der Universitat¨ Fridericiana zu Karlsruhe (TH) genehmigte DISSERTATION von Volkmar Uhlig aus Dresden Tag der mundlichen¨ Prufung:¨ 30.05.2005 Hauptreferent: Prof. Dr. rer. nat. Gerhard Goos Universitat¨ Fridericiana zu Karlsruhe (TH) Korreferent: Prof. Dr. sc. tech. (ETH) Gernot Heiser University of New South Wales, Sydney, Australia Karlsruhe: 15.06.2005 i Abstract Microkernel-based systems divide the operating system functionality into individ- ual and isolated components. The system components are subject to application- class protection and isolation. This structuring method has a number of benefits, such as fault isolation between system components, safe extensibility, co-existence of different policies, and isolation between mutually distrusting components. How- ever, such strict isolation limits the information flow between subsystems including information that is essential for performance and scalability in multiprocessor sys- tems. Semantically richer kernel abstractions scale at the cost of generality and mini- mality–two desired properties of a microkernel. I propose an architecture that al- lows for dynamic adjustment of scalability-relevant parameters in a general, flex- ible, and safe manner. I introduce isolation boundaries for microkernel resources and the system processors. The boundaries are controlled at user-level. Operating system components and applications can transform their semantic information into three basic parameters relevant for scalability: the involved processors (depending on their relation and interconnect), degree of concurrency, and groups of resources. I developed a set of mechanisms that allow a kernel to: 1. efficiently track processors on a per-resource basis with support for very large number of processors, 2.
    [Show full text]