Virtual Memory: Overlays, Mapping, and TLBs

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 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 212=4096 byte pages. • How many pages? • 1 million!

7. Ex. Page table • Page table size = 24 • Page size = 212

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! (232/212) • 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. (228/212=216) • 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