DOCSLIB.ORG

Computer Systems II

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Computer Systems II Computer Systems II Virtual Memory Recap: Paging • Memory is divided into frames • Process is divided into pages (same size as frames) Frame Main Memory 0 • Pages are loaded into frames (need not be 1 contiguous) 2 • Page table translates page addresses to frames 3 addresses 4 5 6 Process A (1) Process B (0) Process C (0) Process D (0) 7 Process A (2) Process B (1) Process C (1) Process D (1) 8 Process A (3) Process D (2) Process B (2) Process C (2) 9 Process A (4) Process C (3) Process D (3) Process B (3) 10 Process D (4) Process B (4) 11 Process B (5) Process D (5) 12 13 14 15 Recap: Page Tables • One page table for each process Frame Main Memory 0 Process AD (1)(0) • Page table used to translate virtual 1 Process DA (2)(1) addresses to physical addresses 2 Process DA (3)(2) 3 Process DA (4)(3) 4 Process B (0) 5 Process B (1) Process B Process C Process D 6 Process B (2) Page Frame Page Frame Page Frame 0 4 0 10 0 0 7 Process B (3) 1 5 1 11 1 1 8 Process B (4) 2 6 2 12 2 2 9 Process B (5) 3 7 3 13 3 3 10 Process C (0) 4 8 4 14 5 9 5 15 11 Process C (1) 12 Process C (2) 13 Process C (3) 14 Process D (4) 15 Process D (5) Recap: Problems that Still Remain • Should all pages be loaded in memory? – Limits the number of active processes • Solution: Virtual Memory – Load pages only when needed – Less need to swap blocked processes out to disk Virtual Memory allows the OS to load pieces only when needed (demand paging) Virtual Addressing • Virtual (logical) address is mapped to a real address using a page table • Size of physical address limited by memory size • What limits the size of a virtual address?? Page Number Offset Virtual Address Page table mapping Frame Number Offset Physical Address Virtual Memory Expands Memory Size • Virtual memory can be larger than physical memory – A process can use more memory – Only limited by swap space on disk • Pages not in main memory are stored in a dedicated swap area on the disk Main Memory Disk Pages 0 3 Swap Area 4 6 7 5 2 1 Demand Paging Frame Main Memory • Only load those pages needed 0 Process A (1) by process 1 Process A (2) 2 Process D (1) • Keep a permanent store of 3 Process B (3) pages on disk 4 Process C (1) 5 Process D (4) • Allows more processes to be 6 Process E (2) active 7 Process C (4) 8 Process F (1) • Eliminates needless loading 9 Process G (2) and unloading 10 Process B (1) 11 Process H (11) 12 Process I (1) 13 Process J (3) 14 Process E (3) 15 Process J (5) Page Faults • Imagine process A attempting to Frame Main Memory execute: 0 Process A (1) 1 Process A (2) mov ecx, [ebx] 2 Process D (1) 3 Process B (3) Register ebx contains a virtual 4 Process C (1) 5 Process D (4) address that corresponds to page 6 Process E (2) 3 of process A 7 Process C (4) 8 Process F (1) 9 Process G (2) • What happens? 10 Process B (1) 11 Process H (11) 12 Process I (1) PAGE FAULT 13 Process J (3) 14 Process E (3) 15 Process J (5) Page Fault Processing • Occurs when a process accesses a page not in memory Initial page fault processing When page is loaded (Disk Interrupt) Block current process Replacement Policy? Update page Memory yes Evict a page table Full? from memory No Mark process Setup I/O HW ready to read page from disk Start a new ready process Thrashing Frame Main Memory • Occurs when pages are 0 Process A (1)(2) swapped in and out 1 Process D (2) 2 Process D (1) frequently 3 Process B (3) • In steady state, memory will 4 Process C (1) be full 5 Process D (4) 6 Process E (2) 7 Process C (4) 8 Process F (1) for ( i=0; i<LIMIT; i++ ) { 9 Process G (2) /* access the first page */ 10 Process B (1) a = array[i]; /* access the second page */ 11 Process H (11) b = array[i+5000]; 12 Process I (1) sum = sum + a + b; Process J (3) } 13 14 Process E (3) 15 Process J (5) Aside: Programming Considerations • Program structure int A[1024][1024]; • Assume – each row is stored in one page – Only one page fits in memory • Program 1: ________ page faults for (j = 0; j < 1024; j++) for (i = 0; i < 1024; i++) A[i][j] = 0; • Program 2: ________ page faults for (i = 0; i < 1024; i++) for (j = 0; j < 1024; j++) A[i][j] = 0; Locality Limits Thrashing • Memory references tend to cluster • Different types of locality: – Spatial: If we access one memory item, we are likely to access other items close to it (i.e. code and array accesses) – Temporal: Over time, memory tends to be accessed multiple times (i.e. a loop) • OS may also limit the number of active processes to control thrashing Operating System Policies Operating System Policies • Fetch Policy: When to bring in pages • Replacement Policy: Which pages to replace • Resident Set Policy: How many pages to allow for each process • Load Control: How many active processes to allow Fetch Policy • Demand paging (most widely used) – Bring in page only when needed – Flurry of page transfers when process starts • Prepaging – Bring in extra pages on a page fault – Block transfers are more efficient – Ineffective if extra pages are not used Replacement Policy • When a page fault occurs, a victim page must be evicted from memory to make room for the new one • Goal is to replace the page needed furthest in the future (minimize page faults) • Some pages not subject to replacement – Frames are locked • Policies include: – Optimal: not possible but something to try for – First-in, first-out (FIFO) – Least recently used (LRU) Optimal • Selects page furthest referenced in the future – gives lower bound on the number of page faults • Three page replacements for example: Page Address Stream 2 3 2 1 5 2 4 5 3 2 5 2 2 2 2 2 2 2 4 4 4 2 2 2 3 3 3 3 3 3 3 3 3 3 3 1 5 5 5 5 5 5 5 5 F F F FIFO: First-In First-Out • Replace the page that is the oldest (has been in memory longest) • Six page replacements for example: Page Reference Stream 2 3 2 1 5 2 4 5 3 2 5 2 2 2 2 2 5 5 5 5 3 3 3 3 3 3 3 3 2 2 2 2 2 5 5 1 1 1 4 4 4 4 4 2 F F F F F F LRU: Least Recently Used • Replace the page that was referenced furthest in the past • Four page replacements for example: Page Address Stream 2 3 2 1 5 2 4 5 3 2 5 2 2 2 2 2 2 2 2 3 3 3 3 3 3 5 5 5 5 5 5 5 1 1 1 4 4 4 2 2 F F F F Resident Set Policy • How many frames to give each process? • Tradeoffs are: – few pages: load more processes, but more page faults – large number of pages: fewer resident processes, may waste page frames • Number of frames can be – fixed: decide at load time – variable: dynamically adjust the allocation Variable Frame Allocation • Keep track of the page fault count for each process – Define upper bound U , lower bound L for page fault rates – Allocate more frames to a process if fault rate > U – Allocate fewer frames to a process if fault rate < L • Load Control: – suspend a process with page fault rate > U, if all frames occupied Measuring the Memory Usage Virtual memory usage Physical memory usage (“resident set size”) Unix CPU time used by this process so far % ps -l F UID PID PPID PRI VSZ RSS STAT TIME COMMAND 0 115 7264 7262 17 4716 1400 SN 0:00 -csh 0 115 7290 7264 17 15380 10940 SN 5:52 emacs 0 115 3283 7264 23 2864 812 RN 0:00 ps l Windows Recap • Virtual memory can be larger than physical memory – Bring pages in memory as needed – Use disk swap area for pages not in memory • Fetch policy – Demand: bring page in memory only when needed – Prepaging: bring extra pages in on page fault • Replacement policy – FIFO: replace oldest page – LRU: replace page least recently referenced • Resident Set Policy – Adjust page allocation based on fault rate.
Load more

