Computer Systems Principles Virtual Memory & Paging

1. Computer Systems PrinciplesVirtual Memory & Paging Emery Berger and Mark Corner University of Massachusetts Amherst

2. Virtual vs. Physical Memory • Apps don’t access physical memory • Well, not directly • Apps use virtual memory • Addresses start at 0 • One level of indirection • Address you see is not “real” address • Any ideas why?

3. Memory Pages • Programs use memory as individual bytes • OS manages groups of bytes: pages • typically 4kB, 8kB • Why? (think Tetris with all squares) • Applies this to virtual and physical memory • Physical pages usually called frames A

4. Mapping Virtual to Physical • Note this is simplified and the data here includes the heap, not the typical data segment…

5. Why Virtual Memory? • Why? • Simpler • Everyone gets illusion of whole address space • Isolation • Every process protected from every other • Optimization • Reduces space requirements

6. Typical Virtual Memory Layout • Some things grow • Must leave room! • Mmap and heap spaces • Mmap increases mmap • Brk increases heap • Other layouts possible

7. Quick Quiz! • Are arrays contiguous in memory? • Physical memory? • Virtual memory? • Where does the code for a program live?

8. Memory Management Unit • Programs issue loads and stores • What kind of addresses are these? • MMU Translates virtual to physical addresses • Maintains page table (big hash table): • Almost always in HW… Why? Program MMU Memory Virtual Address Physical Address Page Table

9. Page Tables • Table of translations • virtual pages -> physical pages • One page table per process • One page table entry per virtual page • How? • Programs issue virtual address • Find virtual page (how?) • Lookup physical page, add offset

10. Page Table Entries • Do all virtual pages -> physical page? • Valid and Invalid bits • PTEs have lots of other information • For instance some pages can only be read

11. Address Translation • Powers of 2: • Virtual address space: size 2^m • Page size 2^n • Page#: High m-n bits of virtual address • Lower n bits select offset in page 11

12. Quick Activity • How much mem does a page table need? • 4kB pages, 32 bit address space • page table entry (PTE) uses 4 bytes • 2^32/2^12*4=2^22 bytes=4MB • Is this a problem? • Isn’t this per process? • What about a 64 bit address space? • Any ideas how to fix this?

13. Multi-Level Page Tables • Use a multi-level page table A A Level 0 Table Level 1 Table A Level 1 Table

14. Quick Activity • How much mem does a page table need? • 4kB pages, 32 bit address space • Two level page table • 20bits = 10 bits each level • page table entry (PTE) uses 4 bytes • Only first page of program is valid • 2^10*4+2^10*4=2^13 bytes=8kB • Isn’t this slow?

15. Translation Lookaside Buffer (TLB) • TLB: fast, fully associative memory • Caches page table entries • Stores page numbers (key) and frame (value) in which they are stored • Assumption: locality of reference • Locality in memory accesses =locality in address translation • TLB sizes: 8 to 2048 entries • Powers of 2 simplifies translationof virtual to physical addresses

16. Virtual Memory is an Illusion! • How much memory does a process have? • Do all processes have this? • Key idea: use RAM as cache for disk • OS transparently moves pages • Requires locality: • Working set must fit in RAM • memory referenced recently • If not: thrashing (nothing but disk traffic)

17. Paging 17

18. Paging + Locality • Most programs obey 90/10 “rule” • 90% of time spent accessing 10% of memory • Exploit this rule: • Only keep “live” parts of process in memory A A B B 18

19. Key Policy Decisions • Two key questions: (for any cache): • When do we read page from disk? • When do we write page to disk? 19

20. Reading Pages • Read on-demand: • OS loads page on its first reference • May force an eviction of page in RAM • Pause while loading page = page fault • Can also perform pre-paging: • OS guesses which page will next be needed, and begins loading it • Most systems just do demand paging • What about writes? 20

21. Demand Paging • On every reference, check if page is in memory (resident bit in page table) • Who is doing this? • If not: trap to OS • How does this work in HW? • OS: • Selects victim page to be replaced • Writes victim page if necessary, marks non-resident • Begins loading new page from disk • OS can switch to another process • more on this later 21

