EECS 470. Lecture 16 Virtual Memory. Fall 2018 Jon Beaumont

Transcription

1 Lecture 16 Virtual Memory Fall 2018 Jon Beaumont Slides developed in part by Profs. Austin, Brehob, Falsafi, Hill, Hoe, Lipasti, Shen, Smith, Sohi, Tyson, and Vijaykumar of Carnegie Mellon University, Purdue University, University of Michigan, and University of Wisconsin. Slide 1

2 Announcements Milestone II Meetings Today No Lecture on Wednesday, gobble gobble Milestone III next Friday (11/30) Should be passing most testcases Wrapping up advanced features Slide 2

3 Last Time Finished up memory enhancements Caching Prefetching Slide 3

4 Virtual Memory Why do we need it? Evolution: Today From base and bound through paging Page tables and organization Hierarchical Inverted (hash) Cache implications Slide 4

5 Virtual Memory Slide 5

6 Roadmap Speedup Programs Reduce Instruction Latency Parallelize Reduce number of instructions Reduce average memory latency Instruction Level Parallelism Caching First 2 months Programmability Precise State Virtual Memory Slide 6

7 Motivation - Multiprogramming Multiprogramming We like to have multiple processes (program instances) running at the same time Practicality: I/O management, network processing, GUI Performance: More power efficient to do many things slowly, rather than few things quickly (remember P V 3 ) Different programs might use the same addresses Either statically compile applications to be compatible with one another (inflexible) or have some way of ensuring address spaces of different processes are independent, even when using same addresses Slide 7

8 Motivation - Demand Paging Consider 32-bit address space 4 GB, not too bad with modern technology Might still be expensive/prohibitive for embedded or otherwise minimal systems 48-bit address space? 256 TB no way Use caching principles! Keep data likely to be used in DRAM, less likely in slower, cheaper storage (e.g. disk) Slide 8

9 Motivation - Demand Paging But, a bit different than traditional caching Locality is a lot harder to extract past L1-L3 caches Penalties of going to disk are much higher (page miss - millions of cycles) So, let OS figure out data placement Need fast way of figuring out where data is on cycle to cycle basis Slide 9

10 Motivation Multiprogramming and Demand Paging 2 independent sets of problems, 1 solution Virtual memory Virtual means using indirection Map virtual address (VA) specified in program to physical address (PA), which may be in either DRAM or disk Slide 10

11 Evolution of Protection Mechanisms Earliest machines had no concept of protection and address translation no need---single process, single user automatically private and uniform (but not very large) programs operated on physical addresses directly no multitasking protection, no dynamic relocation (at least not very easily) Slide 11

12 base and bound registers In a multi-tasking system: Each process is given a non-overlapping, contiguous physical memory region, everything belonging to a process must fit in that region When a process is swapped in, OS sets base to the start of the process s memory region and bound to the end of the region HW translation and protection check (on each memory reference) PA = VA + base provided (PA < bound), else violations Each process sees a private and uniform address space (0.. max) Base Bound privileged control registers active process s region another process s region physical mem. Bound can also be formulated as a range Slide 12

13 Segmented Address Space segment == a base and bound pair segmented addressing gives each process multiple segments initially, separate code and data segments - 2 sets of base-and-bound reg s for inst and data fetch - allowed sharing code segments became more and more elaborate: code, data, stack, etc. also (ab)used as a way for an ISA with a small VA space to address a larger physical memory space SEG # VA segment tables must be 1. privileged data structures and 2. private/unique to each process segment table base & bound +,< PA & okay? Slide 13

14 Paged Address Space Segmented addressing creates fragmentation problems, a system may have plenty of unallocated memory locations they are useless if they do not form a contiguous region of a sufficient size In a Paged Memory System: PA space is divided into fixed size segments (e.g. 4kbyte), more commonly known as page frames VA is interpreted as page number and page offset Page No. Page Offset page tables must be 1. privileged data structures and 2. private/unique to each process page table page frame base & okay? + PA Slide 14

15 decoder decoder Page-Based Virtual Memory Virtual address Virtual page number (52-bit) (64-bit) (12-bit) Translation memory (page table) (~8-bytes) Page offset (1~10 GBytes) Main memory pages Physical Page Number Physical address Where to hold this translation memory and how much translation memory do we need? (40-bit) (10 ~ 100 GBytes) Slide 15

16 Page table organization Slide 16

