Design Issues u Discussed Address Translation (will refresh in context) COS 318: Operating Systems u Thrashing and working sets Virtual Memory Design Issues: u Backing store Address Translation u Multiple page sizes and PT entries u Pinning/locking pages Jaswinder Pal Singh u Zero pages Computer Science Department Princeton University u Shared pages u Copy-on-write (http://www.cs.princeton.edu/courses/cos318/) u Distributed shared memory u Virtual memory in Unix and Linux u Virtual memory in Windows 2000 2 Virtual Memory Design Goals Recall Address translation: Base and Bound u Protection Processor’s View Implementation Physical u Virtualization Memory l Use disk to extend physical memory Virtual l Make virtualized memory user friendly (0 to high address) Base Memory Base Virtual Virtual Physical u Enabling memory sharing (libraries, communication) Address Address Address Processor Processor u Efficiency l Translation efficiency (TLB as cache) Base+ Bound l Access efficiency Bound • Access time = h ⋅ memory access time + ( 1 - h ) ⋅ disk access time Raise • E.g. Suppose memory access time = 100ns, disk access time = 10ms Exception • If h = 90%, VM access time is 1ms! ◆ Pros: Simple, fast, cheap, safe, can relocate ◆ Cons: u Portability "! Can’t keep program from accidentally overwriting its own code "! Can’t share code/data with other processes "! Can’t grow stack/heap as needed (stop program, change reg, …) 3 1 Recall Address Translation: Segmentation Segmentation Process View Implementation Physical u! A segment is a contiguous region of virtual memory Memory Base 3 u! Every process has a segment table (in hardware) Virtual Memory Stack l! Entry in table oer segment Processor Base+ Virtual Bound 3 Address Code Virtual Segment Table u! Segment can be located anywhere in physical memory Processor Address Base Bound Access Base 0 Segment Ofset Read l! Each segment has: start, length, access permission Code Data R/W Base+ u! Processes can share segments R/W Bound 0 R/W l! Same start, length, same/different access permissions Heap Base 1 Data Physical Address Base+ Stack Bound 1 Raise Exception Base 2 Heap •! Segments contiguous, but gaps in VM between them Base+ Bound 2 •! Segment table small, so stored on-CPU Segments Enable Copy-on-Write Segmentation u! Idea of Copy-on-Write u! Pros l! Child process inherits copy of parent’s address space on fork l! Can share code/data segments between processes l! But don’t really want to make a copy of all data upon fork l! Can protect code segment from being overwritten l! Would like to share as far as possible and make own copy l! Can transparently grow stack/heap as needed only “on-demand”, i.e. upon a write l! Can detect if need to copy-on-write u! Segments allow this to an extent l! Copy segment table into child, not entire address space u! Cons l! Mark all parent and child segments read-only l! Complex memory mgmt: need to find chunk of particular size l! Start child process; return to parent l! May need to rearrange memory from time to time to make room l! If child or parent writes to a segment (e.g. stack, heap) for new segment or growing segment •! Trap into kernel •! External fragmentation: wasted space between chunks •! At this point, make a copy of the segment, and resume 2 Recall Address Translation: Paging Multilevel Page Table u Manage memory in fixed size units, or pages u Finding a free page is easy Implementation Physical Memory l Effectively bitmap allocation: 0011111100000001100 l Each bit represents one physical page frame Processor u Every process has its own page table Virtual Address l Stored in physical memory Index 1 Index 2 Index 3 Offset l Hardware registers Physical Address Level 1 • Pointer to page table start Frame Offset • Page table length Level 2 u Recall fancier structures: segmentation+paging, multi-level PT l Better for sparse virtual address spaces l E.g. per-processor heaps, per-thread stacks, memory mapped files, Level 3 dynamically linked libraries, … l Don’t have fine-grain page table entries for “holes” Sharing and Copy on Write with Paging Pinning (or Locking) Page Frames u When do you need it? u Can we share memory between processes? l When DMA is in progress, you don’t want to page the pages out l Entries in both page tables to point to same page frames to avoid CPU from overwriting the pages l Need core map of page frames to track which / how many u Mechanism? processes are pointing to which page frames (e.g., reference l A data structure to remember all pinned pages count), so know when a a page is still “live” l Paging algorithm checks the data structure to decide on page u UNIX fork with copy on write replacement l Copy page table of parent into child process l Special calls to pin and unpin certain pages l Mark all pages (in new and old page tables) as read-only l Trap into kernel on write (in child or parent) l Copy page l Mark both as writeable l Resume execution 12 3 Zeroing Pages Shared Pages u Initilalize pages to all zero values u PTEs from two processes share v vp# pp# l Heap and static data are initialized the same physical pages v vp# pp# u How to implement? l What use cases? . l On the first page fault on a data page or stack page, zero it u Implementation issues v vp# pp# l l What if you terminate a process Or, have a special thread zeroing pages in the background Page table 1 with shared pages l Paging in/out shared pages v vp# pp# l Pinning, unpinning shared pages v vp# pp# l Deriving the working set for a . process with shared pages . v vp# pp# Physical Page table 2 pages 13 14 Efficient address translation TLB and page table translation u Recall translation lookaside buffer (TLB) Virtual Virtual l Cache of recent virtual page -> physical page translations Address Address Raise Processor TLB Miss Page Invalid l If cache hit, use translation Exception Table l If cache miss, walk (perhaps multi-level) page table Hit u Cost of translation = Valid Cost of TLB lookup + Frame Frame Prob(TLB miss) * cost of page table lookup Offset Physical Memory Physical Address Data Data 4 TLB Performance Intel i7 Memory hierarchy u What is the cost of a TLB miss on a modern processor? l Cost of multi-level page table walk l Software-controlled: plus cost of trap handler entry/exit l Use additional caching principles: multi-level caching, etc Intel i7 Processor Chip rd nd 17 i7 has 8MB as shared 3 level cache; 2 level cache is per-core Problem with Translation Slowdown Virtually vs. Physically Addressed Caches u What is the cost of a first level TLB miss? u It can be too slow to first access TLB to find physical l Second level TLB lookup address, then look up address in the cache u What is the cost of a second level TLB miss? u Instead, first level cache is virtually addressed l x86: 2-4 level page table walk u In parallel with cache lookup using virtual address, u Problem: Do we need to wait for the address translation access TLB to generate physical address in case of a in order to look up the caches (for code and data)? cache miss 5 Virtually addressed caches Physically addressed cache Virtual Virtual Virtual Virtual Virtual Virtual Address Address Address Address Address Address Virtual Raise Virtual Raise Processor Miss TLB Miss Page Invalid Processor Miss TLB Miss Page Invalid Cache Exception Cache Exception Table Table Hit Hit Hit Hit Valid Valid Data Frame Frame Data Frame Frame Offset Offset Physical Physical Physical Miss Cache Memory Memory Physical Physical Physical Address Hit Address Address Data Data Data Data Data When do TLBs work/not work? Superpages Video Frame Buffer u Video Frame Page# u On many systems, TLB entry can be 0 Buffer: 32 bits x l A page 1 1K x 1K = 4MB l A superpage: a set of contiguous pages 2 3 u x86: superpage is a set of pages in one page table l x86 TLB entries • 4KB • 2MB • 1GB 1021 1022 1023 6 Superpages When do TLBs Work/Not Work, Part 2 Physical u What happens when the OS changes the permissions Memory Virtual on a page? Address Page# Offset l For demand paging, copy on write, zero on reference, … SP Offset Translation Lookaside Buffer (TLB) u TLB may contain old translation Superpage Superframe l OS must ask hardware to purge TLB entry (SP) or (SF) or Page# Frame Access Physical Address Matching Entry Frame Offset u On a multicore: TLB shootdown l OS must ask each CPU to purge TLB entry Matching Superpage Page Table Lookup SF Offset When do TLBs Work/Not Work, Part 3 Aliasing u What happens on a context switch? u Alias: two (or more) virtual cache entries that refer to the l Keep using TLB? same physical memory l Flush TLB? l A consequence of a tagged virtually addressed cache! u Solution: Tagged TLB l A write to one copy needs to update all copies l Each TLB entry has process ID l TLB hit only if process ID matches current process u Typical solution Implementation Physical Memory Processor l Keep both virtual and physical address for each entry in Page Virtual Frame Address virtually addressed cache Page# Offset l Lookup virtually addressed cache and TLB in parallel Translation Lookaside Buffer (TLB) Process ID l Check if physical address from TLB matches multiple entries, Process ID Page Frame Access Physical Address and update/invalidate other copies Matching Entry Frame Offset Page Table Lookup 7 TLB Consistency Issues TLB shootdown u “Snoopy” cache protocols (hardware) l Maintain consistency with DRAM, even when DMA happens u Consistency between DRAM and TLBs (software) Process ID VirtualPage PageFrame Access l You need to flush related TLBs whenever changing a page = 0 0x0053 0x0003 R/W table entry in memory Processor 1 TLB = 1 0x4OFF 0x0012 R/W u TLB “shoot-down” l On multiprocessors/multicore, when you modify a page table = 0 0x0053 0x0003 R/W entry, need to flush all related TLB entries on all processors/ Processor 2 TLB = 0 0x0001 0x0005 Read cores = 1 0x4OFF 0x0012 R/W Processor 3 TLB = 0 0x0001 0x0005 Read 29 Summary u Must consider many issues l Global and local replacement strategies l Management of backing store l Primitive operations • Pin/lock pages • Zero pages • Shared pages • Copy-on-write u Real system designs are complex 31 8 .