1 / 47

CS519 Advanced Operating Systems Virtual Memory Layout

This recap discusses the concepts of virtual memory layout, page tables, and address translation in the context of operating systems. It covers the pros and cons of segmentation and paging, as well as the process of page table lookup and TLB caching.

jessem
Download Presentation

CS519 Advanced Operating Systems Virtual Memory Layout

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS519 Advanced Operating SystemsVirtual Memory Layout Yeongjin Jang 01/17/19

  2. Recap – Page Table & Addr Translation 31 12 0 0x08048000 Offset (12-bits) 0x000 Page number (20-bits) 0x08048 Directory Index (10-bits) 0x20 Table index (10-bits) 0x48 22 12 31 Physical access

  3. Recap CR3 • Segmentation • Access GDT Base,Limit • Translate to Linear Addr • Paging • CR3 – points to page directory • Higher 20 bits of the address • Page number • Highest 10 bits: Page Directory Index (PDX) • CR3 == pgdir, pgdir[PDX(va)] • Next 10 bits: Page Table Index (PTX) • pgdir[PDX(va)] == pgtbl • Pgtlb[PTX(va)] == PTE • Page table Entry • Highest 20 bits: Physical Page Number • Lower 12 bits: Offset • CR3[PDX(va)][PTX(va)] = PTE!

  4. Pros/Cons of Segmentation • Pros • Easy implementation (in hardware) • Read [Base address] and add offset • Small memory requirement • 8 byte for address translation in GDT (per each region) • Can allocate by the exact size (within 20bits limit) • Base = 0x10000, limit = 0x10 • Memory protection (DPL)

  5. Pros/Cons of Segmentation Program Data (64 KB) 0x58000 ~ 0x68000 (352KB ~ 416KB) Program Code - 2 (160KB) Free (128 KB) 0x38000 ~ 0x58000 (224KB ~ 352KB) Program Code (160KB) 0x10000 ~ 0x38000 (64KB ~ 224KB) • Cons • Fragmentation • Must allocate contiguous space for the region • Need to search for such region (regarding size) • Free: need to consolidate free memory chunks, etc.. • Memory protection placed for the entire region…

  6. Pros/Cons of Paging • Pros • No fragmentation (splitted by 4KB each blocks) • Not requiring allocating contiguous space • 0x8048000 -> 0x10000 • 0x8049000 -> 0xff000 • 0x804a000 -> 0xe0000 • Fast allocation • No need to search available blocks (just checks how many pages are available) • Free: removing PTE! • Memory protection can be enforced in page granularity • Part of region could have a different protection bits

  7. Pros/Cons of Paging • Cons • Internal fragmentation – wasting memory • Requiring 1 byte – allocate 4KB • Required 10 byte – allocate 4KB… • Storing a Page Table • 4MB for the full page table • At least 8KB (2 pages, one for PD and the other one for PT) is required… • Page table lookup for translation • Slow, requires a more complex hardware than segmentation

  8. Page Table Lookup • Access example • movl 0x12345678, %eax • (load 4 byte from 0x12345678 to %eax) • Memory access (pseudocode) • PGNUM = (0x12345678 & 0xfffff000) >> 12 • PDX = PGNUM >> 10 • PTX = PGNUM & 0x3ff • PTE = CR3[PDX][PTX] – 2 memory dereferences • PHY_ADDR = (PTE & 0xfffff000) + (0x12345678 & 0xfff) • eax = PHY_ADDR[0] – 1 memory dereferences (required)

  9. Recap – Page Table & Addr Translation 31 12 0 0x12345678 Offset (12-bits) 0x678 Page number (20-bits) 0x12345 Directory Index (10-bits) 0x48 Table index (10-bits) 0x345 22 12 31

  10. Page Table Lookup • Access 0x12345678 • Memory access (pseudocode) • PGNUM = (0x12345678 & 0xfffff000) >> 12 = 0x12345 • PDX = PGNUM >> 10 = 0x48 • PTX = PGNUM & 0x3f = 0x345 • PTE = CR3[PDX][PTX] – 2 memory dereferences • CR3[0x48][0x345] • PHY_ADDR = (PTE & 0xfffff000) + (0x12345678 & 0xfff) • eax = PHY_ADDR[0] – 1 memory dereferences (required)

  11. Page Table Lookup - Caching • Access example • movl 0x12345678, %eax • 3 memory access per each memory access – SLOW! • CPU caches Address Translation • Translation Lookaside Buffer (TLB)

  12. Translation Lookaside Buffer (TLB) 0x12345678 -> 0x678 0x12346678 -> 0x5678 0x12347678 -> 0xff678 0x12348678 -> 0xfff678 • Stores VA-PA mappings and cache them! • Benefits • Do not have to walk down page tables for cached entries

  13. Address Translation (Paging) TLB Hit! Access TLB 0x678! Address 0x12345678

  14. Address Translation (Paging) TLB Access TLB Address 0x12349678 TLB miss

  15. Address Translation (Paging) TLB Access TLB Address 0x12349678 Add an entry! TLB miss

  16. Why do we have TLB? • Core i7-6700K (Skylake, 4.00 GHz) • TLB hit requires 1 cycle, 0.25ns! • Page table walk requires 2 memory access for translation • 5 * 2 = 10 cycles if all blocks cached in L1 (2.5 ns, 10 times slower!) • Memory? (10ns * 2 + 51ns) = 71ns…

  17. We have limited entries in TLB • Core i7-6700K (Skylake, 4.00 GHz) • 64 items for L1 d-TLB, 1536 items for L2 d-TLB • CPU need to schedule this cache • Based on Temporal/Spatial locality…

  18. TLB Replacement Policy • Smart: LRU (Least Recently Used) • Mark when the block was accessed (update timestamp upon access) • When an eviction is required, evict the one with the oldest timestamp • Random • Do not do anything when accessed • When an eviction is required, evict an entry randomly… • Sometimes, this works better than LRU.. • We will learn more about such scheduling later • When we learn about process scheduling…

  19. Synchronizing TLB with Page Table • CPU uses the TLB for caching Page Table Entries • What will happen if content in TLB mismatches to the PTE in the page table? • Access wrong physical memory… • Does not honor the correct privilege in PTE (if we updated PTE after caching) • Running a new process with new CR3 • Use old process’s mapping, wrong access

  20. TLB and Page Table Update TLB Address 0x12349678

  21. TLB and Page Table Update TLB Address 0x12349678 Update

  22. TLB and Page Table Update TLB Address 0x12349678 We need to invalidate this entry Update

  23. TLB and Process Context Switch TLB Address 0x12349678 CR3

  24. TLB and Process Context Switch TLB Address 0x12349678 CR3

  25. TLB and Process Context Switch TLB Address 0x12349678 We need to invalidate all previous entries.. CR3

  26. Updating Page Table • When updating a Page Table Entry • We must invalidate TLB for that entry • invlpg

  27. Updating Page Table In JOS (kern/pmap.c & inc/x86.h)

  28. Summary • Segmentation – Pros/Cons • Paging – Pros/Cons • TLB • Benefits? • Scheduling? • Invalidating?

  29. Manipulating Page Tables in JOS • PGNUM(x) • Get the page number (x >> 12) of the address x • PDX(x) • Get the page directory index (top 10 bits) of the address x • PTX(x) • Get the page table index (mid 10 bits) of the address x • PGOFF(x) • Get the page offset (lower 12 bits) of the address x

  30. Manipulating Page Tables in JOS • PTE_ADDR(pte) • Get the physical address that a pte points • PTE_ADDR(pte) + PGOFF(x) • The physical address pointed by the PTE, translated by a virtual address x • Translate a virtual address va to physical address pa • pte = CR3[PDX(va)][PTX(va)] • pte_t **cr3 = lcr3(); # or, kern_pgdir • pte_t *pt = cr3[PDX(va)] • pte_tpte = pt[PTX(va)] • physaddr_t pa = PTE_ADDR(pte) + PGOFF(va);

  31. Virtual Memory Layout 0xffffffff OS 0xc000000 ~ 0xffffffff (1GB) 0xc0000000 Stack Libraries heap Program code/data 0x08048000 Each process maps VMs for both kernel and userspace

  32. Virtual Memory Layout 0xffffffff OS 0xc000000 ~ 0xffffffff (1GB) OS 0xc000000 ~ 0xffffffff (1GB) 0xc0000000 Stack Stack Libraries Libraries heap heap Program code/data Program code/data 0x08048000 • Each process will have almost the same mapping for the kernel but having a different mapping for userspace • Why? • Kernel is shared among processes • Each process could run different apps

  33. JOS Kernel Memory Layout Physical Memory (256MB) Virtual Memory (4GB) 0x10000000 Dirmap 0xf000000~0xffffffff (256MB) (KERNEL RW, User -) 0xf0000000 KERNBASE 0x00000000

  34. JOS Kernel Memory Layout Physical Memory (256MB) Virtual Memory (4GB) 0x10000000 Dirmap 0xf000000~0xffffffff (256MB) (KERNEL RW, User -) 0xf0000000 KERNBASE, KSTACKTOP PTSIZE 4MB 0x400000 Kernel Stack (4MB) (KERNEL RW, User -) 0xefc00000 MMIOLIM 0x00000000

  35. JOS Kernel Memory Layout Physical Memory (256MB) Virtual Memory (4GB) 0x10000000 Dirmap 0xf000000~0xffffffff (256MB) (KERNEL RW, User -) 0xf0000000 KERNBASE, KSTACKTOP PTSIZE 4MB 0x400000 Kernel Stack (4MB) (KERNEL RW, User -) 0xefc00000 MMIOLIM Memory-mapped I/O (4MB) (KERNEL RW, User -) PTSIZE 4MB 0x400000 0xef800000 MMIOBASE, ULIM 0x00000000

  36. JOS User Memory Layout Virtual Memory (4GB) Dirmap (256MB) Kernel Stack (4MB) Memory-mapped I/O (4MB) 0xef800000 ULIM Current Page Table (4MB) (Kernel R-, User R-) 0xef400000 UVPT RO Pages (4MB) (Kernel R-, User R-) 0xef000000 UVPT RO Envs (4MB) (Kernel R-, User R-) 0xeec00000 ENVS, UTOP User Exception Stack (4KB) (Kernel RW, User RW) 0xeebff000 Empty (4KB) (Kernel -, User -) 0xeebfe000 USTACKTOP

  37. JOS User Memory Layout Virtual Memory (4GB) Dirmap (256MB) Kernel Stack (4MB) Memory-mapped I/O (4MB) Current Page Table (4MB) RO Pages (4MB) Read inc/memlayout.h for more information! RO Envs (4MB) User Exception Stack (4KB) Empty (4KB) 0xeebfe000 USTACKTOP User Stack (4KB), RW, RW Free Space Program/data, RW, RW 0x800000 UTEXT Empty (8MB)

  38. Lab-2 Part1How JOS manages free Phys mem? • struct PageInfo • JOS will have a struct PageInfo entry per each physical pages.. • 256MB physical memory • 65536 entries (65536 * 4096 = 256MB)

  39. Lab-2 Part1How JOS manages free Phys mem? page_free_list: Linked list of free physical pages

  40. Lab-2 Part1How JOS manages free Phys mem? pp_link: indicates a pointer to the PageInfo of the next free page

  41. Lab-2 Part1How JOS manages free Phys mem? pp_link pp_link pp_link pp_link Free page 3 Free page 2 page_free_list Free page 1 pp_link: indicates a pointer to the PageInfo of the next free page

  42. Lab-2 Part1How JOS manages free Phys mem? • pp_ref: indicates how many virtual allocation was made • pp_ref != 0 // page is being used • pp_ref == 0 // page is not being used at all – free!

  43. Allocating a page (va->pa) • Get a page from page_free_list (let this be new_page) • Set page_free_list = new_page->pp_link • Maintain page_free_list • page_alloc() does this • Assigning PTE (done by other functions that uses page_alloc) • new_page->pp_ref += 1 • Set page table entry (va -> pa) • Store it to page directory • invalidate TLB

  44. Releasing a page • page->pp_ref -= 1; • if(page->pp_ref == 0) { • Add it to the page_free_list • page->pp_link = page_free_list; • page_free_list = page; • } • page_free() does this

  45. Type and Casting • uintptr_t • Used for indicating a virtual address (uint32_t) • physaddr_t • Used for indicating a physical address (uint32_t) • (void *), (char *) • Pointers, virtual address

  46. Type and Casting • How to use uintptr_tva? • (void *)va • char * c = (char *)va; c[0]; • int *i = (int *)va; i[0]; • struct PageInfo *pp = (struct PageInfo *) va; • How to use physaddr_t pa? • We can’t access physical address directly; use KADDR(x) • KADDR(x) adds KERNBASE to x • char *c = (char *c) KADDR(pa); c[0]; • struct PageInfo *pp = (struct PageInfo *) KADDR(pa);

  47. Other MACROs • page2kva(page) • Get the kernel virtual address of the page (struct PageInfo *) • E.g., physical_address_of_the_page + KERNBASE, 0xf??????? • Page2pa(page) • Get the physical address of the page (struct PageInfo *) • page2kva(page) == KADDR(page2pa(page)) • pa2page(pa) • Get the struct PageInfo *page that stores information about the pa • To get the pa for kva? • pa2page(PADDR(kva))

More Related