Policies

• How do we decide which page to evict?
• What is the goal of our page replacement algorithm?
  • Maximize hit rate.
  • Actually, it is to minimize AMAT – which is almost always tied to maximizing hit rate.
• Compare the AMAT for two different hit rates:
  • memory access time 100ns.
  • disk access time: 10ms (or 10,000,000ns)
  • With a 90% hit rate, AMAT = 100 + .1 * 10,000,000 = 1,000,100ns — about 1ms.
    • Think about that – the average memory access takes 1,000,000 instructions? That can’t be right.
  • With a 99.9% hit rate, AMAT= 100 + .001 * 10,000,000 = 10,100ns — about 10 microseconds
    • 100x faster, but still too slow!
• Optimal
  • What is the optimal policy? How do we calculate it?
  • Why can’t we use it?
• FIFO
  • Why is this not a good policy?
• Belady’s Anomaly
  • 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5
  • What is hit rate with 3 pages?
  • What is hit rate with 4 pages?
• Stack property: Cache of size N + 1 always includes pages from cache of size N.
  • Can’t suffer from Belady’s Anomaly.
• Random:
  • Pros and cons?
• LRU
  • Remember, replacement is done in software, so pesudo-LRU not critical (as with hardware cache)
• Graphs https://pages.cs.wisc.edu/~remzi/OSTEP/vm-beyondphys-policy.pdf
  • 22.6 Random
    • With no locality, why do all algorithms behave the same?
    • Why is opt different?
  • 22.7 80/20
    • More locality to leverage
  • 22.8 Looping
    • Why are LRU and FIFO identical?
    • Wy is rand better?

Implementation

• What work must be done to implement each of the algorithms?
  • Random: “Just” draw a random number.
  • FIFO: Create a list on page replacement. (No work per access)
  • LRU: Work needed per access.
  • Naive LRU can be a performance bottleneck.
• How can hardware support help (without putting everything in HW)
  • Remember, we want to allow OS designers flexibility to implement different policies.
• Idea: Have the hardware update a timestamp in page table upon each memory access.

Approximating LRU

• Add a simple reference bit to the page table: Just set it whenever a page is referenced.
• Idea: Don’t worry about precise LRU. Just be sure to only evict pages that haven’t been referenced.
• Reset referenced bits to 0 when a page is evicted.
  • Since we have trapped into the OS, this isn’t a big deal.
• “Clock” algorithm:
  • Maintain a pointer that circles through the page table.
  • When a page must be evicted,
  • Circle through the page table.
  • If a page has a reference bit of 1, set it to 0 and move on.
  • If a page has a reference bit of 0, evict it.
  • If all pages have been referenced, pointer will circle around and evict the first page to 0.
• Notice:
  • Minimal accounting (a single bit set by hardware).
  • Don’t usually have to touch all the pages upon eviction.
  • Figure 22.9 shows small difference with LRU.
• Modifications to clock:
  • Prefer evicting “clean” pages
    • Why?
• Other optimizations:
  • Demand paging (waiting until memory is accessed to bring it in)
  • Prefetching (predicting that a page will be accessed soon)
  • Writing clusters of pages out at once
    • This is more efficient than one page at a time.

Thrashing

• Repeatedly moving pages on and off disk – destroying speed.
• What can we do?
  • Intentionally “starve” some processes?
  • Or at least run processes in batches, limiting how often pages need to be swapped out.
  • Kill a few memory intensive processes