Advanced Operating Systems - Lecture 23: Goals of OS memory management. This lecture will cover the following: Goals of OS memory management; questions regarding memory management; multiprogramming; virtual addresses; fixed partitioning; variable partitioning; fragmentation;...
CS703 Advanced Operating Systems By Mr Farhan Zaidi Lecture No. 23 Overview of today’s lecture Goals of OS memory management Questions regarding memory management Multiprogramming Virtual addresses Fixed partitioning Variable partitioning Fragmentation Goals of OS memory management Allocate scarce memory resources among competing processes, maximizing memory utilization and system throughput Provide isolation between processes Tools of memory management Base and limit registers Swapping Paging (and page tables and TLBs) Segmentation (and segment tables) Page fault handling => Virtual memory The policies that govern the use of these mechanisms Our main questions regarding Memory Management How is protection enforced? How are processes relocated? How is memory partitioned? Today’s desktop and server systems The basic abstraction that the OS provides for memory management is virtual memory (VM) VM enables programs to execute without requiring their entire address space to be resident in physical memory program can also execute on machines with less RAM than it “needs” many programs don’t need all of their code or data at once (or ever) e.g., branches they never take, or data they never read/write no need to allocate memory for it, OS should adjust amount allocated based on run-time behavior virtual memory isolates processes from each other one process cannot name addresses visible to others; each process has its own isolated address space Virtual memory requires hardware and OS support MMU’s, TLB’s, page tables, page fault handling, … Typically accompanied by swapping, and at least limited segmentation Multiprogramming: Linkerloader Can multiple programs share physical memory, without hardware translation? Yes: when copy program into memory, change its addresses (loads, stores, jumps) to use the addresses of where program lands in memory This relocation is performed by a linker-loader UNIX ld works this way: compiler generates each o file with code that starts at location How you create an executable from this? Scan through each o, changing addresses to point to where each module goes in larger program (requires help from compiler to say where all the re-locatable addresses are stored) With linker-loader, no protection: one program's bugs can cause other programs to crash Swapping save a program’s entire state (including its memory image) to disk allows another program to be run first program can be swapped back in and re-started right where it was The first timesharing system, MIT’s “Compatible Time Sharing System” (CTSS), was a uni-programmed swapping system only one memory-resident user upon request completion or quantum expiration, a swap took place Amazing even to think about today how bad the performance would be … but it worked! multiple processes/jobs in memory at once to overlap I/O and computation memory management requirements: protection: restrict which addresses processes can use, so they can’t stomp on each other fast translation: memory lookups must be fast, in spite of the protection scheme fast context switching: when switching between jobs, updating memory hardware (protection and translation) must be quick Virtual addresses for multiprogramming To make it easier to manage memory of multiple processes, make processes use virtual addresses (which is not what we mean by “virtual memory” today!) virtual addresses are independent of location in physical memory (RAM) where referenced data lives OS determines location in physical memory instructions issued by CPU reference virtual addresses e.g., pointers, arguments to load/store instructions, PC … virtual addresses are translated by hardware into physical addresses (with some setup from OS) The set of virtual addresses a process can reference is its address space many different possible mechanisms for translating virtual addresses to physical addresses we’ll take a historical walk through them, ending up with our current techniques Note: We are not yet talking about paging, or virtual memory – only that the program issues addresses in a virtual address space, and these must be “adjusted” to reference memory (the physical address space) for now, think of the program as having a contiguous virtual address space that starts at 0, and a contiguous physical address space that starts somewhere else Memory Hierarchy Two principles: The smaller amount of memory needed, the faster that memory can be accessed The larger amount of memory, the cheaper per byte Thus, put frequently accessed stuff in small, fast, expensive memory; use large, slow, cheap memory for everything else Works because programs aren't random Exploit locality: that computers usually behave in future like they have in the past Temporal locality: will reference same locations as accessed in the recent past Spatial locality: will reference locations near those accessed in the recent past Levels in Memory Hierarchy cache CPU CPU regs regs Register size: speed: $/Mbyte: line size: 32 B ns 8B 8B C a c h e 32 B Cache 32 KB-4MB ns $125/MB 32 B larger, slower, cheaper virtual memory Memory Memory Memory 1024 MB 30 ns $0.20/MB KB KB disk disk Disk Memory 100 GB ms $0.001/MB Old technique #1: Fixed partitions Physical memory is broken up into fixed partitions Advantages partitions may have different sizes, but partitioning never changes hardware requirement: base register, limit register physical address = virtual address + base register base register loaded by OS when it switches to a process how we provide protection? if (physical address > base + limit) then… ? Simple Problems internal fragmentation: the available partition is larger than what was requested external fragmentation: two small partitions left, but one big job – what sizes should the partitions be?? Mechanics of fixed partitions physical memory limit register base register 2K P2’s base: 6K partition 2K partition offset virtual address