17 Page Table Could just store big table in memory contiguously listing all physical page numbers but many applications don t use very much of its address space, lot s of wasted space Many possible solutions. 2 popular ones: Hierarchical map table Inverted (hash) page table Slide 17

18 Hierarchical Page Table 10-bit 10-bit 12-bit p1 p2 P.O. effective address privileged register p1 p2 Base of the Page Table of the page table page in swap disk page in main memory page does not exist Page Table of the page table pages of the page table d data pages Storage of overhead of translation should be proportional to the size of physical memory and not the virtual address space Slide 18

19 Inverted or Hashed Page Tables Base of Table Inverted Page Table PID VPN hash Table Offset + PA of IPTE VPN PID PTE Size of Inverted Page table only needs to be proportional to the size of the physical memory Each VPN can only be mapped to a small set of entries according to a hash function To translate a VPN, check all allowed table entries for matching VPN and PID How many memory lookups per translation? Physical Memory Slide 19

20 Virtual-to-Physical Translation Slide 20

21 Translation Look-aside Buffer (TLB) Essentially a cache of recent address translations avoids going to the page table on every reference indexed by lower bits of VPN (virtual page #) tag = unused bits of VPN + process ID data = a page-table entry i.e. PPN (physical page #) and access permission status = valid, dirty the usual cache design choices (placement, replacement policy multi-level, etc) apply here too. Virtual address Tag VPN Index Physical page no. Page offset = Physical address Page offset What should be the relative sizes of ITLB and I-cache? Slide 21

22 Virtual to Physical Address Translation Virtual Address TLB Lookup 1 pclk miss hit 100 s pclk by HW or SW Page Table Walk Protection Check 1 pclk succeed fail denied permitted Update TLB Page Fault OS Table Walk s pclk Protection Fault Physical Address To Cache Slide 22

23 Cache Placement and Address Translation Physical Cache (Most Systems) PA CPU VA MMU fetch critical path Virtual Cache (SPARC2 s) VA Physical Cache Physical Memory longer hit time CPU Virtual Cache fetch critical path MMU PA Physical Memory aliasing problem cold start after context switch Virtual caches are not popular anymore because MMU and CPU can be integrated on one chip Slide 23

24 Virtually Indexed Virtually Tagged (VIVT) Cache Virtual Pg No. Index Page Offset BO p D-cache i b p PPN p = Hit/Miss Data Slide 24

25 Pros Fast (access cache right away) Simple VIVT Cache Cons Homonyms (one virtual address maps to several different physical addresses) Flush cache after context switch or add address space ID to cache Synonyms (one physical address maps to several virtual addresses) Flush cache Slide 25

26 Physically Indexed Physically Tagged (PIPT) Cache Virtual Address (n=v+g bits) Virtual Page No. (VPN) Tag Index Page Offset (PO) v-k k g TLB Physical Address (m=p+g bits) p Phy. Page No. (PPN) PO Tag Index BO t i b D-cache Data Slide 26

27 PIPT Cache Pros Simple No aliasing (homonyms or synonyms) Cons Slow (all loads/stores take 2 memory transactions at best) Slide 27

28 Virtually Indexed Physically Tagged (VIPT) Cache Parallel Access to TLB and Cache arrays Virtual Pg No. (VPN) Tag Index Page Offset Tag Index Page Offset v-k TLB PPN p Virtual Pg No. (VPN) k Index BO g i b p D-cache p PPN p = Hit/Miss Data How large can a virtually indexed cache get? Slide 28

29 Large Virtually Indexed Cache Virtual Pg No. (VPN) Tag Index Page Offset Tag Index Page Offset v-k TLB PPN p Virtual Pg No. (VPN) k Index BO g a i b p D-cache p PPN p = Hit/Miss Data If two VPNs differs in a, but both map to the same PPN then there is an aliasing problem Slide 29

30 Pros VIVT Cache Fast (two memory transactions can be done in parallel) Cons More complicated Cache size is constrained Slide 30

31 Virtual Address Synonyms To Virtual pages that map to the same physical page within the same virtual address space across address spaces VA1 PA VA2 Using VA bits as IDX, PA data may reside in different sets in cache!! Slide 31

32 Synonym Solutions Limit cache size to page size times associativity get index from page offset Search all sets in parallel 64K 4-way cache, 4K pages, search 4 sets (16 entries) Slow! Restrict page placement in OS make sure index(va) = index(pa) Eliminate by OS convention single virtual space restrictive sharing model Slide 32