Page Eviction

Limited Memory

• paging solves a lot of memory management problems
• but what if processes still need more memory after all frames are allocated?
• option 1: out of memory error, mobile OSes tend to kill processes that use too much memory to make space
• option 2: evict a mapped page, write the page to a storage device, then re-allocate its frame
  • why do we need to write the data to disk?
  • do we always have to write the data out?
• how to evict?
  • where can the write evicted page to?
  • swap partition: a section on disk reserved for storing evicted pages
  • need to track allocation status of the swap partition
  • often uses a bitmap to track free space inside the swap partition
  • need to maintain bookkeeping structures so we can find the page later when it's accessed again
  • how to reflect the result of an eviction?
  • remove the page to frame mapping from the page table (set present bit to false)
    • how to ensure that page will not be modified while being written out to swap?
    • what if there are multiple pages mapped to the frame?
  • what about the TLB?
  • reuse the frame
  • after the page is evicted, can we just map its frame to another process?
• what to evict?
  • eviction policies set by the OS

Eviction Policies

• what pages should be our eviction candidates?
  • do we only consider pages within the faulting process?
  • do we also consider all mapped pages?
  • are all pages equal?
  • do we want to evict kernel code and data pages?
  • what about shared library pages?
  • do all pages need to be written out to swap when evicted?
  • do we want to evict pages that will be accessed soon?
• eviction policies
  • FIFO:
    • evicts pages that were mapped first
    • just need to maintain a queue of allocated frames, simple impl
    • what access pattern might work poorly for this?
    • Belady's anomaly: increasing # of frames can cause more page faults
    • do we expect this to do well at reducing page faults?
  • LRU:
    • evicts pages that were least recently used
    • uses history (access patterns) to predict the future
    • what access pattern might work poorly for this?
    • would LRU suffer from Belady's anomaly?
    • how would we implement this?
  • Clock:
    • approximates LRU
    • uses the access bit inside a page table entry (pte), bit set by hardware whenever the page is accessed (brought into TLB)
    • algorithm:
      
      1. track a clock hand (starting frame to look at for eviction)
      2. look at the frame at the clock hand, check the page table entry for the mapped page
      3. if pte's access bit is 0, select the page to evict, advance the clock hand to the next frame
      4. if pte's access bit is 1, clear the access bit to 0, shootdown TLB entry, advance the clock hand, and go to step 2
    • takes access patterns into account, but doesn't take costs of evicting a page into account
  • Enhanced Clock (Second Chance):
    • clock but look at both access and dirty bit
    • if page is not dirty then we don't need to write it out (cheaper)
    • conditions:
      1. if access is 0 and dirty is 0, select page to evict, advance the clock hand
      2. if access is 1 and dirty is 0, clear access bit, advance the clock hand, keep searching
      3. if access is 0 and dirty is 1, clear dirty bit (track the dirty info elsewhere), advance the clock hand, keep searching
      4. if access is 1 and dirty is 1, clear access bit, advance the clock hand, keep searching