CS5460: Operating Systems Lecture 13: Memory Management (Chapter 8) CS 5460: Operating Systems
Where are we? Basic OS structure, HW/SW interface, interrupts, • scheduling • Concurrency • • Memory management Storage management Other topics CS 5460: Operating Systems
Example Virtual Address Space 0xFFFFFFFF User stack segment Typical address space has 4 parts SP – Code: binary image of program – Data: static variables (globals) HP – Heap : explicitly allocated data ( malloc ) User User heap – Stack: implicitly allocated data User data segment Kernel mapped into all processes User code segment MMU hardware: PC 0x80000000 – Remaps virtual addresses to physical – Supports read-only, supervisor-only Kernel heap – Detects accesses to unmapped regions Kernel data segment How can we load two processes Kernel into memory at same time? – Assume each has similar layout Kernel code segment 0x00000000 CS 5460: Operating Systems
Mapping Addresses How can process (virtual) addresses be mapped to physical addresses? – Compile time: Compiler generates physical addresses directly » Advantages: No MMU hardware, no runtime translation overhead » Disadvantages: Inflexible, hard to multiprogram, inefficient use of DRAM – Load time: OS loader “ fixes ” addresses when it loads program » Advantages: Can support static multiprogramming » Disadvantages: MMU hardware, inflexible, hard to share data, … – Dynamic: Compiler generates address, but OS/HW reinterpret » Advantages: Very flexible, can use memory efficiently » Disadvantages: MMU hardware req ’ d, runtime translation overhead For “real” OSes, processes only use virtual addresses – Small-sized embedded systems use physical addresses CS 5460: Operating Systems
Uniprogramming (e.g., DOS) 0xFFFFFFFF One process at a time Reserved for DOS kernel User code compiled to sit in fixed range (e.g., [0,640 KB]) 0xA0000 Stack – No hardware virtualization of SP addresses OS in separate addresses HP – E.g., above 640KB Heap (Dynamically allocated) Uninitialized data Goals: (BSS segment) – Safety: None (good and bad) Static data – Efficiency: Poor (I/O and compute (Data segment) not overlapped, response time) Code PC (Text segment) 0x00000000 CS 5460: Operating Systems
Multiprogramming: Static Relocation 0xFFFFFFFF OS loader relocates programs Reserved for – OS stored in reserved “ high ” region OS kernel – Compiler maps process starting at 0 – When process started, OS loader: » Allocates contiguous physical memory Stack » Uses relocation info in binary to fix up SP 1 addresses to relocated region – TSRs in DOS based on this technique HP 1 Heap Problems: Data – Finding/creating contiguous holes PC 1 Code – Dealing with processes that grow/shrink Stack Goals: SP 0 – Safety: None! à à process can destroy other processes HP 0 Heap – Efficiency: Poor à à only one segment per process; slow load times; no Data sharing PC 0 Code 0x00000000 CS 5460: Operating Systems
Dynamic Relocation Physical Addresses 0xFFFFFFFF Idea: Stack Data SP 0 – Programs all laid out the same HP 0 Heap – Relocate addresses when used Data Data – “Requires” hardware support Code Heap Two views of memory: PC 0 – Virtual: Process ’ s view Code OS kernel – Physical: Machine ’ s view 0x00000000 Stack Many variants 0xFFFFFFFF Stack – Base and bounds Heap SP 1 – Segmentation Stack HP 1 Heap – Paging Virtual Data – Segmented paging Code Addresses Code PC 1 OS kernel OS kernel 0x00000000 CS 5460: Operating Systems
Base and Bounds Trap Each process mapped to contiguous physical region Bounds register Virtual address Two hardware registers >? – Base: Starting physical address – Bounds: Size in bytes + Base register Physical On each reference: address – Check against bounds Physical Virtual – Add base to get physical address 0xFFFFFFFF OS kernel 0x00000 Evaluation: 0x7ffff Stack Bounds 1 – Good points: … Heap P 1 VAs Data – Bad points: … Code Base 1 0x00000 OS handled specially 0x7ffff Stack Example: Cray-1 Bounds 0 Heap P 0 VAs Data Base 0 Code 0x00000 0x00000000 CS 5460: Operating Systems
Base and Bounds Each process has private address space – No relocation done at load time Operating system handled specially – Runs with relocation turned off (i.e., ignores Base and Bounds) – Only OS can modify Base and Bounds registers Good points: – Very simple hardware Bad points: – Only one contiguous segment per process à à inhibits sharing – External fragmentation à à need to find or make holes – Hard to grow segments CS 5460: Operating Systems
Segmentation Idea: Create N separate segments – Each segment has separate base and bounds register – Segment number is fixed portion of virtual address Seg# Offset Error! >? (Trap) Base Bounds Bounds Base Base Bounds Physical … + address Base Bounds Base Bounds CS 5460: Operating Systems
Segmentation Example Virtual address space is 2000 Base Bounds bytes in size • 0 1000 400 4 segments up to 500 bytes Segment • 1 0 500 Table each • 2 600 300 – Starting at 0, 500, 1000, 1500 • 3 1500 400 What if processor accesses … Physical Address Virtual Address – VA 0 2000 – VA 1040 Seg3 Seg3 – VA 1900 – VA 920 Seg0 Seg2 1000 – VA 1898 What if we allocate: Seg2 Seg1 – 100-byte segment – 200-byte segment Seg1 Seg0 0 CS 5460: Operating Systems
Segmentation Discussion Good features: – More flexible than base and bounds à à enables sharing (How?) – Reduces severity of fragmentation (How?) – Small hardware table (e.g., 8 segments) à à can fit all in processor Problems: – Still have fragmentation à à How? What kind? – Hard to grow segments à à Why? – Non-contiguous virtual address space à à Real problem? Possible solutions: – Fragmentation: Copy and compact – Growing segments: Copy and compact – Paging CS 5460: Operating Systems
Paging Problem w/ segmentation à à variable-sized segments Solution à à Paging! – Insist that all “ chunks ” be the same size (typically 512-8K bytes) – Call them “ pages ” rather than “ segments ” – Allocation is done in terms of full page-aligned pages à à no bounds – MMU maps virtual page numbers to physical page numbers Virtual Page# Offset Wired concatenate Physical Page# Other Physical Physical Page# Offset address Physical Page# Other Other Physical Page# What other info? Physical Page# Other CS 5460: Operating Systems
Paging Discussion How does this help? – No external fragmentation! – No forced holes in virtual address space – Easy translation à à everything aligned on power-of-2 addresses – Easy for OS to manage/allocate free memory pool What problems are introduced? – What if you do not need entire page? Internal fragmentation – Page table may be large » Where should we put it? – How can we do fast translation if not stored in processor? – How big should you make your pages? » Large: Smaller table, demand paging more efficient » Small: Less fragmentation, finer grained sharing, larger page table CS 5460: Operating Systems
Paging Examples Page Table PPN Valid R/O Super • 0 3 Y N Y • 1 8 N N N Assume 1000-byte pages 5 Y Y N • 2 What if processor accesses: 7 Y N N • 3 – VA 0 1 N Y Y • 4 – VA 1040 – VA 2900 Virtual Address Physical Address – VA 920 VP1 – VA 4998 VP3 VP2 VP4 VP3 VP0 VP2 VP4 VP1 Free VP0 List CS 5460: Operating Systems
x86 Paging x86 typically uses 4 KB pages Virtual addresses are 32 bits How big is the offset field of a virtual address? How big is the virtual page number field? How many pages are in a virtual address space? How big is a flat page table? – Assume PTE (page table entry) is 32 bits CS 5460: Operating Systems
Key Idea From Today Address space virtualization – Programs see virtual addresses – Kernel can see both virtual and physical addresses – Virtual and physical address spaces need not be the same size – You must understand this to understand modern operating systems Kernel + HW supports the virtual to physical mapping – Has to be fast – There are different ways to do it – Modern OSes use paging CS 5460: Operating Systems
Recommend
More recommend
