cps110: page replacement landon cox. replacement think of physical memory as a cache what happens...
TRANSCRIPT
CPS110: Page replacement
Landon Cox
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
Review of replacement algorithms
1. Random Easy implementation, not great results
2. 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
3. OPT (optimal) Replace the page that won’t be needed for longest
time Problem: requires knowledge of the future
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)
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
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
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
ClockTime 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
Clock
BB
AA
CCDD
EE
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP = Resident virtual pages
Physical page 0Physical page 0
Physical page 1Physical page 1
Physical page 2Physical page 2
Physical page 3Physical page 3
Physical page 4Physical page 4
Clock
BB
AA
CCDD
EE
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
When you need to evict a page:
Physical page 0Physical page 0
Physical page 1Physical page 1
Physical page 2Physical page 2
Physical page 3Physical page 3
Physical page 4Physical page 4
1) Check physical page pointed to by clock hand
Clock
BB
AA
CCDD
EE
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
When you need to evict a page:
Physical page 0Physical page 0
Physical page 1Physical page 1
Physical page 2Physical page 2
Physical page 3Physical page 3
Physical page 4Physical page 4
2) If reference=0, page hasn’t been touched in a while. Evict.
Clock
BB
AA
CCDD
EE
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
When you need to evict a page:
Physical page 0Physical page 0
Physical page 1Physical page 1
Physical page 2Physical page 2
Physical page 3Physical page 3
Physical page 4Physical page 4
3) If reference=1, page has been accessed since last sweep. What to do?
Clock
BB
AA
CCDD
EE
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
PPVPPPVP
When you need to evict a page:
Physical page 0Physical page 0
Physical page 1Physical page 1
Physical page 2Physical page 2
Physical page 3Physical page 3
Physical page 4Physical page 4
3) If reference=1, page has been accessed since last sweep. Set reference=0. Rotate clock hand. Try next page.
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
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)
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)
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
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!
Hardware page table info
What should go in a PTE?
Physical page #Physical page # ResidentResident Protection(read/write)Protection
(read/write) DirtyDirty ReferenceReference
What bits does a MMU need to make access decisions?
Set by OS to control translation. Checked by
MMU on each access.“page frame number”
PFN
Set by OS. Checked by
MMU on each access.
Set by OS to control access.
Checked by MMU on each access.
R, W
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.
MMU needs to know if resident, readable, or writable.Do we really need a resident bit? No, if non-resident, set R=W=0.
MMU algorithmif (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
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
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)
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
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
General idea for Project 2
1. Figure out what info to maintain E.g. dirty and reference bits
2. Figure out when to update this info What state is the page in? Which accesses change the page’s
state?
3. Set protections to generate faults Want faults on accesses in these states