DOCSLIB.ORG

Understanding the Linux® Virtual Memory Manager BRUCE PERENS’ OPEN SOURCE SERIES

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Understanding the Linux® Virtual Memory Manager BRUCE PERENS’ OPEN SOURCE SERIES Understanding the Linux® Virtual Memory Manager BRUCE PERENS’ OPEN SOURCE SERIES http://www.phptr.com/perens ♦ C++ GUI Programming with Qt 3 Jasmin Blanchette, Mark Summerfield ♦ Managing Linux Systems with Webmin: System Administration and Module Development Jamie Cameron ♦ Understanding the Linux Virtual Memory Manager Mel Gorman ♦ Implementing CIFS: The Common Internet File System Christopher R. Hertel ♦ Embedded Software Development with eCos Anthony J. Massa ♦ Rapid Application Development with Mozilla Nigel McFarlane ♦ The Linux Development Platform: Configuring, Using, and Maintaining a Complete Programming Environment Rafeeq Ur Rehman, Christopher Paul ♦ Intrusion Detection Systems with Snort: Advanced IDS Techniques with Snort, Apache, MySQL, PHP, and ACID Rafeeq Ur Rehman ♦ The Official Samba-3 HOWTO and Reference Guide John H. Terpstra, Jelmer R. Vernooij, Editors ♦ Samba-3 by Example: Practical Exercises to Successful Deployment John H. Terpstra Understanding the Linux® Virtual Memory Manager Mel Gorman PRENTICE HALL PROFESSIONAL TECHNICAL REFERENCE UPPER SADDLE RIVER,NJ07458 WWW.PHPTR.COM Library of Congress Cataloging-in-Publication Data Gorman, Mel. Understanding the Linux Virtual Memory Manager / Mel Gorman. p. cm.—(Bruce Perens’ Open source series) Includes bibliographical references and index. ISBN 0-13-145348-3 1. Linux. 2. Virtual computer systems. 3. Virtual storage (Computer science) I. Title. II. Series. QA76.9.V5G67 2004 005.4’3—dc22 2004043864 Editorial/production supervision: Jane Bonnell Composition: TechBooks Cover design director: Jerry Votta Manufacturing buyer: Maura Zaldivar Executive Editor: Mark L. Taub Editorial assistant: Noreen Regina Marketing manager: Dan DePasquale c 2004 Pearson Education, Inc. Publishing as Prentice Hall Professional Technical Reference Upper Saddle River, New Jersey 07458 This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). Prentice Hall PTR offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact: U.S. Corporate and Government Sales, 1-800-382-3419, [email protected]. For sales outside of the U.S., please contact: International Sales, 1-317-581-3793, [email protected]. Company and product names mentioned herein are the trademarks or registered trademarks of their respective owners. Printed in the United States of America First Printing ISBN 0-13-145348-3 Pearson Education LTD. Pearson Education Australia PTY, Limited Pearson Education South Asia Pte. Ltd. Pearson Education Asia Ltd. Pearson Education Canada, Ltd. Pearson Educación de Mexico, S.A. de C.V. Pearson Education—Japan Pearson Malaysia SDN BHD To John O’Gorman (RIP) for teaching me the joys of operating systems and for making memory management interesting. To my parents and family for their continuous support of my work. To Karen for making all the work seem worthwhile. Contents PREFACE xiii 1INTRODUCTION 1 1.1 Getting Started 2 1.2 Managing the Source 4 1.3 Browsing the Code 9 1.4 Reading the Code 11 1.5 Submitting Patches 12 2DESCRIBING PHYSICAL MEMORY 15 2.1 Nodes 16 2.2 Zones 18 2.3 Zone Initialization 23 2.4 Initializing mem map 24 2.5 Pages 24 2.6 Mapping Pages to Zones 29 2.7 High Memory 29 2.8 What’s New in 2.6 30 3PAGETABLE MANAGEMENT 33 3.1 Describing the Page Directory 33 3.2 Describing a Page Table Entry 36 3.3 Using Page Table Entries 37 3.4 Translating and Setting Page Table Entries 39 3.5 Allocating and Freeing Page Tables 39 3.6 Kernel Page Tables 40 3.7 Mapping Addresses to a struct page 42 3.8 Translation Lookaside Buffer (TLB) 43 vii viii Contents 3.9 Level 1 CPU Cache Management 44 3.10 What’s New in 2.6 47 4PROCESS ADDRESS SPACE 53 4.1 Linear Address Space 53 4.2 Managing the Address Space 55 4.3 Process Address Space Descriptor 57 4.4 Memory Regions 61 4.5 Exception Handling 79 4.6 Page Faulting 80 4.7 Copying to/from Userspace 87 4.8 What’s New in 2.6 90 5BOOT MEMORY ALLOCATOR 95 5.1 Representing the Boot Map 96 5.2 Initializing the Boot Memory Allocator 98 5.3 Initializing bootmem data 98 5.4 Allocating Memory 99 5.5 Freeing Memory 100 5.6 Retiring the Boot Memory Allocator 101 5.7 What’s New in 2.6 102 6 PHYSICAL PAGE ALLOCATION 105 6.1 Managing Free Blocks 105 6.2 Allocating Pages 106 6.3 Free Pages 109 6.4 Get Free Page (GFP) Flags 110 6.5 Process Flags 111 6.6 Avoiding Fragmentation 112 6.7 What’s New in 2.6 113 7 NONCONTIGUOUS MEMORY ALLOCATION 117 7.1 Describing Virtual Memory Areas 117 7.2 Allocating a Noncontiguous Area 118 7.3 Freeing a Noncontiguous Area 120 7.4 What’s New in 2.6 121 8SLABALLOCATOR 123 8.1 Caches 125 8.2 Slabs 137 Contents ix 8.3 Objects 144 8.4 Sizes Cache 146 8.5 Per-CPU Object Cache 148 8.6 Slab Allocator Initialization 150 8.7 Interfacing With the Buddy Allocator 151 8.8 What’s New in 2.6 151 9HIGHMEMORYMANAGEMENT 153 9.1 Managing the PKMap Address Space 153 9.2 Mapping High Memory Pages 154 9.3 Unmapping Pages 156 9.4 Mapping High Memory Pages Atomically 156 9.5 Bounce Buffers 157 9.6 Emergency Pools 159 9.7 What’s New in 2.6 160 10 PAGE FRAME RECLAMATION 163 10.1 Page Replacement Policy 164 10.2 Page Cache 165 10.3 LRU Lists 169 10.4 Shrinking All Caches 173 10.5 Swapping Out Process Pages 173 10.6 Pageout Daemon (kswapd) 175 10.7 What’s New in 2.6 177 11 SWAP MANAGEMENT 179 11.1 Describing the Swap Area 180 11.2 Mapping Page Table Entries to Swap Entries 183 11.3 Allocating a Swap Slot 184 11.4 Swap Cache 185 11.5 Reading Pages From Backing Storage 189 11.6 Writing Pages to Backing Storage 189 11.7 Reading/Writing Swap Area Blocks 192 11.8 Activating a Swap Area 192 11.9 Deactivating a Swap Area 193 11.10 What’s New in 2.6 194 12 SHARED MEMORY VIRTUAL FILESYSTEM 195 12.1 Initializing the Virtual Filesystem 196 12.2 Using shmem Functions 197 x Contents 12.3 Creating Files in tmpfs 199 12.4 Page Faulting Within a Virtual File 201 12.5 File Operations in tmpfs 203 12.6 Inode Operations in tmpfs 203 12.7 Setting Up Shared Regions 204 12.8 System V IPC 204 12.9 What’s New in 2.6 207 13 OUT OF MEMORY MANAGEMENT 209 13.1 Checking Available Memory 209 13.2 Determining OOM Status 210 13.3 Selecting a Process 211 13.4 Killing the Selected Process 211 13.5 Is That It? 211 13.6 What’s New in 2.6 211 14 THE FINAL WORD 213 CODE COMMENTARY AINTRODUCTION 217 BDESCRIBING PHYSICAL MEMORY 219 B.1 Initializing Zones 220 B.2 Page Operations 234 CPAGETABLE MANAGEMENT 239 C.1 Page Table Initialization 240 C.2 Page Table Walking 248 DPROCESS ADDRESS SPACE 251 D.1 Process Memory Descriptors 254 D.2 Creating Memory Regions 261 D.3 Searching Memory Regions 309 D.4 Locking and Unlocking Memory Regions 315 D.5 Page Faulting 328 D.6 Page-Related Disk I/O 355 EBOOT MEMORY ALLOCATOR 395 E.1 Initializing the Boot Memory Allocator 396 Contents xi E.2 Allocating Memory 399 E.3 Freeing Memory 409 E.4 Retiring the Boot Memory Allocator 411 F PHYSICAL PAGE ALLOCATION 419 F.1 Allocating Pages 420 F.2 Allocation Helper Functions 433 F.3 Free Pages 435 F.4 Free Helper Functions 440 G NONCONTIGUOUS MEMORY ALLOCATION 441 G.1 Allocating a Noncontiguous Area 442 G.2 Freeing a Noncontiguous Area 452 HSLABALLOCATOR 457 H.1 Cache Manipulation 459 H.2 Slabs 479 H.3 Objects 486 H.4 Sizes Cache 501 H.5 Per-CPU Object Cache 504 H.6 Slab Allocator Initialization 511 H.7 Interfacing with the Buddy Allocator 512 IHIGHMEMORYMANAGEMENT 513 I.1 Mapping High Memory Pages 514 I.2 Mapping High Memory Pages Atomically 519 I.3 Unmapping Pages 521 I.4 Unmapping High Memory Pages Atomically 523 I.5 Bounce Buffers 524 I.6 Emergency Pools 532 JPAGEFRAME RECLAMATION 535 J.1 Page Cache Operations 537 J.2 LRU List Operations 547 J.3 Refilling inactive list 552 J.4 Reclaiming Pages From the LRU Lists 554 J.5 Shrinking All Caches 562 J.6 Swapping Out Process Pages 566 J.7 Page Swap Daemon 577 xii Contents KSWAPMANAGEMENT 583 K.1 Scanning for Free Entries 585 K.2 Swap Cache 590 K.3 Swap Area I/O 597 K.4 Activating a Swap Area 607 K.5 Deactivating a Swap Area 619 L SHARED MEMORY VIRTUAL FILESYSTEM 633 L.1 Initializing shmfs 635 L.2 Creating Files in tmpfs 641 L.3 File Operations in tmpfs 645 L.4 Inode Operations in tmpfs 659 L.5 Page Faulting Within a Virtual File 668 L.6 Swap Space Interaction 679 L.7 Setting Up Shared Regions 686 L.8 System V IPC 689 MOUTOFMEMORY MANAGEMENT 697 M.1 Determining Available Memory 698 M.2 Detecting and Recovering From OOM 700 REFERENCES 707 CODE COMMENTARY INDEX 711 INDEX 717 ABOUT THE AUTHOR 729 Preface Linux is developed with a stronger practical emphasis than a theoretical one. When new algorithms or changes to existing implementations are suggested, it is common to request code to match the argument.
Load more

