CPS 110 Page replacement Landon Cox Replacement Think

CPS 110: 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-secondchance ê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-secondchance ê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

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

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

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

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

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

Clock A Physical page 0 Physical page 1 Physical page 2 E PP VP Physical page 3 PP VP Physical page 4 D B PP VP 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.

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? Protection Physical page # Resident (read/write) 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 Dirty Reference Set by MMU Set by when page is MMU touched. Used when by OS to see if page is modified. page has been referenced. Used by OS to see if page is decisions? modified. What bits does a MMU need to make access 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 algorithm if (VP # is invalid || non-resident || protected) { trap to OS fault handler } else { physical page = page. Table[virtual page]. phys. Page. Num physical address = {physical page}{offset} page. Table[virtual page]. referenced = 1 if (access is write) { page. Table[virtual page]. dirty = 1 } } Project 2: infrastructure performs MMU functions Note: P 2 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

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