22. Swap Space • Swap space = where victim pages go • Partition or special file reserved on disk • Size of reserved swap space limits what? 22

23. Tricks with Page Tables • Do all pages of memory end up in swap? • Parts of address space mapped into files • see man pages for mmap

24. Overview • A Day in the Life of a Page • Allocation • Use • Eviction • Reuse • Terms: Resident and Non-resident

25. A Day in the Life of a Page • Allocate some memory 0x40001000 0x40001040 → 0x4000104F virtual memory layout char * x = new char[16];

26. A Day in the Life of a Page • Update page tables 0x40001000 0x40001040 → 0x4000104F virtual memory layout physical memory layout char * x = new char[16];

27. A Day in the Life of a Page • Write contents – dirty page 0x40001000 0x40001040 → 0x4000104F virtual memory layout physical memory layout strcpy(x, “hello”);

28. A Day in the Life of a Page • Other processes fill up memory… virtual memory layout physical memory layout

29. A Day in the Life of a Page • Forcing our page to be evicted (paged out) virtual memory layout physical memory layout swapspace(disk)

30. A Day in the Life of a Page • Now page nonresident & protected virtual memory layout physical memory layout swapspace(disk)

31. A Day in the Life of a Page • Touch page – swap it in 0x40001000 0x40001040 → 0x4000104F virtual memory layout physical memory layout swapspace(disk) y[0] = x[0];

32. A Day in the Life of a Page • Touch page – swap it in 0x40001000 0x40001040 → 0x4000104F virtual memory layout physical memory layout swapspace(disk) y[0] = x[0];

33. Tricks with Page Tables: Sharing • Paging allows sharing of memory across processes • Reduces memory requirements • Shared stuff includes code, data • Code typically R/O

34. Tricks with Page Tables: COW • Copy on write (COW) • Just copy page tables • Make all pages read-only • What if process changes mem? • All processes are created this way!

35. Allocating Pages • ultimately from sbrk or mmap • Sbrk increases # of valid pages • Increases the heap • Mmap maps address space to file • Increases the mmap space • Oddity: • Allocators can use either mmap or brk to get pages • You will use mmap • What does mmap /dev/zero mean? • Think about COW

36. Overview • Replacement policies • Comparison

37. Cost of Paging • Usually in algorithms, we pick algorithm with best asymptotic worst-case • Paging: worst-case analysis useless! • Easy to construct adversary:every page requires page fault A, B, C, D, E, F, G, H, I, J, A... size of available memory

38. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault A A, B, C, D, E, F, G, H, I, J, A... size of available memory

39. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault A B A, B, C, D, E, F, G, H, I, J, A... size of available memory

40. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault A B C A, B, C, D, E, F, G, H, I, J, A... size of available memory

41. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault A B C D A, B, C, D, E, F, G, H, I, J, A... size of available memory

42. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault A B C D E A, B, C, D, E, F, G, H, I, J, A... size of available memory

43. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault F B C D E A, B, C, D, E, F, G, H, I, J, A... size of available memory

44. Cost of Paging • Worst-case analysis – useless • Easy to construct adversary example:every page requires page fault F G H I J A, B, C, D, E, F, G, H, I, J, A... size of available memory

45. Optimal Replacement (MIN/OPT) • Evict page accessed furthest in future • Optimal page replacement algorithm • Invented by Belady (“MIN”), a.k.a. “OPT” • Provably optimal policy • Just one small problem...Requires predicting the future • Useful point of comparison • How far from optimal

46. Quick Activity: OPT sequence of page accesses • Page faults: 5 contents of page frames

47. Least-Recently Used (LRU) • Evict page not used in longest time(least-recently used) • Approximates OPT • If recent past ≈ predictor of future • Variant used in all real operating systems

48. Quick Activity: LRU example • Page faults: ?

49. LRU example • Page faults: 5

50. LRU, example II • Page faults: ?