Recommended publications
  • Fluidmem: Open Source Full Memory Disaggregation
    FluidMem: Open Source Full Memory Disaggregation by Blake Caldwell B.S., University of Colorado at Boulder, 2014 M.S., University of Colorado at Boulder, 2015 A thesis submitted to the Faculty of the Graduate School of the University of Colorado in partial fulfillment of the requirements for the degree of Doctor of Philosophy Department of Computer Science 2019 This thesis entitled: FluidMem: Open Source Full Memory Disaggregation written by Blake Caldwell has been approved for the Department of Computer Science Prof. Richard Han Prof. Eric Keller Prof. Sangtae Ha Prof. Kenneth Anderson Date The final copy of this thesis has been examined by the signatories, and we find that both the content and the form meet acceptable presentation standards of scholarly work in the above mentioned discipline. iii Caldwell, Blake (Ph.D., Computer Science) FluidMem: Open Source Full Memory Disaggregation Thesis directed by Prof. Richard Han To satisfy the performance demands of memory-intensive applications facing DRAM short- ages, the focus of previous work has been on incorporating remote memory to expand capacity. However, the emergence of resource balancing as a priority for cloud computing requires the capa- bility to dynamically size virtual machine memory up and down. Furthermore, hardware-based or kernel space implementations hamper flexibility with respect to making customizations or integrat- ing the continuing open source advancements in software infrastructure for the data center. This thesis presents an architecture to meet the performance, bi-directional sizing, and flexibility challenges of memory disaggregation in the cloud. The implementation, called FluidMem, is open source software [35] that integrates with the Linux kernel, KVM hypervisor, and multiple key- values stores.
    [Show full text]
  • Virtual Memory
    M08_STAL6329_06_SE_C08.QXD 2/21/08 9:31 PM Page 345 CHAPTER VIRTUAL MEMORY 8.1 Hardware and Control Structures Locality and Virtual Memory Paging Segmentation Combined Paging and Segmentation Protection and Sharing 8.2 Operating System Software Fetch Policy Placement Policy Replacement Policy Resident Set Management Cleaning Policy Load Control 8.3 UNIX and Solaris Memory Management Paging System Kernel Memory Allocator 8.4 Linux Memory Management Linux Virtual Memory Kernel Memory Allocation 8.5 Windows Memory Management Windows Virtual Address Map Windows Paging 8.6 Summary 8.7 Recommended Reading and Web Sites 8.8 Key Terms, Review Questions, and Problems APPENDIX 8A Hash Tables 345 M08_STAL6329_06_SE_C08.QXD 2/21/08 9:31 PM Page 346 346 CHAPTER 8 / VIRTUAL MEMORY Table 8.1 Virtual Memory Terminology Virtual memory A storage allocation scheme in which secondary memory can be addressed as though it were part of main memory.The addresses a program may use to reference mem- ory are distinguished from the addresses the memory system uses to identify physi- cal storage sites, and program-generated addresses are translated automatically to the corresponding machine addresses. The size of virtual storage is limited by the ad- dressing scheme of the computer system and by the amount of secondary memory available and not by the actual number of main storage locations. Virtual address The address assigned to a location in virtual memory to allow that location to be ac- cessed as though it were part of main memory. Virtual address space The virtual storage assigned to a process. Address space The range of memory addresses available to a process.
    [Show full text]
  • Ret2dir: Rethinking Kernel Isolation Vasileios P
    ret2dir: Rethinking Kernel Isolation Vasileios P. Kemerlis, Michalis Polychronakis, and Angelos D. Keromytis, Columbia University https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/kemerlis This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7 Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX ret2dir: Rethinking Kernel Isolation Vasileios P. Kemerlis Michalis Polychronakis Angelos D. Keromytis Columbia University {vpk, mikepo, angelos}@cs.columbia.edu Abstract equally attractive target. Continuing the increasing trend of the previous years, in 2013 there were 355 reported Return-to-user (ret2usr) attacks redirect corrupted kernel kernel vulnerabilities according to the National Vulnera- pointers to data residing in user space. In response, sev- bility Database, 140 more than in 2012 [73]. Admittedly, eral kernel-hardening approaches have been proposed to the exploitation of user-level software has become much enforce a more strict address space separation, by pre- harder, as recent versions of popular OSes come with nu- venting arbitrary control flow transfers and dereferences merous protections and exploit mitigations. The princi- from kernel to user space. Intel and ARM also recently ple of least privilege is better enforced in user accounts introduced hardware support for this purpose in the form and system services, compilers offer more protections of the SMEP, SMAP, and PXN processor features. Un- against common software flaws, and highly targeted ap- fortunately, although mechanisms like the above prevent plications, such as browsers and document viewers, have the explicit sharing of the virtual address space among started to employ sandboxing.
    [Show full text]
  • System Analysis and Tuning Guide Opensuse Leap 42.1 System Analysis and Tuning Guide Opensuse Leap 42.1
    System Analysis and Tuning Guide openSUSE Leap 42.1 System Analysis and Tuning Guide openSUSE Leap 42.1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to efficiently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: November 05, 2018 SUSE LLC 10 Canal Park Drive Suite 200 Cambridge MA 02141 USA https://www.suse.com/documentation Copyright © 2006–2018 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Docu- mentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see http://www.suse.com/company/legal/ . All other third party trademarks are the prop- erty of their respective owners. A trademark symbol (®, ™ etc.) denotes a SUSE or Novell trademark; an asterisk (*) denotes a third party trademark. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its affiliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xi I BASICS 1 1 General Notes on System Tuning 2
    [Show full text]
  • Protecting Commodity Operating Systems Through Strong Kernel Isolation
    Protecting Commodity Operating Systems through Strong Kernel Isolation Vasileios P. Kemerlis Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Graduate School of Arts and Sciences COLUMBIA UNIVERSITY 2015 c 2015 Vasileios P. Kemerlis All Rights Reserved ABSTRACT Protecting Commodity Operating Systems through Strong Kernel Isolation Vasileios P. Kemerlis Today’s operating systems are large, complex, and plagued with vulnerabilities that allow perpetrators to exploit them for profit. The constant rise in the number of software weak- nesses, coupled with the sophistication of modern adversaries, make the need for effective and adaptive defenses more critical than ever. In this dissertation, we develop a set of novel protection mechanisms, and introduce new concepts and techniques to secure commodity operating systems against attacks that exploit vulnerabilities in kernel code. Modern OSes opt for a shared process/kernel model to minimize the overhead of opera- tions that cross protection domains. However, this design choice provides a unique vantage point to local attackers, as it allows them to control—both in terms of permissions and contents—part of the memory that is accessible by the kernel, easily circumventing protec- tions like kernel-space ASLR and WˆX. Attacks that leverage the weak separation between user and kernel space, characterized as return-to-user (ret2usr) attacks, have been the de facto kernel exploitation technique in virtually every major OS, while they are not limited to the x86 platform, but have also targeted ARM and others. Given the multi-OS and cross-architecture nature of ret2usr threats, we propose kGuard: a kernel protection mechanism, realized as a cross-platform compiler extension, which can safeguard any 32- or 64-bit OS kernel from ret2usr attacks.
    [Show full text]
  • Practice Problems: Memory
    Lectures on Operating Systems (Mythili Vutukuru, IIT Bombay) Practice Problems: Memory 1. Provide one advantage of using the slab allocator in Linux to allocate kernel objects, instead of simply allocating them from a dynamic memory heap. Ans: A slab allocator is fast because memory is preallocated. Further, it avoids fragmentation of kernel memory. 2. Consider a program that memory maps a large file, and accesses bytes in the first page of the file. Now, a student runs this program on several machines running different versions of Linux, and finds that the actual physical memory consumed by the process (RSS or resident set size) varies from OS to OS. Provide one reason to explain this observation. Ans: Different operating systems may have different heuristics to allocate physical memory to a process. For example, systems may differ in the heuristics for prepaging, i.e., how to prefetch pages that may be accessed in the future. This leads to different values of RSS. 3. In a 32-bit architecture machine running Linux, for every physical memory address in RAM, there are at least 2 virtual addresses pointing to it. That is, every physical address is mapped at least twice into the virtual address space of some set of processes. [T/F] Ans: F 4. Consider a system with N bytes of physical RAM, and M bytes of virtual address space per pro- cess. Pages and frames are K bytes in size. Every page table entry is P bytes in size, accounting for the extra flags required and such. Calculate the size of the page table of a process.
    [Show full text]
  • Chapter 8 Virtual Memory Roadmap
    Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 8 Virtual Memory Dave Bremer Otago Polytechnic, N.Z. ©2008, Prentice Hall Roadmap • Hardware and Control Structures • Operating System Software • UNIX and Solaris Memory Management • Linux Memory Management • Windows Memory Management Terminology Key points in Memory Management 1) Memory references are logical addresses dynamically translated into physical addresses at run time – A process may be swapped in and out of main memory occupying different regions at different times during execution 2) A process may be broken up into pieces that do not need to located contiguously in main memory Breakthrough in Memory Management • If both of those two characteristics are present, – then it is not necessary that all of the pages or all of the segments of a process be in main memory during execution. • If the next instruction, and the next data location are in memory then execution can proceed – at least for a time Execution of a Process • Operating system brings into main memory a few pieces of the program • Resident set - portion of process that is in main memory • An interrupt is generated when an address is needed that is not in main memory • Operating system places the process in a blocking state Execution of a Process • Piece of process that contains the logical address is brought into main memory – Operating system issues a disk I/O Read request – Another process is dispatched to run while the disk I/O takes place – An interrupt is issued when disk I/O complete
    [Show full text]
  • Chapter 8 Chapter 8 Virtual Memory
    Operating Systems: Internals and Design Chapter 8 Principles Virtual Memory Seventh Edition William Stallings Operating Systems: Internals and Design Principles You’re gonna need a bigger boat. — Steven Spielberg, JAWS, 1975 Hardware and Control Structures n Two characteristics fundamental to memory management: 1) all memory references are logical addresses that are dynamically translated into physical addresses at run time 2) a process may be broken up into a number of pieces that don’t need to be contiguously located in main memory during execution n If these two characteristics are present, it is not necessary that all of the pages or segments of a process be in main memory during execution Terminology n Operating system brings into main memory a few pieces of the program n Resident set - portion of process that is in main memory n An interrupt is generated when an address is needed that is not in main memory n Operating system places the process in a blocking state Continued . Execution of a Process n Piece of process that contains the logical address is brought into main memory n operating system issues a disk I/O Read request n another process is dispatched to run while the disk I/O takes place n an interrupt is issued when disk I/O is complete, which causes the operating system to place the affected process in the Ready state Implications n More processes may be maintained in main memory n only load in some of the pieces of each process n with so many processes in main memory, it is very likely a process will be in the Ready state
    [Show full text]
  • An Analysis of How Static and Shared Libraries Affect Memory Usage on an IP-STB
    An analysis of how static and shared libraries affect memory usage on an IP-STB Master of Science Thesis in the Programme Networks and Distributed Systems Dongping Huang Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, September 2010 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. An analysis of how code locality affects the dynamic memory usage on an embedded set- top box running Linux Dongping Huang © Dongping Huang, September 2010. Examiner: Björn von Sydow Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE-412 96 Göteborg Sweden Telephone + 46 (0)31-772 1000 Department of Computer Science and Engineering Göteborg, Sweden September 2010 Abstract An IP-STB is a small and stand alone embedded system which is able to provide a series of advanced entertaining services.
    [Show full text]
  • Working Sets Past and Present
    Purdue University Purdue e-Pubs Department of Computer Science Technical Reports Department of Computer Science 1978 Working Sets Past and Present Peter J. Denning Report Number: 78-276 Denning, Peter J., "Working Sets Past and Present" (1978). Department of Computer Science Technical Reports. Paper 208. https://docs.lib.purdue.edu/cstech/208 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. WORKING SETS PAST AND PRESENT· Peter J. Denning Computer Science Department Purdue University W. Lafayette, IN 47907 CSD-TR-276 July 1978 (revised May 1979) Abstract A program's working set is the collection of segments (or pages) recently referenced. This concept has led to efficient methods for measuring a program's intrinsic memory demand; it has assisted in understanding and in modeling program behavior; and it has been used as the basis of optimal multiprograrnmed memory management. The total cost of a working set dispatcher is no larger than the total cost of other common dispatchers. This paper outlines the argument why it is unlikely that anyone will find a cheaper nonlookahead ~emory policy that delivers significantly better performance. Index Terms \'lorking sets, memory management. virtual memory, multiprogram­ ming, optimal multiprogramming, lifetime curves, program measureI'lent, program behavior. stochastic program models, phase/transition behavior. program locality, multiprogrammed load control1ers.~ispatchers,work­ ing set dispatchers, memor/ space-time product. *I'lork reported herein \'1as supported in part by NSF Grants GJ-41289 and ~ICS78-01729 at Purdue University. A condensed, preliminary draft of this paper was presented as an invited lecture at the International Symposium on Operating Systems, IRIA Laboria, Rocquenc:ourt, France, October 2-4, 1978 [DENN78d).
    [Show full text]
  • Section 9: Paging
    Section 9: Paging CS 162 July 22, 2020 Contents 1 Vocabulary 2 2 Address Translation (7/20)3 2.1 Page Allocation..........................................3 2.2 Address Translation.......................................4 3 Paging 6 3.1 Demand Paging..........................................6 3.2 Cached Paging..........................................7 3.3 Inverted Page Tables.......................................8 3.3.1 Inverted Page Table...................................8 3.3.2 Linear Inverted Page Table...............................8 3.3.3 Hashed Inverted Page Table...............................9 4 Page Replacement Algorithms 10 4.1 FIFO................................................ 10 4.2 LRU................................................ 10 4.3 MIN................................................ 10 4.4 FIFO vs. LRU.......................................... 11 4.5 Improving Cache Performance.................................. 11 4.5.1 FIFO........................................... 11 4.5.2 LRU............................................ 11 4.5.3 MIN............................................ 11 1 CS 162 Summer 2020 Section 9: Paging 1 Vocabulary • Demand Paging - The process where the operating system only stores pages that are "in demand" in the main memory and stores the rest in persistent storage (disk). Accesses to pages not currently in memory page fault and the page fault handler will retrieve the request page from disk (paged in). When main memory is full, then as new pages are paged in old pages must be paged out through a process called eviction. Many cache eviction algorithms like least recently used can be applied to demand paging, the main memory is acting as the cache for pages which all start on disk. • Working Set - The subset of the address space that a process uses as it executes. Generally we can say that as the cache hit rate increases, more of the working set is being added to the cache.
    [Show full text]
  • Design Decisions Page Size Page Fault Rate Resident Set
    Käyttöjärjestelmät, Luento 9 WEEK 5 Page fault rate • More small pages to the same memory space • References from large pages Virtual memory algorithms and more probable to go to a page not yet in memory examples • References from small pages often to other pages -> often used pages selected to the Stallings, Chapter 8 memory • Page size closer to process size • Too small working set size -> larger page fault rate • Large working set size -> nearly all pages in the memory 1 4 Algorithms for memory Design decisions management • Virtual memory or not? • Fetch policy • Paging or segmentation? • Demand paging vs prepaging • What algorithms? • Placement policy CONSIDERING ONLY PAGING: • Replacement policy • Resident set management, selecting the page to be replaced • What page size? • Methods: OPT, LRU, FIFO, random … • Cleaning policy • Demand cleaning vs precleaning, buffering • Load control • Working set size 2 5 Page size Resident set mgt • Number of page frames allocated for a process (resident set • Reduce internal fragmentation ĺ small size) • Fixed: how large, identical for all? • Reduce page table size ĺ large • Variable: based on what? Working set? • Proportional (1x, 2x, …) to disk block size • Replacement policy: • Global: over all pages (all processes) • Optimal value is different for different programs • Local: just the pages of this process • Increase TLB hit ratio ĺ large • Size of the resident set: • Too small: higher multprocessing level, more page faults, trashing • Different page size for different applications? • Too large: smaller CPU utilisation, wasted memory • How does MMU know the page size? Tbl 8.2 [Stal05] 3 6 Syksy 2007, Tiina Niklander 9-1 Käyttöjärjestelmät, Luento 9 Resident set management Clock • Replace the page where the use bit is zero, while scanning reset the use bit (esim.
    [Show full text]