Application Signature: a New Way to Predict Application Performance Rajat Kumar Todi Iowa State University

Total Page:16

File Type:pdf, Size:1020Kb

Application Signature: a New Way to Predict Application Performance Rajat Kumar Todi Iowa State University Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2003 Application Signature: a new way to predict application performance Rajat Kumar Todi Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Todi, Rajat Kumar, "Application Signature: a new way to predict application performance " (2003). Retrospective Theses and Dissertations. 1913. https://lib.dr.iastate.edu/rtd/1913 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Application Signature: A new way to predict application performance by Rajat Kumar Todi A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee: John Gustafson, Co-major Professor Gurpur Prabhu, Co-major Professor Don Heller Srinivas Aluru Doug Jacobson Iowa State University Ames, Iowa 2003 Copyright © Rajat Kumar Todi, 2003. All rights reserved. UMI Number: 3279645 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. UMI UMI Microform 3279645 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 ii Graduate College Iowa State University This is to certify that the doctoral dissertation of Rajat Kumar Todi has met the dissertation requirements of Iowa State University Signature was redacted for privacy. Co-major Professor Signature was redacted for privacy. Co-major Professor Signature was redacted for privacy. For thk Major Program iii TABLE OF CONTENTS List of Figures ix List of Tables xv Acknowledgments xxi Abstract xxii CHAPTER 1 Introduction 1 CHAPTER 2 Benchmarks 5 2.1 Introduction 5 2.2 User Groups of Benchmarks 7 2.3 Usefulness of Benchmarking 14 CHAPTER 3 Benchmarks Classification 15 3.1 Classification Based on Usage 15 3.2 Benchmark Strategy 16 3.3 Narrow versus Broad-spectrum Benchmark 16 3.4 Benchmark Examples 17 3.4.1 Peak Performance 17 3.4.2 Linpack 17 3.4.3 STREAM 17 3.4.4 SPEC CPU95 19 3.4.5 SPEC CPU2000 24 3.4.6 SPEC CPU2004 24 3.4.7 NPB Benchmarks 25 iv 3.4.8 SPLASH Benchmarks 27 3.4.9 GAMESS 27 3.4.10 Assorted Benchmarks 27 3.4.11 HINT 28 3.4.12 Peak FLOPS 29 3.4.13 Lawrence Livermore Loops 29 3.4.14 Whetstone 29 3.4.15 SLALOM Benchmark 30 CHAPTER 4 Common Problems with Benchmarks 31 4.1 Benchmarks Won't Follow Moore's Law 31 4.2 Benchmarks Won't Correlate With Real Applications 31 4.3 Benchmarks are Redundant 33 4.3.1 Inter-Benchmark Redundancy 34 4.3.2 Intra-Benchmark Redundancy 34 4.4 Past Benchmarks Predict Future Performance 35 4.5 Other Selected Problems of Benchmark 36 4.6 Summary 39 CHAPTER 5 Metrics 40 5.1 Characteristics of Good Performance Metrics 40 5.2 Means versus Ends Metrics 41 5.3 Uniprocessor Performance Metrics 41 5.3.1 MFLOPS 41 5.3.2 MIPS 42 5.3.3 Clock Frequency 42 5.3.4 QUIPS 42 5.4 Parallel Processing Performance Metrics 43 5.4.1 Speedup 43 5.4.2 Efficiency 44 V 5.4.3 Scalability . 45 5.5 Summary 49 CHAPTER 6 Statistical Background 50 6.1 Pearson Product Moment Correlation 50 6.2 Linear Relation 52 6.3 Spearman's Rank Correlation 52 6.3.1 A Matlab Example 53 6.4 The Harmonic Mean 54 6.5 The Weighted Harmonic Mean 55 CHAPTER 7 HINT: The Hardware Signature 57 7.1 Introduction 57 7.2 Task and Terminology 58 7.3 An Example using 8-bit Data Type 59 7.4 Salient features 62 7.5 Understanding HINT Graphs 64 7.5.1 Generic HINT Graphs 64 7.5.2 Classical Memory-Regime Revealing Graph 65 7.5.3 Varying Precision 66 7.5.4 Varying Main Memory 67 7.5.5 Varying Clock Speed 68 7.5.6 Cache-Dependent and Cache-Independent systems 68 7.5.7 Dedicated Machine versus Machine with Interrupts 69 7.5.8 Scalable Parallel Computers 70 7.5.9 Non-Scalable Parallel Computers 70 7.5.10 Special-Purpose Computer 71 7.5.11 Business computer 71 7.5.12 Serial versus Workstation Clusters 72 7.5.13 Same Machine Different Operating System 76 vi 7.5.14 Serial versus Vector Computer 76 7.5.15 Region of Computation 77 7.5.16 Superset of Other Benchmarks 78 7.5.17 Problem Detection using HINT 79 7.5.18 Identical Machines Varied Performance 80 7.5.19 Bug in Motherboard's BIOS software 81 7.5.20 Dual processors Pentium machine with Slow Memory Bandwidth .... 82 CHAPTER 8 Application Signature 85 8.1 History of Application Signature 85 8.2 What is Application Signature? 87 8.3 Characteristics of Application Signature 89 8.4 Modeling Application-Architecture Performance: A Car Transportation Analogy 90 8.5 Application Performance Model 91 8.5.1 Hardware Performance Predictors 91 8.5.2 Application Performance Predictors 93 8.5.3 The Proposed Computer Design Model 94 8.6 Experiment Setup 94 8.6.1 Machines Used 94 8.6.2 Benchmarks Used 96 8.7 Summary 97 CHAPTER 9 Definitions and Notations 99 9.1 Measured Time, APPMAP Time, and Projected Time 104 9.2 Validation Strategy for the Models 106 CHAPTER 10 Model 1: Application Signature Using Instantaneous QUIPS 107 10.1 Model 107 10.1.1 Using Instantaneous QUIPS as Application Signature 108 10.1.2 Using NetQUIPS as Application Signature 108 10.1.3 Using NetQUIPS and Instantaneous QUIPS Application Signature . 109 vii 10.1.4 Using Correlation Vector as Application Signature 109 10.2 Results 109 10.3 Summary 110 CHAPTER 11 Model 2: Application Signature Using Optimization Method 112 11.1 Model 112 11.2 Results 113 CHAPTER 12 Model 3: Application Signature Using Cache Misses 115 12.1 Model 115 12.2 Results 116 CHAPTER 13 Model 4: Application Signature Using Cache Sensitivity . 118 13.1 Model 118 13.2 Results 119 CHAPTER 14 Applications of APPMAP technology 120 14.1 System Design 120 14.2 Selecting System on Applications 121 14.3 Multiprocessor Scheduling 122 14.4 Utility based Computing 122 14.5 Power versus Performance 123 14.6 Chapter Summary 123 CHAPTER 15 Conclusion and Future Directions 125 15.1 Original Contributions of the Thesis 126 15.2 Future Directions 126 APPENDIX A Cache Memory Subsystem 129 APPENDIX B HINT Database 132 APPENDIX C Application Characteristics - I 135 APPENDIX D Application Characteristics - II 162 viii APPENDIX E Machine Characteristics using HINT 176 APPENDIX F LMBENCH . 195 APPENDIX G Machine Profile Using Stream Benchmark 201 APPENDIX H More Modell Results 211 APPENDIX I More Model2 Results 227 Bibliography 249 ix LIST OF FIGURES 1.1 Application Signature Performance Model 2 2.1 iCOMP Index 2.0 Weightings 11 4.1 Computation Chemistry vs LINPACK 32 4.2 Peak FLOPS versus EP benchmark 33 4.3 Workload Benchmarks (a) Ideal (b) Redundancy in SPEC CFP2000 Benchmarks 33 4.4 Intra-Benchmark Redundancy in SWIM benchmark of SPEC CFP2000 34 4.5 Past Benchmarks are used for Future System Design 35 4.6 Benchmarks emphasize different Problem Sizes 37 7.1 Problem Solved by HINT: Area to be Bounded under the Curve .... 58 7.2 Two Subintervals of One Dimension Integration with 8-bit Data Precision 60 7.3 Sequence of Hierarchical Refinement of Integral Bounds 61 7.4 Precision-Limited Last Iteration, 8-bit data 62 7.5 Memory Cost versus QUIPS 63 7.6 Generic HINT Graphs 65 7.7 Memory Regime Revealing Graph 66 7.8 Varying Precision 67 7.9 Varying Main Memory 68 7.10 Varying Clock Speed 69 7.11 Cache-independent and Cache-dependent System 70 7.12 Dedicated Machine versus Machine with interrupts 71 X 7.13 Scalable Parallel Computer 72 7.14 Unscalable Parallel Computer 73 7.15 Special Purpose Computer 73 7.16 Business Computer 74 7.17 Serial versus Workstation Cluster 74 7.18 Linux Cluster 75 7.19 Serial versus Workstation Cluster 76 7.20 Serial versus Vector Machine 77 7.21 Vector versus Parallel Computers 78 7.22 Region of Computation 79 7.23 Superset of Other Benchmarks 80 7.24 Identical Machine Varied Performance 81 7.25 Mosix Xluster's Identical Nodes Perform Differently 82 7.26 Bug in Alpha LX motherboard's BIOS 83 7.27 Serial versus Threaded HINT on Dual Processors 300 MHz Pentiumll 84 8.1 Hypothetical Application Signature for (a) Word Processing Applica­ tion (b) Computational Fluid Dynamic 86 8.2 Gustafson's Great Crossover: The crossover of memory and arithmetic performance 92 8.3 HINT (Double) QUIPS-Time Graph for Machines M1-M8 96 9.1 Two Different Ranking of Machines k\ and at Memory Points mi and m2.
Recommended publications
  • 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]
  • Kernel Architectures
    A short history of kernels n Early kernel: a library of device drivers, support for threads (QNX) Operating System Kernels n Monolithic kernels: Unix, VMS, OS 360… n Unstructured but fast… n Over time, became very large Ken Birman n Eventually, DLLs helped on size n Pure microkernels: Mach, Amoeba, Chorus… (borrowing some content from n OS as a kind of application Peter Sirokman) n Impure microkernels: Modern Windows OS n Microkernel optimized to support a single OS n VMM support for Unix on Windows and vice versa The great m-kernel debate Summary of First Paper n How big does it need to be? n The Performance of µ-Kernel-Based Systems (Hartig et al. 16th SOSP, Oct 1997) n With a m-kernel protection-boundary crossing forces us to n Evaluates the L4 microkernel as a basis for a full operating system n Change memory -map n Ports Linux to run on top of L4 and compares n Flush TLB (unless tagged) performance to native Linux and Linux running on n With a macro-kernel we lose structural the Mach microkernel protection benefits and fault-containment n Explores the extensibility of the L4 microkernel n Debate raged during early 1980’s Summary of Second Paper In perspective? n The Flux OSKit: A Substrate for Kernel and n L4 seeks to validate idea that a m-kernel Language Research (Ford et al. 16th SOSP, can support a full OS without terrible 1997) cost penalty n Describes a set of OS components designed to be used to build custom operating systems n Opened the door to architectures like the n Includes existing code simply using “glue code” Windows
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Common Coupling As a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of Mklinux and Darwin
    IUScholarWorks at Indiana University South Bend Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Yu, Liguo To cite this article: Yu, Liguo. “Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin.” Journal of the Brazilian Computer Society14, vol. 14, no. 1, Feb. 2008, pp. 45–55. This document has been made available through IUScholarWorks repository, a service of the Indiana University Libraries. Copyrights on documents in IUScholarWorks are held by their respective rights holder(s). Contact [email protected] for more information. Common Coupling as a Measure of Reuse Effort in Kernel-Based Software with Case Studies on the Creation of MkLinux and Darwin Liguo Yu Department of Informatics Computer and Information Sciences Department Indiana University South Bend South Bend, IN 46634, USA. Fax: 1-574-520-5589 E-mail: [email protected] The initial version of this paper appers in the 19th International Conference on Software Engineering and Knowledge Engineering. Abstract software components, which required less effort in order to be reused to produce Darwin. An obstacle to software reuse is the large number of major modifications that frequently have to be made Keywords: Reuse, common coupling, kernel-based software, as a consequence of dependencies within the reused MkLinux, Darwin software components. In this paper, common coupling is categorized and used as a measure of the dependencies 1. INTRODUCTION between software components. We compared common Software reuse has become a topic of interest within coupling in three operating systems, Linux, FreeBSD, the software community because of its potential and Mach, and related it to the reuse effort of these benefits.
    [Show full text]
  • Kernel-Based Systems
    The Performance of µ-Kernel-Based Systems Liedtke et al. presented by: Ryan O’Connor <[email protected]> October 7th, 2009 Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Motivation By this time (1997) the OS research community had virtually abandoned research on pure µ-kernels. due primarily to the poor performance of first-generation µ-kernels Many researchers believe that µ-kernel abstraction layer is either too low or too high too low: research should focus on extensible-kernels, allowing users to safely add new functionality to a monolithic kernel too high: kernels should export an interface resembling a hardware architecture Claim: pure µ-kernels are not fundamentally flawed, they just haven’t been done right yet Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems Contributions L4 and L4Linux the penalty for using a pure µ-kernel can be kept between 5% and 10% µ-kernel abstractions are efficient enough to motivate their use in user applications Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4 L4 exports a pure µ-kernel interface (threads, address spaces, and IPC). In addition it supports: user-level paging, and recursive construction of address spaces translation of hardware interrupts to IPC messages fast context switches on small address-spaces using Pentium segmentation trick Liedtke et al.presented by: Ryan O’Connor <[email protected]> The Performance of µ-Kernel-Based Systems L4Linux L4Linux is a Linux Single Server, an L4 process that provides a unix ’personality’ for user applications.
    [Show full text]
  • Popcorn Project: Starting with Popcorn OS
    Popcorn Project: Starting with Popcorn OS Antonio Barbalace [email protected] Systems Software Research Group at Virginia Tech http://ssrg.ece.vt.edu VTLUUG meeting , May 2 nd 2013 Patches 14 th Dec 2012 • Popcorn Hacking Guide – Generic modifications (all archs) • linux-3.2.14-popcorn-build.patch • linux-3.2.14-popcorn-syscall.patch • linux-3.2.14-popcorn-generic.patch – Architecture dependent in arch/x86 • linux-3.2.14-popcorn-x86-build.patch • linux-3.2.14-popcorn-x86-syscall.patch • linux-3.2.14-popcorn-x86-generic.patch • linux-3.2.14-popcorn-x86-apic.patch • linux-3.2.14-popcorn-x86-boot.patch • linux-3.2.14-popcorn-x86-vty.patch – Drivers modifications (all archs) in drivers/ • linux-3.2.14-popcorn-drivers-vty.patch • linux-3.2.14-popcorn-drivers-acpi.patch • linux-3.2.14-popcorn-drivers-gpu.patch • linux-3.2.14-popcorn-drivers-pci.patch • Goal – Release a first usable version of the project (alternative to virtual machines) – Document the project – Attract contributors and enthusiasts – Separate the architecture dependent code (initial porting guide) 2 Patches 25 th Mar 2013 • Goal – Release a new usable version of the project (replicated-kernel) – Add new components • Inter-Kernel Messaging layer • Remote process creation and migration • Other improvements and fixes 3 GIT Repositories • Hosted on TO BE ANNOUNCED – Publicly browseable, direct r/w access is protected (ssh key required) • Kernel code – TO BE ANNOUNCED – many different branches • davek – process/thread remote creation, migration • net_msg_integration – fast software network switch • shmem_tuntap – software network switch using TUN/TAP • bshelton_messaging – inter-kernel messaging layer • andy_fd_aware – NUMA aware scheduling • andy_load_balance – again, NUMA aware scheduling • mklinux-readonly – one page table per NUMA-node • etc.
    [Show full text]
  • Applications/Utilities
    [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata • Academic Mac OS X Panther for Unix Geeks By Brian Jepson, Ernest E. Rothman Publisher: O'Reilly Pub Date: February 2004 ISBN: 0-596-00607-1 Pages: 240 If you find yourself disoriented by the new Mac environment, Mac OS X Panther for Unix Geeks will get you acclimated quickly to the foreign new areas of a familiar Unix landscape. The new edition of this book is your guide to figuring out the BSD Unix system and Panther-specific components that you may find challenging. The book includes a quick manpage-style reference to the "Missing Manual Pages" --commands that come with Mac OS X Panther, although there are no manpages. [ Team LiB ] [ Team LiB ] • Table of Contents • Index • Reviews • Reader Reviews • Errata • Academic Mac OS X Panther for Unix Geeks By Brian Jepson, Ernest E. Rothman Publisher: O'Reilly Pub Date: February 2004 ISBN: 0-596-00607-1 Pages: 240 Copyright Preface Audience for This Book Organization of This Book Xcode Tools Where to Go for More Information Conventions Used in This Book Comments and Questions Acknowledgments from the Previous Edition Acknowledgments from Brian Jepson Acknowledgments from Ernest E. Rothman Part I: Getting Around Chapter 1. Inside the Terminal Section 1.1. Mac OS X Shells Section 1.2. The Terminal and xterm Compared Section 1.3. Using the Terminal Section 1.4. Customizing the Terminal Section 1.5. The Services Menu Section 1.6. Alternative Terminal Applications Section 1.7. The open Command Chapter 2. Startup Section 2.1.
    [Show full text]
  • 101 Ways to Save Apple by James Daly
    http://www.wired.com/wired/archive/5.06/apple_pr.html 101 Ways to Save Apple By James Daly An assessment of what can be done to fix a once-great company. Dear Apple, In the movie Independence Day, a PowerBook saves the earth from destruction. Now it's time to return the favor. Unfortunately, even devoted Mac addicts must admit that you look a little beleaguered these days: a confusing product line, little inspiration from the top, software developers fleeing. But who wants to live in a world without you? Not us. So we surveyed a cross section of hardcore Mac fans and came up with 101 ways to get you back on the path to salvation. We chose not to resort to time travel or regurgitate the same old shoulda/coulda/wouldas (you shoulda licensed your OS in 1987, for instance, or coulda upped your price/performance in 1993). We don't believe Apple is rotten to the core. Chrysler nearly went under in the late 1970s and came back to lead its industry. Here's a fresh assessment of what can be done to fix your once-great company using the material at hand. Don't wait for a miracle. You have the power to save the world - and yourself. Edited by James Daly 1. Admit it. You're out of the hardware game. Outsource your hardware production, or scrap it entirely, to compete more directly with Microsoft without the liability of manufacturing boxes. 2. License the Apple name/technology to appliance manufacturers and build GUIs for every possible device - from washing machines to telephones to WebTV.
    [Show full text]
  • Contents of Lecture 8 on UNIX History
    Contents of Lecture 8 on UNIX History Before UNIX Origin of UNIX Commerical wars and other threats Linux Game over. UNIX won. Continued work by the original UNIX team: Plan 9 and Inferno Microkernels vs Monolithic kernels and other issues. Jonas Skeppstedt ([email protected]) Lecture 8 2014 1 / 67 CTSS The Compatible Time-Sharing System was designed at MIT in the early 1960s. Supported up to 32 simultanously logged in users: proof of the time-sharing idea. Ran on IBM 7090 with 32K 36 bit words, of which the monitor used 5K. User programs were swapped in from a magnetic drum (disk). Multilevel feedback scheduling queue. Higher priorities have shorter time quantum Initial priority (quantum) reflects size of the executable file so it can be swapped in and run. CTSS was extremely successful and used as late as 1972: basis for MULTICS. Jonas Skeppstedt ([email protected]) Lecture 8 2014 2 / 67 MULTICS Multiplexed Information and Computing Ser vice designed by MIT, AT&T, and GE. AT&T and GE provided telephone and electricity ser vices as utilities. GE also produced computers, eg the GE-645 used in MULTICS development. Why not do the same with computing power? The goal was one computer for 100,000s users in Boston (on hardware equivalent to about 386 or 486). Designed as an extension to CTSS with virtual memory and sophisticated protection (more levels than UNIX user vs superuser). MULTICS was written in PL/1 and consisted of about 300,000 lines. Jonas Skeppstedt ([email protected]) Lecture 8 2014 3 / 67 End of MULTICS Lots of people were very enthusiastic about MULTICS, including the newly graduated Ken Thompson from Berkeley.
    [Show full text]
  • Microkernels: Mach and L4
    Microkernels: Mach and L4 Presented by Jason Wu With content borrowed from Dan Williams (2009) and Hakim Weatherspoon (2008) Outline • Introduction to Kernels • 1st Generation Microkernels – Mach • 2nd Generation Microkernels – L4 • Conclusions Introduction to Kernels • Different Types of Kernel Designs – Monolithic kernel – Microkernel – Hybrid Kernel – Exokernel – Virtual Machines? Monolithic Kernels • All OS services operate in kernel space • Good performance • Disadvantages – Dependencies between system component – Complex & huge (millions(!) of lines of code) – Larger size makes it hard to maintain • E.g. Multics, Unix, BSD, Linux Microkernels • Minimalist approach – IPC, virtual memory, thread scheduling • Put the rest into user space – Device drivers, networking, file system, user interface • More stable with less services in kernel space • Disadvantages – Lots of system calls and context switches • E.g. Mach, L4, AmigaOS, Minix, K42 Monolithic Kernels VS Microkernels Hybrid Kernels • Combine the best of both worlds – Speed and simple design of a monolithic kernel – Modularity and stability of a microkernel • Still similar to a monolithic kernel – Disadvantages still apply here • E.g. Windows NT, NetWare, BeOS Exokernels • Follows end-to-end principle – Extremely minimal – Fewest hardware abstractions as possible – Just allocates physical resources to apps • Disadvantages – More work for application developers • E.g. Nemesis, ExOS • Next Thursday! The Microkernel Debate • How big should it be? • Big debate during the 1980’s Summary:
    [Show full text]
  • The Performance of Μ-Kernel-Based Systems
    16th ACM Symposium on Operating Systems Principles (SOSP ’97), October 5–8, 1997, Saint-Malo, France The Performance of µ-Kernel-Based Systems Hermann Hartig¨ Michael Hohmuth Jochen Liedtke Sebastian Schonber¨ g Jean Wolter Dresden University of Technology IBM T. J. Watson Research Center Department of Computer Science 30 Saw Mill River Road D-01062 Dresden, Germany Hawthorne, NY 10532, USA email: [email protected] email: [email protected] based on pure µ-kernels, i. e. kernels that provide only ad- dress spaces, threads and IPC, or an equivalent set of primi- tives. This trend is due primarily to the poor performance ex- Abstract hibited by such systems constructed in the 1980’s and early 1990’s. This reputation has not changed even with the advent First-generation µ-kernels have a reputation for being too of faster µ-kernels; perhaps because these µ-kernel have for slow and lacking sufficient flexibility. To determine whether the most part only been evaluated using microbenchmarks. L4, a lean second-generation µ-kernel, has overcome these limitations, we have repeated several earlier experiments and Many people in the OS research community have adopted conducted some novel ones. Moreover, we ported the Linux the hypothesis that the layer of abstraction provided by pure operating system to run on top of the L4 µ-kernel and com- µ-kernels is either too low or too high. The “too low” fac- pared the resulting system with both Linux running native, tion concentrated on the extensible-kernel idea. Mechanisms and MkLinux, a Linux version that executes on top of a first- were introduced to add functionality to kernels and their ad- generation Mach-derived µ-kernel.
    [Show full text]
  • The Linux Kernel: Configuring the Kernel Part 22
    The Linux Kernel: Configuring the Kernel Part 22 In this article, we will continue to configure the kernel hacks and then we will configure the whole security system. The next feature to configure is needed by Alpha and s390 processor (Force weak per­cpu definitions). This feature offers a fix for an addressing issue commonly seen in such processors. Other processors do not need this feature enabled. Kernel dumps can be tested with this special debugging tool (Linux Kernel Dump Test Tool Module). This software will allow a kernel developer to trigger a fake error that will cause a kernel dump. The kernel developers can then ensure that the dumps complete successfully. The kernel offers some different error injection modules that allow kernel developers to test the notifiers (CPU notifier error injection module), (PM notifier error injection module), and (Memory hotplug notifier error injection module). A notifier informs the system that the hardware is present, which is important for hotplugging. These error injection modules trigger an error in this notification system so developers can test the notification system's error handling abilities. The "Fault­injection framework" driver offers various tools for testing fault­handling. The "Latency measuring infrastructure" driver provides the LatencyTOP tool used to find the userspace object that is blocking/interfering with a kernel execution/task. Next, we have a sub­menu titled "Tracers" that contains a list of various tracers. A tracer is a piece of code that watches various kernel functions. Every time a particular function starts, a tracer will be called to watch the function.
    [Show full text]