Recommended publications
  • Analysing Aliasing in Java Applications
    IT 20 048 Examensarbete 15 hp Augusti 2020 Analysing Aliasing in Java Applications Björn Berggren Institutionen för informationsteknologi Department of Information Technology Abstract Analysing Aliasing in Java Applications Björn Berggren Teknisk- naturvetenskaplig fakultet UTH-enheten Aliasing refers to the possibility of having multiple references to the same memory location and is a cornerstone concept in the imperative programming paradigm. As Besöksadress: applications grow large, it is hard for programmers to keep track of all places in the Ångströmlaboratoriet Lägerhyddsvägen 1 code where they employ aliasing, possibly resulting in hard-to-predict runtime errors. Hus 4, Plan 0 I present a tool, model and query language to perform dynamic aliasing analysis on Java programs. The tool uses the model to simulate the full execution of a program, Postadress: including how and when objects and references between them are created and Box 536 751 21 Uppsala removed. The query language consists of constructs that can be nested to form logical expressions, operating on the model to check whether a certain object remains in a Telefon: certain condition throughout the execution. The language is designed to monitor 018 – 471 30 03 lifetimes of specific objects and collect information about the execution as a whole. I Telefax: performed an experiment using the tool, examining traces from programs for 018 – 471 30 00 profiling, searching and parsing, showing that applications have different aliasing behaviour. All programs mostly use objects based on built-in Java classes, indicating Hemsida: that programmers could benefit from gaining the ability to control and limit how such http://www.teknat.uu.se/student objects can be aliased.
    [Show full text]
  • Better Performance Through a Disk/Persistent-RAM Hybrid Design
    The Conquest File System: Better Performance Through a Disk/Persistent-RAM Hybrid Design AN-I ANDY WANG Florida State University GEOFF KUENNING Harvey Mudd College PETER REIHER, GERALD POPEK University of California, Los Angeles ________________________________________________________________________ Modern file systems assume the use of disk, a system-wide performance bottleneck for over a decade. Current disk caching and RAM file systems either impose high overhead to access memory content or fail to provide mechanisms to achieve data persistence across reboots. The Conquest file system is based on the observation that memory is becoming inexpensive, which enables all file system services to be delivered from memory, except providing large storage capacity. Unlike caching, Conquest uses memory with battery backup as persistent storage, and provides specialized and separate data paths to memory and disk. Therefore, the memory data path contains no disk-related complexity. The disk data path consists of only optimizations for the specialized disk usage pattern. Compared to a memory-based file system, Conquest incurs little performance overhead. Compared to several disk-based file systems, Conquest achieves 1.3x to 19x faster memory performance, and 1.4x to 2.0x faster performance when exercising both memory and disk. Conquest realizes most of the benefits of persistent RAM at a fraction of the cost of a RAM-only solution. Conquest also demonstrates that disk-related optimizations impose high overheads for accessing memory content in a memory-rich environment. Categories and Subject Descriptors: D.4.2 [Operating Systems]: Storage Management—Storage Hierarchies; D.4.3 [Operating Systems]: File System Management—Access Methods and Directory Structures; D.4.8 [Operating Systems]: Performance—Measurements General Terms: Design, Experimentation, Measurement, and Performance Additional Key Words and Phrases: Persistent RAM, File Systems, Storage Management, and Performance Measurement ________________________________________________________________________ 1.
    [Show full text]
  • Virtual Memory
    Chapter 4 Virtual Memory Linux processes execute in a virtual environment that makes it appear as if each process had the entire address space of the CPU available to itself. This virtual address space extends from address 0 all the way to the maximum address. On a 32-bit platform, such as IA-32, the maximum address is 232 − 1or0xffffffff. On a 64-bit platform, such as IA-64, this is 264 − 1or0xffffffffffffffff. While it is obviously convenient for a process to be able to access such a huge ad- dress space, there are really three distinct, but equally important, reasons for using virtual memory. 1. Resource virtualization. On a system with virtual memory, a process does not have to concern itself with the details of how much physical memory is available or which physical memory locations are already in use by some other process. In other words, virtual memory takes a limited physical resource (physical memory) and turns it into an infinite, or at least an abundant, resource (virtual memory). 2. Information isolation. Because each process runs in its own address space, it is not possible for one process to read data that belongs to another process. This improves security because it reduces the risk of one process being able to spy on another pro- cess and, e.g., steal a password. 3. Fault isolation. Processes with their own virtual address spaces cannot overwrite each other’s memory. This greatly reduces the risk of a failure in one process trig- gering a failure in another process. That is, when a process crashes, the problem is generally limited to that process alone and does not cause the entire machine to go down.
    [Show full text]
  • Automatic Detection of Bad Smells in Code: an Experimental Assessment
    Journal of Object Technology Published by AITO — Association Internationale pour les Technologies Objets, c JOT 2011 Online at http://www.jot.fm. Automatic detection of bad smells in code: An experimental assessment Francesca Arcelli Fontanaa Pietro Braionea Marco Zanonia a. DISCo, University of Milano-Bicocca, Italy Abstract Code smells are structural characteristics of software that may indicate a code or design problem that makes software hard to evolve and maintain, and may trigger refactoring of code. Recent research is active in defining automatic detection tools to help humans in finding smells when code size becomes unmanageable for manual review. Since the definitions of code smells are informal and subjective, assessing how effective code smell detection tools are is both important and hard to achieve. This paper reviews the current panorama of the tools for automatic code smell detection. It defines research questions about the consistency of their responses, their ability to expose the regions of code most affected by structural decay, and the relevance of their responses with respect to future software evolution. It gives answers to them by analyzing the output of four representative code smell detectors applied to six different versions of GanttProject, an open source system written in Java. The results of these experiments cast light on what current code smell detection tools are able to do and what the relevant areas for further improvement are. Keywords code smells; code smell detection tools; refactoring; software quality evaluation. 1 Introduction Nowadays there is an increasing number of software analysis tools available for detecting bad programming practices, highlighting anomalies, and in general increasing the awareness of the software engineer about the structural features of the program under development.
    [Show full text]
  • Preliminary Report on Empirical Study of Repeated Fragments in Internal Documentation
    Proceedings of the Federated Conference on Computer Science DOI: 10.15439/2016F524 and Information Systems pp. 1573–1576 ACSIS, Vol. 8. ISSN 2300-5963 Preliminary Report on Empirical Study of Repeated Fragments in Internal Documentation Milan Nosál’, Jaroslav Porubän Department of Computers and Informatics, Faculty of Electrical Engineering and Informatics, Technical University of Košice Letná 9, 042 00, Košice, Slovakia Email: [email protected], [email protected] Abstract—In this paper we present preliminary results of an safe and therefore the programmer has to pay extra caution empirical study, in which we used copy/paste detection (PMD when using it in multithreaded systems (she has to use Event CPD implementation) to search for repeating documentation Dispatch Thread to safely work with the Swing components). fragments. The study was performed on 5 open source projects, including Java 8 SDK sources. The study shows that there are Swing JavaDoc documents it and for each affected class many occurrences of copy-pasting documentation fragments in includes a warning (see JPanel documentation in Figure 1). the internal documentation, e.g., copy-pasted method parameter description. Besides these, many of the copy-pasted fragments express some domain or design concern, e.g., that the method is obsolete and deprecated. Therefore the study indicates that the cross-cutting concerns are present in the internal documentation in form of documentation phrases. I. INTRODUCTION RESERVING and comprehending developer’s concerns P (intents) in the source code is still a current challenge in software development [1], [2], [3], [4]. In this paper we analyze the internal documentation (source code comments, JavaDoc, etc.) to recognize repeating documentation fragments that document those concerns (or features [5]).
    [Show full text]
  • SFLC V Conservancy
    Trademark Trial and Appeal Board Electronic Filing System. http://estta.uspto.gov ESTTA Tracking number: ESTTA863914 Filing date: 12/11/2017 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE TRADEMARK TRIAL AND APPEAL BOARD Proceeding 92066968 Party Defendant Software Freedom Conservancy Correspondence PAMELA S CHESTECK Address CHESTEK LEGAL P O BOX 2492 RALEIGH, NC 27602 UNITED STATES Email: [email protected] Submission Motion for Summary Judgment Yes, the Filer previously made its initial disclosures pursuant to Trademark Rule 2.120(a); OR the motion for summary judgment is based on claim or issue pre- clusion, or lack of jurisdiction. The deadline for pretrial disclosures for the first testimony period as originally set or reset: 07/20/2018 Filer's Name Pamela S Chestek Filer's email [email protected] Signature /Pamela S Chestek/ Date 12/11/2017 Attachments Motion for SJ on affirmative defenses-signed.pdf(756280 bytes ) Kuhn-Declara- tion_summary-judgment_as-submitted_reduced-size-signed.pdf(2181238 bytes ) Sandler-declara- tion_summary-judgment_as-submitted-reduced-size-signed.pdf(1777273 bytes ) Chestek declaration_summary-judgment-signed-with-exhibits.pdf(2003142 bytes ) IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE TRADEMARK TRIAL AND APPEAL BOARD In the Mater of Registraion No. 4212971 Mark: SOFTWARE FREEDOM CONSERVANCY Registraion date: September 25, 2012 Sotware Freedom Law Center Peiioner, v. Cancellaion No. 92066968 Sotware Freedom Conservancy Registrant. RESPONDENT’S MOTION FOR SUMMARY JUDGMENT ON ITS AFFIRMATIVE DEFENSES Introducion The Peiioner, Sotware Freedom Law Center (“SFLC”), is a provider of legal services. It had the idea to create an independent enity that would ofer inancial and administraive services for free and open source sotware projects.
    [Show full text]
  • Memory Protection at Option
    Memory Protection at Option Application-Tailored Memory Safety in Safety-Critical Embedded Systems – Speicherschutz nach Wahl Auf die Anwendung zugeschnittene Speichersicherheit in sicherheitskritischen eingebetteten Systemen Der Technischen Fakultät der Universität Erlangen-Nürnberg zur Erlangung des Grades Doktor-Ingenieur vorgelegt von Michael Stilkerich Erlangen — 2012 Als Dissertation genehmigt von der Technischen Fakultät Universität Erlangen-Nürnberg Tag der Einreichung: 09.07.2012 Tag der Promotion: 30.11.2012 Dekan: Prof. Dr.-Ing. Marion Merklein Berichterstatter: Prof. Dr.-Ing. Wolfgang Schröder-Preikschat Prof. Dr. Michael Philippsen Abstract With the increasing capabilities and resources available on microcontrollers, there is a trend in the embedded industry to integrate multiple software functions on a single system to save cost, size, weight, and power. The integration raises new requirements, thereunder the need for spatial isolation, which is commonly established by using a memory protection unit (MPU) that can constrain access to the physical address space to a fixed set of address regions. MPU-based protection is limited in terms of available hardware, flexibility, granularity and ease of use. Software-based memory protection can provide an alternative or complement MPU-based protection, but has found little attention in the embedded domain. In this thesis, I evaluate qualitative and quantitative advantages and limitations of MPU-based memory protection and software-based protection based on a multi-JVM. I developed a framework composed of the AUTOSAR OS-like operating system CiAO and KESO, a Java implementation for deeply embedded systems. The framework allows choosing from no memory protection, MPU-based protection, software-based protection, and a combination of the two.
    [Show full text]
  • Chapter 3. Booting Operating Systems
    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
    [Show full text]
  • Evaluating Dependency Based Package-Level Metrics for Multi-Objective Maintenance Tasks
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 8, No. 10, 2017 Evaluating Dependency based Package-level Metrics for Multi-objective Maintenance Tasks Mohsin Shaikh Adil Ansari Kashif Memon Qaid-e-Awam University Qaid-e-Awam University UCET, The Islamia University of Engineering Science of Engineering Science of Bahwalpur and Technology, Nawabshah and Technology, Nawabshah Akhtar Hussain Jalbani Ahmed Ali Qaid-e-Awam University Qaid-e-Awam University of Engineering Science of Engineering Science and Technology, Nawabshah and Technology, Nawabshah Abstract—Role of packages in organization and maintenance determine quality attributes of object oriented source code of software systems has acquired vital importance in recent [3], [4]. Conventionally, software evolution process has been research of software quality. With an advancement in modu- subject to structural and architectural changes in the source larization approaches of object oriented software, packages are code, targeting suitable and organized placement of classes widely considered as re-usable and maintainable entities of object- in particular. However, such re-factoring practices can cause oriented software architectures, specially to avoid complicated de- drift and deterioration in modularization quality of software pendencies and insure software design of well identified services. In this context, recently research study of H. Abdeen on automatic [5]. Consequently, to insure flexible software modularization, optimization of package dependencies
    [Show full text]
  • ELF1 7D Virtual Memory
    ELF1 7D Virtual Memory Young W. Lim 2021-07-06 Tue Young W. Lim ELF1 7D Virtual Memory 2021-07-06 Tue 1 / 77 Outline 1 Based on 2 Virtual memory Virtual Memory in Operating System Physical, Logical, Virtual Addresses Kernal Addresses Kernel Logical Address Kernel Virtual Address User Virtual Address User Space Young W. Lim ELF1 7D Virtual Memory 2021-07-06 Tue 2 / 77 Based on "Study of ELF loading and relocs", 1999 http://netwinder.osuosl.org/users/p/patb/public_html/elf_ relocs.html I, the copyright holder of this work, hereby publish it under the following licenses: GNU head Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. CC BY SA This file is licensed under the Creative Commons Attribution ShareAlike 3.0 Unported License. In short: you are free to share and make derivative works of the file under the conditions that you appropriately attribute it, and that you distribute it only under a license compatible with this one. Young W. Lim ELF1 7D Virtual Memory 2021-07-06 Tue 3 / 77 Compling 32-bit program on 64-bit gcc gcc -v gcc -m32 t.c sudo apt-get install gcc-multilib sudo apt-get install g++-multilib gcc-multilib g++-multilib gcc -m32 objdump -m i386 Young W.
    [Show full text]
  • Linux at 25 PETERHISTORY H
    Linux at 25 PETERHISTORY H. SALUS Peter H. Salus is the author of A n June 1991, at the USENIX conference in Nashville, BSD NET-2 was Quarter Century of UNIX (1994), announced. Two months later, on August 25, Linus Torvalds announced Casting the Net (1995), and The his new operating system on comp.os.minix. Today, Android, Google’s Daemon, the Gnu and the Penguin I (2008). [email protected] version of Linux, is used on over two billion smartphones and other appli- ances. In this article, I provide some history about the early years of Linux. Linus was born into the Swedish minority of Finland (about 5% of the five million Finns). He was a “math guy” throughout his schooling. Early on, he “inherited” a Commodore VIC- 20 (released in June 1980) from his grandfather; in 1987 he spent his savings on a Sinclair QL (released in January 1984, the “Quantum Leap,” with a Motorola 68008 running at 7.5 MHz and 128 kB of RAM, was intended for small businesses and the serious hobbyist). It ran Q-DOS, and it was what got Linus involved: One of the things I hated about the QL was that it had a read-only operating system. You couldn’t change things ... I bought a new assembler ... and an editor.... Both ... worked fine, but they were on the microdrives and couldn’t be put on the EEPROM. So I wrote my own editor and assembler and used them for all my programming. Both were written in assembly language, which is incredibly stupid by today’s standards.
    [Show full text]
  • HALO: Post-Link Heap-Layout Optimisation
    HALO: Post-Link Heap-Layout Optimisation Joe Savage Timothy M. Jones University of Cambridge, UK University of Cambridge, UK [email protected] [email protected] Abstract 1 Introduction Today, general-purpose memory allocators dominate the As the gap between memory and processor speeds continues landscape of dynamic memory management. While these so- to widen, efficient cache utilisation is more important than lutions can provide reasonably good behaviour across a wide ever. While compilers have long employed techniques like range of workloads, it is an unfortunate reality that their basic-block reordering, loop fission and tiling, and intelligent behaviour for any particular workload can be highly subop- register allocation to improve the cache behaviour of pro- timal. By catering primarily to average and worst-case usage grams, the layout of dynamically allocated memory remains patterns, these allocators deny programs the advantages of largely beyond the reach of static tools. domain-specific optimisations, and thus may inadvertently Today, when a C++ program calls new, or a C program place data in a manner that hinders performance, generating malloc, its request is satisfied by a general-purpose allocator unnecessary cache misses and load stalls. with no intimate knowledge of what the program does or To help alleviate these issues, we propose HALO: a post- how its data objects are used. Allocations are made through link profile-guided optimisation tool that can improve the fixed, lifeless interfaces, and fulfilled by
    [Show full text]