1. 4.3 Virtual Memory

2. Virtual memory  Want to run programs (code+stack+data) larger than available memory.  Overlays programmer divides program into pieces OS move pieces in and out from disk  Virtual memory – OS automates overlays  Virtual addresses vs. physical addresses

3. CPU MMU translates virtual addresses to physical addresses

4. Memory unit = page ge is not currently in memory. X indicates that the page is not currently in memory.

5. Mapping virtual to physical addresses  Done in hardware for speed.  Virtual address = page number and offset within page  Each process has its own page table. can be quite large  physical address = pageTable[pageNumber] + offset must be fast  Page fault occurs when a page is not in memory and is referenced.

6. Ex. 32 bit virtual address space  Given 32 bit virtual address space.  Given 2 12 =4096 byte pages.  How many pages? 1 million!

7. Ex. Page table  Page table size = 2 4  Page size = 2 12

8. Multilevel page tables

9. Example page table entry  Caching disabled bit = use device, not cache) (used for memory mapped I/O)  Referenced = used bit  Modified = “dirty” bit  Protection = R W X access flags  Present = in memory flag  Page frame number

10. TLBs – translation lookaside buffers  Problem: Page tables are large and are therefore kept in main memory. This impacts performance. Consider an instruction that moves data from one register to another.  W/out paging, this makes only one memory reference (to fetch the instruction).  W/ paging, additional memory references are required to access the page table.  Solution: “cache” frequently used page table entries

11. TLBs – translation lookaside buffers  Problem: Page tables are large and are therefore kept in main memory.  Solution: “cache” frequently used page table entries  This is effective because most programs make a large number of references to a small number of pages.

12. TLBs – translation lookaside buffers  a.k.a. associative memory Lookup/search occurs in parallel in hardware  8 to 64 entries  “cache” of frequently used page table entries

13. Inverted page tables  Problem: Using virtual to physical page tables:  Indexed by virtual page number.  Over 1 million entries for 4K pages on a 32 bit system! (2 32 /2 12 )  Over 30 million gigabytes on a 64 bit system!  But our 64 bit system may only 256M RAM!

14. Inverted page tables  Problem: Using virtual to physical page tables.  Solution: Use one entry per physical page (rather then one entry per virtual page)  Ex. A 64 bit system with 256M RAM and 4K pages requires an inverted page table with only 64K entries. (2 28 /2 12 =2 16 )  But search for virtual to physical translation becomes hard (slow)! Why?

15. Inverted page tables  Problem: Using virtual to physical page tables.  Solution: Use one entry per physical page (rather then one entry per virtual page)  But search for virtual to physical translation becomes hard (slow)! Why?  Because every time process p references virtual page p, we must search the IPT for an entry (n,p) for every memory reference – not just the page faults!  Solution:  Use TLB and hash table

16. Inverted page tables  Problem: Using virtual to physical page tables.  Solution: Use one entry per physical page (rather then one entry per virtual page)  But search for virtual to physical translation becomes hard (slow)!  Solution:  Use TLB for heavily used pages and a hash table for TLB misses.

17. Page table vs. inverted page table