CPS110: Page replacement

1. CPS110: Page replacement Landon Cox

2. Replacement • Think of physical memory as a cache • What happens on a cache miss? • Page fault • Must decide what to evict • Goal: reduce number of misses

3. Review of replacement algorithms • Random • Easy implementation, not great results • FIFO (first in, first out) • Replace “oldest” page (that came in longest ago) • Popular pages often come in early • Problem: doesn’t consider last time used • OPT (optimal) • Replace the page that won’t be needed for longest time • Problem: requires knowledge of the future

4. Review of replacement algorithms • LRU (least-recently used) • Use past references to predict future • Evict “coldest” page • Exploit “temporal locality” • Problem: expensive to implement exactly • Why? • Either have to keep sorted list • Or maintain time stamps + scan on eviction • Update info on every access (ugh)

5. LRU • LRU is just an approximation of OPT • Could try approximating LRU instead • Don’t have to replace coldest page • Just replace a cold page

6. LRU approximations • Clock algorithm, or FIFO-second-chance • What can the hardware give us? • “Reference bit” for each PTE • Set each time page is accessed • Why is this done in hardware? • May be slow to do in software

7. LRU approximations • Clock algorithm, or FIFO-second-chance • What can the hardware give us? • “Reference bit” for each PTE • Set each time page is accessed • What do “cold” pages look like to OS? • Clear all bits • Check later to which are set

8. Clock Time 0: clear reference bit for page . . . Time t: examine reference bit • Splits pages into two classes • Those that have been touched lately • Those that haven’t been touched lately • Clearing all bits simultaneously is slow • Sample them to spread work out over time

9. Clock A PP VP E B Physical page 0 PP VP PP VP Physical page 1 Physical page 2 Physical page 3 PP VP PP VP Physical page 4 D C PP VP = Resident virtual pages

10. Clock A PP VP E B Physical page 0 PP VP PP VP Physical page 1 Physical page 2 Physical page 3 PP VP PP VP Physical page 4 D C When you need to evict a page: 1) Check physical page pointed to by clock hand

11. Clock A PP VP E B Physical page 0 PP VP PP VP Physical page 1 Physical page 2 Physical page 3 PP VP PP VP Physical page 4 D C When you need to evict a page: 2) If reference=0, page hasn’t been touched in a while. Evict.

12. Clock A PP VP E B Physical page 0 PP VP PP VP Physical page 1 Physical page 2 Physical page 3 PP VP PP VP Physical page 4 D C When you need to evict a page: 3) If reference=1, page has been accessed since last sweep. What to do?

13. Clock A PP VP E B Physical page 0 PP VP PP VP Physical page 1 Physical page 2 Physical page 3 PP VP PP VP Physical page 4 D C When you need to evict a page: 3) If reference=1, page has been accessed since last sweep. Set reference=0. Rotate clock hand. Try next page.

14. Clock • Does this cause an infinite loop? • No. • First sweep sets all to 0, evict on next sweep • What about new pages? • Put behind clock hand • Set reference bit to 1 • Maximizes chance for page to stay in memory

15. Paging out • What can we do with evicted pages? • Write to backing store (e.g., disk, also known as “swap space”) • When don’t you need to write to disk? • Disk already has data (page is clean) • Can recompute page content (zero page)

16. Paging out • Why set the dirty bit in hardware? • If set on every store, too slow for software • Why not write to disk on each store? • Too slow • Better to defer work • You might not have to do it! (except in 110)

17. Paging out • When does work of writing to disk go away? • If you store to the page again • If the owning process exits before eviction • Project 2: other work you can defer • Initializing a page with zeroes • Taking faults

18. Paging out • Faulted-in page must wait for disk write • Can we avoid this work too? • Evict clean (non-dirty) pages first • Write out (“clean”) pages during idle periods • Project 2: don’t do either of these!

19. Hardware page table info • What should go in a PTE? Physical page # Resident Protection (read/write) Dirty Reference Set by OS. Checked by MMU on each access. Set by MMU when page is modified. Used by OS to see if page is modified. Set by MMU when page is touched. Used by OS to see if page has been referenced. Set by OS to control translation. Checked by MMU on each access. “page frame number” PFN Set by OS to control access. Checked by MMU on each access. R, W What bits does a MMU need to make access decisions? MMU needs to know if resident, readable, or writable. Do we really need a resident bit? No, if non-resident, set R=W=0.

20. MMU algorithm if (VP # is invalid || non-resident || protected) { trap to OS fault handler } else { physical page = pageTable[virtual page].physPageNum physical address = {physical page}{offset} pageTable[virtual page].referenced = 1 if (access is write) { pageTable[virtual page].dirty = 1 } } Project 2: infrastructure performs MMU functions Note: P2 page table entry definition has no dirty/reference bits

21. Hardware page table entries • Do PTEs need to store disk block nums? • No • Only the OS needs this (the MMU doesn’t) • What per page info does OS maintain? • Which virtual pages are valid • Locations of virtual pages on backing store

22. Hardware page table entries • Do we really need a dirty bit? • Claim: OS can emulate at a reasonable overhead. • How can OS emulate the dirty bit? • Keep the page read-only • MMU will fault on a store • OS/you now know that the page is dirty • Do we need to fault on every store? • No. After first store, set page writable • When do we make it read-only again? • When it’s clean (e.g. written to disk and paged in)

23. Hardware page table entries • Do we really need a reference bit? • Claim: OS can emulate at a reasonable overhead. • How can OS emulate the reference bit? • Keep the page unreadable • MMU will fault on a load/store • OS/you now knows that the page has been referenced • Do we need to fault on every load/store? • No. After first load/store, set page readable

24. Application’s perspective • VM system manages page permissions • Application is totally unaware of faults, etc • Most OSes allow apps to request page protections • E.g. make their code pages read-only • E.g., Unix mprotect() system call used by proj 2 paging infrastructure • Project 2 • App has no control over page protections • App assumes all pages are read/writable

25. General idea for Project 2 • Figure out what info to maintain • E.g. dirty and reference bits • Figure out when to update this info • What state is the page in? • Which accesses change the page’s state? • Set protections to generate faults • Want faults on accesses in these states