Page Replacement Algorithms: TLB, Page Faults, and Paged Virtual Memory, Slides of Advanced Operating Systems

Download Page Replacement Algorithms: TLB, Page Faults, and Paged Virtual Memory and more Slides Advanced Operating Systems in PDF only on Docsity!

Lecture No.

Overview of today’s lecture

 Set associative and fully associative caches

 Demand Paging

 Page replacement algorithms

Fully associative TLB

 Fully associative caches have one element per bank, one comparator

per bank.

 Same set of options, whether you are building TLB or any kind of

cache. Typically, TLB's are small and fully associative.

 Hardware caches are larger, and direct mapped or set

 associative to a small degree.

 How do we choose which item to replace?

 For direct mapped, never any choice as to which item to

 replace. But for set associative or fully associative cache, have

 a choice. What should we do?

 Replace least recently used? Random? Most recently used?

 In hardware, often choose item to replace randomly, because it's simple

and fast. In software (for example, for page replacement), typically do

something more sophisticated. Tradeoff: spend CPU cycles to try to

improve cache hit rate.

 How do we implement this? How can a process run without

 access to a page table?

 Basic mechanism:

 1. TLB has "present" (valid) bit

 if present, pointer to page frame in memory

 if not present, use page table in memory

 2. Hardware traps to OS on reference not in TLB

 3. OS software:

 a. load page table entry into TLB

 b. continue thread

 All this is transparent -- job doesn't know it happened.

Reminder: Page Table Entries (PTEs)

 PTE‟s control mapping

 the valid bit says whether or not the PTE can be used  says whether or not a virtual address is valid  it is checked each time a virtual address is used  the referenced bit says whether the page has been accessed  it is set when a page has been read or written to  the modified bit says whether or not the page is dirty  it is set when a write to the page has occurred  the protection bits control which operations are allowed  read, write, execute  the page frame number determines the physical page  physical page start address = PFN

V R M prot page frame number

Page faults

 What happens when a process references a virtual address in a page

that has been evicted?

 when the page was evicted, the OS set the PTE as invalid and noted the disk location of the page in a data structure (that looks like a page table but holds disk addresses)  when a process tries to access the page, the invalid PTE will cause an exception (page fault) to be thrown  OK, it‟s actually an interrupt!  the OS will run the page fault handler in response  handler uses the “like a page table” data structure to locate the page on disk  handler reads page into a physical frame, updates PTE to point to it and to be valid  OS restarts the faulting process

Demand paging

 Pages are only brought into main memory when they are referenced

 only the code/data that is needed (demanded!) by a process needs to be loaded  What‟s needed changes over time, of course…  Hence, it‟s called demand paging

 Few systems try to anticipate future needs

 OS crystal ball module notoriously ineffective

 But it‟s not uncommon to cluster pages

 OS keeps track of pages that should come and go together  bring in all when one is referenced  interface may allow programmer or compiler to identify clusters

Page replacement  When you read in a page, where does it go?  if there are free page frames, grab one  what data structure might support this?  if not, must evict something else  this is called page replacement  Page replacement algorithms  try to pick a page that won‟t be needed in the near future  try to pick a page that hasn‟t been modified (thus saving the disk write)  OS typically tries to keep a pool of free pages around so that allocations don‟t inevitably cause evictions  OS also typically tries to keep some “clean” pages around, so that even if you have to evict a page, you won‟t have to write it  accomplished by pre-writing when there‟s nothing better to do

how does it all work?

 Locality!

 temporal locality  locations referenced recently tend to be referenced again soon  spatial locality  locations near recently referenced locations are likely to be referenced soon (think about why)

 Locality means paging can be infrequent

 once you‟ve paged something in, it will be used many times  on average, you use things that are paged in  but, this depends on many things:  degree of locality in the application  page replacement policy and application reference pattern  amount of physical memory vs. application “footprint” or “working set”

#1: Belady’s Algorithm

 Provably optimal: lowest fault rate (remember SJF?)

 evict the page that won‟t be used for the longest time in future  problem: impossible to predict the future

 Why is Belady‟s algorithm useful?

 as a yardstick to compare other algorithms to optimal  if Belady‟s isn‟t much better than yours, yours is pretty good  how could you do this comparison?

 Is there a best practical algorithm?

 no; depends on workload

 Is there a worst algorithm?

 no, but random replacement does pretty badly  there are some other situations where OS‟s use near- random algorithms quite effectively!

#2: FIFO

 FIFO is obvious, and simple to implement

 when you page in something, put it on the tail of a list  evict page at the head of the list

 Why might this be good?

 maybe the one brought in longest ago is not being used

 Why might this be bad?

 then again, maybe it is being used  have absolutely no information either way

 In fact, FIFO‟s performance is typically not good

 In addition, FIFO suffers from Belady‟s Anomaly

 there are reference strings for which the fault rate increases when the process is given more physical memory

Reference string: A B C A B D A D B C B FIFO Belady LRU A B C A B C A B C A B C A A B C A B C A B C B A B C A B C A B C D D B C A D A C D D A C B D A B C C A B B C A B Faults: FIFO 7 Belady 5 LRU 5

Implementing LRU  On every memory reference  time stamp each page  At eviction time:  scan for oldest  Keep a stack of page numbers

• On every reference, move the page on top of stack  Problems:  large page lists  no hardware support for time stamps  do something simple & fast that finds an old page  LRU an approximation anyway, a little more won‟t hurt…