Tore Larsen Material developed by: Kai Li, Princeton University

Slides:



Advertisements
Similar presentations
Multilevel Page Tables
Advertisements

Memory.
Virtual Memory In this lecture, slides from lecture 16 from the course Computer Architecture ECE 201 by Professor Mike Schulte are used with permission.
Part IV: Memory Management
OS Fall’02 Virtual Memory Operating Systems Fall 2002.
CS 153 Design of Operating Systems Spring 2015
Virtual Memory & Address Translation Vivek Pai Princeton University.
Recap. The Memory Hierarchy Increasing distance from the processor in access time L1$ L2$ Main Memory Secondary Memory Processor (Relative) size of the.
Virtual Memory & Address Translation Vivek Pai Princeton University.
Memory Management. 2 How to create a process? On Unix systems, executable read by loader Compiler: generates one object file per source file Linker: combines.
Chapter 3.2 : Virtual Memory
Virtual Memory and Paging J. Nelson Amaral. Large Data Sets Size of address space: – 32-bit machines: 2 32 = 4 GB – 64-bit machines: 2 64 = a huge number.
Main Memory. Background Program must be brought (from disk) into memory and placed within a process for it to be run Main memory and registers are only.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 346, Royden, Operating System Concepts Operating Systems Lecture 24 Paging.
Chapter 8 Memory Management Dr. Yingwu Zhu. Outline Background Basic Concepts Memory Allocation.
CS 153 Design of Operating Systems Spring 2015 Lecture 17: Paging.
Lecture 19: Virtual Memory
1 Chapter 3.2 : Virtual Memory What is virtual memory? What is virtual memory? Virtual memory management schemes Virtual memory management schemes Paging.
Operating Systems ECE344 Ding Yuan Paging Lecture 8: Paging.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 9: Memory Management Background Swapping Contiguous Allocation Paging Segmentation.
By Teacher Asma Aleisa Year 1433 H.   Goals of memory management  To provide a convenient abstraction for programming  To allocate scarce memory resources.
Chapter 8 – Main Memory (Pgs ). Overview  Everything to do with memory is complicated by the fact that more than 1 program can be in memory.
8.1 Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Paging Physical address space of a process can be noncontiguous Avoids.
Chapter 4 Memory Management Virtual Memory.
COS 318: Operating Systems Virtual Memory and Its Address Translations.
Memory Management Fundamentals Virtual Memory. Outline Introduction Motivation for virtual memory Paging – general concepts –Principle of locality, demand.
1 Memory Management (b). 2 Paging  Logical address space of a process can be noncontiguous; process is allocated physical memory whenever the latter.
By Teacher Asma Aleisa Year 1433 H.   Goals of memory management  To provide a convenient abstraction for programming.  To allocate scarce memory.
Virtual Memory 1 1.
1 Memory Management. 2 Fixed Partitions Legend Free Space 0k 4k 16k 64k 128k Internal fragmentation (cannot be reallocated) Divide memory into n (possible.
Address Translation Tore Larsen Material developed by: Kai Li, Princeton University.
Operating Systems ECE344 Ashvin Goel ECE University of Toronto Demand Paging.
Lectures 8 & 9 Virtual Memory - Paging & Segmentation System Design.
Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Memory.
Memory Management. 2 How to create a process? On Unix systems, executable read by loader Compiler: generates one object file per source file Linker: combines.
CS203 – Advanced Computer Architecture Virtual Memory.
Chapter 7: Main Memory CS 170, Fall Program Execution & Memory Management Program execution Swapping Contiguous Memory Allocation Paging Structure.
W4118 Operating Systems Instructor: Junfeng Yang.
CS161 – Design and Architecture of Computer
Translation Lookaside Buffer
Memory.
Memory Hierarchy Ideal memory is fast, large, and inexpensive
Non Contiguous Memory Allocation
Memory COMPUTER ARCHITECTURE
CS161 – Design and Architecture of Computer
Chapter 8: Main Memory Source & Copyright: Operating System Concepts, Silberschatz, Galvin and Gagne.
Paging and Segmentation
Chapter 8: Main Memory.
Operating System Concepts
Lecture 14 Virtual Memory and the Alpha Memory Hierarchy
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 8 11/24/2018.
Background Program must be brought into memory and placed within a process for it to be run. Input queue – collection of processes on the disk that are.
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 9 12/1/2018.
CS399 New Beginnings Jonathan Walpole.
Lecture 3: Main Memory.
Morgan Kaufmann Publishers Memory Hierarchy: Virtual Memory
CSE 451: Operating Systems Autumn 2005 Memory Management
Virtual Memory Overcoming main memory size limitation
CSE 451: Operating Systems Autumn 2003 Lecture 10 Paging & TLBs
Chapter 8: Memory Management strategies
CSE451 Virtual Memory Paging Autumn 2002
CSE 451: Operating Systems Autumn 2003 Lecture 9 Memory Management
Memory Management Lectures notes from the text supplement by Siberschatz and Galvin Modified by B.Ramamurthy Chapter 9 4/5/2019.
CSE 451: Operating Systems Autumn 2003 Lecture 10 Paging & TLBs
CSE 451: Operating Systems Autumn 2003 Lecture 9 Memory Management
CSE 471 Autumn 1998 Virtual memory
Virtual Memory.
CSE 542: Operating Systems
Virtual Memory 1 1.
Presentation transcript:

Tore Larsen Material developed by: Kai Li, Princeton University Address Translation Tore Larsen Material developed by: Kai Li, Princeton University

Topics Virtual memory Address translation Virtualization Protection Base and bound Segmentation Paging Translation look-ahead buffer (TLB)

Issues Many processes running concurrently Location transparency Address space may exceed memory size Many small processes whose total size may exceed memory Even one large may exceed physical memory size Address space may be sparsely used Protection OS protected from user processes User processes protected from each other

The Big Picture Memory is fast Disks are cheap Goals but expensive but slow Goals Run programs as efficiently as possible Make system as safe as possible

Strategies Size: Can we use slow disks to “extend” the size of available memory? Disk accesses must be rare in comparison to memory accesses so that each disk access is amortized over many memory accesses Location: Can we device a mechanism that delays the bindings of program address to memory location? Transparency and flexibility. Sparsity: Can we avoid reserving memory for non-used regions of address space? Process protection: Must check access rights for every memory access

Protection Issue Errors in one process should not affect other processes For each process, need to enforce that every load or store are to “legal” regions of memory

Expansion - Location Transparency Issue Each process should be able to run regardless of location in memory Regardless of memory size? Dynamically relocateable? Memory fragmentation External fragmentation – Among processes Internal fragmentation – Within processes Approach Give each process large “fake” address space Relocate each memory access to actual memory addres

Why Virtual Memory? Use secondary storage Provide Protection Extend expensive DRAM with reasonable performance Provide Protection Programs do not step over each other, communicate with each other require explicit IPC operations Convenience Flat address space and programs have the same view of the world Flexibility Processes may be located anywhere in memory, may be moved while executing, may reside partially in memory and partially on disk

Design Issues How is memory partitioned? How are processes (re)located? How is protection enforced?

Address Mapping Granularity Mapping mechanism Virtual addresses are mapped to DRAM addresses or onto disk Mapping granularity? Increased granularity Increases flexibility Decreases internal fragmentation Requires more mapping information & Handling Extremes Any byte to any byte: Huge map size Whole segments: Large segments cause problems

Locality of Reference Behaviors exhibited by most programs Locality in time When an item is addressed, it is likely to be addressed again shortly Locality in space When an item is addressed, its neighboring items are likely to be addressed shortly Basis of caching Argues that recently accessed items should be cached together with an encompassing region; A block (or line) 20/80 rule: 20 % of memory gets 80 % of references Keep the 20 % in memory

Translation Overview Actual translation is in hardware (MMU) CPU Actual translation is in hardware (MMU) Controlled in privileged software CPU view what program sees, virtual memory Memory & I/O view physical memory virtual address Translation (MMU) physical address Physical memory I/O device

Goals of Translation Implicit translation for each memory reference A hit should be very fast Trigger an exception on a miss Protected from user’s faults Registers Cache(s) 2-20x DRAM 100-300x paging Disk 20M-30Mx

Base and Bound > error + bound virtual address base Built in Cray-1 Protection A program can only access physical memory in [base, base+bound] On a context switch: Save/restore base, bound registers Pros Simple Flat Cons: Fragmentation Difficult to share Difficult to use disks bound virtual address > error + base physical address

Segmentation error > . + Virtual address segment offset seg size Provides separate virtual address spaces (segments) Each process has a table of (seg, size) Protection Each entry has (nil,read,write) On a context switch Save/restore the table or a pointer to the table in kernel memory Pros Efficient Easy to share Cons: Complex management Fragmentation within a segment seg size . + physical address

Paging error > ... ... . ... Physical address Virtual address page table size Use a fixed size unit called page Pages not visible from program Use a page table to translate Various bits in each entry Context switch Similar to the segmentation scheme What should be the page size? Pros Simple allocation Easy to share Cons Big page tables How to deal with holes? VPage # offset error > Page table PPage# ... ... . PPage# ... PPage # offset Physical address

How Many PTEs Do We Need? Assume 4KB page size 12 bit (low order) displacement within page 20 bit (high order) page# Worst case for 32-bit address machine # of processes  220 220 PTEs per page table (~4MBytes). 10K processes? What about 64-bit address machine? # of processes  252 Page table won’t fit on disk (252 PTEs = 16PBytes)

Segmentation with Paging Virtual address Vseg # VPage # offset Page table seg size PPage# ... ... . . PPage# ... Multics was the first system to combine segmentation and paging. www.multicians.org > PPage # offset error Physical address

Multiple-Level Page Tables Virtual address pte dir table offset . Directory . . .

Inverted Page Tables Physical Virtual address address Main idea One PTE for each physical page frame Hash (Vpage, pid) to Ppage# Pros Small page table for large address space Cons Lookup is difficult Overhead of managing hash chains, etc Virtual address pid vpage offset k offset pid vpage k n-1 Inverted page table

Virtual-To-Physical Lookup Program only knows virtual addresses Each process goes from 0 to highest address Each memory access must be translated Involves walk-through of (hierarchical) page tables Page table is in memory An extra memory access for each memory access??? Solution Cache part of page table (hierarchy) in fast associative memory – Translation-Lookahead-Buffer (TLB) Introduces TLB hits, misses etc.

Translation Look-aside Buffer (TLB) Virtual address VPage # offset VPage# PPage# ... Real page table Miss VPage# PPage# ... . VPage# PPage# ... TLB Hit PPage # offset Physical address

Bits in A TLB Entry Common (necessary) bits Optional (useful) bits Virtual page number: match with the virtual address Physical page number: translated address Valid Access bits: kernel and user (nil, read, write) Optional (useful) bits Process tag Reference Modify Cacheable

Hardware-Controlled TLB On a TLB miss Hardware loads the PTE into the TLB Need to write back if there is no free entry Generate a fault if the page containing the PTE is invalid VM software performs fault handling Restart the CPU On a TLB hit, hardware checks the valid bit If valid, pointer to page frame in memory If invalid, the hardware generates a page fault Perform page fault handling Restart the faulting instruction

Software-Controlled TLB On a miss in TLB Write back if there is no free entry Check if the page containing the PTE is in memory If not, perform page fault handling Load the PTE into the TLB Restart the faulting instruction On a hit in TLB, the hardware checks valid bit If valid, pointer to page frame in memory If invalid, the hardware generates a page fault Perform page fault handling

Hardware vs. Software Controlled Hardware approach Efficient Inflexible Need more space for page table Software approach Flexible Software can do mappings by hashing PP#  (Pid, VP#) (Pid, VP#)  PP# Can deal with large virtual address space

Cache vs. TLB Similarity Both are fast and expensive with respect to capasity Both cache a portion of memory Both write back on a miss Differences TLB is usually fully set-associative Cache can be direct-mapped TLB does not deal with consistency with memory TLB can be controlled by software Logically TLB lookup appears ahead of cache lookup, careful design allows overlapped lookup Combine L1 cache with TLB Virtually addressed cache Why wouldn’t everyone use virtually addressed cache?

TLB Related Issues What TLB entry to be replaced? Random Pseudo LRU What happens on a context switch? Process tag: change TLB registers and process register No process tag: Invalidate the entire TLB contents What happens when changing a page table entry? Change the entry in memory Invalidate the TLB entry

Consistency Issue Snoopy cache protocols Maintain cache consistency with DRAM, even when DMA happens Consistency between DRAM and TLBs: You need to flush (SW) related TLBs whenever changing a page table entry in memory Multiprocessors need TLB “shootdown” When you modify a page table entry, you need to do to flush (“shootdown”) all related TLB entries on every processor

Summary Virtual memory Address translation Easier SW development Better memory utilization Protection Address translation Base & bound: Simple, but limited Segmentation: Useful but complex Paging: Best tradeoff currently TLB: Fast translation VM needs to handle TLB consistency issues