Lecture 5: Virtual memory applications

Preparation

• Read OSPP §9, Caching and Virtual Memory and §10, Applications of Memory Management.
• Take a look at the lazy allocation exercise.

Lab 2 questions

• boot_alloc(): what should it “allocate” & return
• struct PageInfo: what’s allocating a page from the free list

• pgdir_walk(): why to allocate “a new page table page”

• It’s easy to “understand” the high-level concepts; implementing them is another story
• Go to this week’s section, office hours, or schedule extra hours

Virtual memory recap

• CPU asks OS to set up a data structure for VA → PA
• isolation: each process has its own address space
  • per-process page table; flags (P/W/U/…)
  • switch page table with process
  • JOS: inc/memlayout.h
  • xv6
    • struct proc in proc.h
    • scheduler() → switchuvm(p) → lcr3(v2p(p->pgdir))
  • Linux
    • cat /proc/iomem
    • cat /proc/self/map (or replace self with a PID)
    • are these physical or virtual addresses
• “All problems in computer science can be solved by another level of indirection”

Examples: protection, virtualization, lazy allocation

• implement null pointer dereference exception
  • how would you implement this for Java, say obj->field
  • trick: put a non-mapped page at VA zero
    • useful for catching program bugs
    • limitations?
• protect against stack overflow
  • see Michael Barr’s Bookout v. Toyota, “Toyota’s major stack mistakes”
  • trick: put a non-mapped page right below user stack
  • JOS: inc/memlayout.h
• limited physical memory
  • applications need more memory than physical memory
    • early days: two floppy drives
    • strawman: applications store part of state to disk and load back later
    • hard to write applications
  • virtual memory: offer the illusion of a large, continuous memory
    • swap space: OS pages out some pages to disk transparently
    • distributed shared memory: access other machines’ memory across network
• memory-mapped files
  • mmap(): map files, read/write files like memory
  • simple programming interface
  • when to page-in/page-out content?
  • avoid data copying: send an mmaped file to network
    • compare to using read/write
    • no data transfer from kernel to user
• multi-level paging
  • x86-32: two-level paging
  • x86-64: four-level paging
  • trade-off: space vs performance
  • other examples
    • Valgrind (used in CSE 333): two-level shadow table (Figure 1)
    • file systems: indirect blocks
• single zero page
  • often need to allocate a page with zeros to start with
  • trick: keep one zero page for all such pages
  • what if one process writes to the page?
• copy-on-write fork
  • strawman fork: copy all pages from parent to child
  • observation: child and parent share most of the data
    • mark pages as copy-on-write
    • make a copy on page fault
    • lab 4: you will implement user-level copy-on-write fork
  • other sharing
    • multiple guest OSes running inside the same hypervisor
    • shared objects: .so/.dll files
    • testing tool: exploring different program paths - KLEE
• virtual linear page tables: uvpt[n] gives the PTE of page n
  • self mapping: set one PDE to point to the page directory
  • CPU walks the tree as usual, but ends up in one level up
  • see UVPT for detail
• grow stack on demand: see this Friday’s in-class exercise