Page Replacement Algorithms

n First-In-First-Out (FIFO)
n Throw out the oldest page
Pros: Low-overhead implementation
Demand Paging
n

n Cons: May replace the heavily used pages

n Optimal or MIN
n Replace the page that won’t be used for the longest time
n Minimal page faults, but offline algorithm
Arvind Krishnamurthy
n Least Recently Used (LRU)
Spring 2001 n Replace page that hasn’t been used for the longest time

n Question
n What hardware mechanisms are required to implement LRU?

Implementing LRU Clock: Simple FIFO + 2nd Chance

Least Oldest page
Mostly
recently used 5 3 4 7 9 11 2 1 15 recently used

n Faithful Implementation:
n Use a timestamp on each reference n FIFO clock algorithm
n Keep a list of pages ordered by time of reference n Hand points to the oldest page
n Impractical: because for every memory reference, the queue n On a page fault, follow the hand to inspect pages
is modified n Second chance
n Approximation: n If the reference bit is 1, set it to 0 and advance the hand
n Use reference bits n If the reference bit is 0, use it for replacement
n If page to be replaced, has reference bit set: n What does it mean if the clock hand is moving slowly?
n Do not discard page, but clear reference bit n What does it mean if the clock hand is moving fast?

Enhanced Clock Not Recently Used (NRU)

Oldest page n Algorithm
n Randomly pick a page from the following (in this order)
n Not referenced and not modified

n Not referenced and modified

n Referenced and not modified

n Referenced and modified

n FIFO clock algorithm n Pros

n One hand went and reset the accessed field n Easy to implement
n Second hand swapped the page out if accessed field is still zero n Cons
n How big should the span be? n Not very good performance and also takes time to classify
n If small, not give enough time for page to be accessed
n If large, then access bit might always be set
n More scanning at page allocation time

1
 Enhanced FIFO with 2nd-chance Dealing with modified pages
n Same as the basic FIFO with 2nd chance, except that this n Replacement cost includes:
method considers both reference bit and modified bit n Cost of writing modified page out
n (0,0): neither recently used nor modified n Cost of reading a new page in
n (0,1): not recently used but modified
n (1,0): recently used but clean n Decrease this cost by:
n (1,1): recently used and modified n Having a background process constantly writing out modified pages
n Pros n Reasoning: keep I/O device occupied

n Avoid write back n Or by having a pool of free frames:

n Free a frame in advance
n Cons
n But remember which page used to live there
n More complicated
n If the same page is referenced, mark it as valid

n Else, it provides space for newly reference pages

More page frames →fewer faults? State per page table entry
n Consider the following reference string with 4 page frames Many machines maintain four bits per page table entry:
n FIFO replacement
n 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5 n use (aka reference): set when page is referenced,
n 10 page faults cleared by “clock algorithm”
n Consider the same reference string with 3 page frames
n modified (aka dirty): set when page is modified, cleared
FIFO replacement
when page is written to disk
n

n 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5
n 9 page faults! n valid (aka present): ok for program to reference this
n This is called Belady’s anomaly page
n LRU does not suffer from this anomaly n read-only: ok for program to read page, but not to modify
n In general, if algorithm satisfies “stack property” (pages that are it (e.g., for catching modifications to code pages)
resident with larger memory are a superset of pages that are
resident with smaller memory) then algorithm avoids this anomaly

Used and modified bits State in software-loaded TLB

n Do we really need to set these bits for every page access? n What if we have software-loaded TLB (as in Nachos)?

n Trick to avoid setting use bit for every reference: n Hardware sets use bit in TLB; when TLB entry is replaced,
n When use bit is to be cleared, also set the invalid bit for the PTE software copies use bit back to page table
n When page is accessed, trap to OS n Setting use bit is very fast operation
n reset invalid bit and set the use bit as well n Combined with address translation operation

n Trick to avoid setting modified bit for every reference: n Software manages TLB entries as FIFO list; everything not
n When page is brought in, set it to “read-only” in TLB is second-chance list (managed as strict LRU).
n When write happens, trap to OS
n Set modified bit, and reset “read-only”
n Insight: TLB filters out most of the overhead

2
 How many pages are allocated to
each process ? Fixed allocation
n Each process needs minimum number of pages.
n Equal allocation – e.g., if 100 frames and 5
processes, give each 20 pages.
n Example: IBM 370 – 6 pages to handle SS MOVE
n Proportional allocation – Allocate according to
instruction:
the size of process.
n instruction is 6 bytes, might span 2 pages.
n 2 pages to handle from. si = size of process pi
2 pages to handle to. S = ∑ si
n m = 64
m = total number of frames
s1 = 10
s
n Two major allocation schemes. ai = allocation for pi = i × m s2 = 127
S
fixed allocation 10
n a1 = × 64 ≈ 5
137
n priority allocation
127
a2 = × 64 ≈ 59
137

What to do when not enough

Priority allocation memory?
n Use a proportional allocation scheme using priorities rather than size. n Thrashing: processes on system require more memory than it has.

n If process Pi generates a page fault,

n select for replacement one of its frames. P1 P2 P3
n select for replacement a frame from a process with lower priority number.
Real mem
n Global replacement – process selects a replacement frame from the set
nEach time one page is brought in, another page, whose contents will
of all frames; one process can take a frame from another. soon be referenced, is thrown out.
n Processes will spend all of their time blocked, waiting for pages to be

n Local replacement – each process selects from only its own set of fetched from disk
n I/O devs at 100% utilization but system not getting much useful
allocated frames.
work done
n What we wanted: virtual memory the size of disk with access time
of of physical memory
n What we have: memory with access time = disk access

Thrashing When does thrashing happen?

n Process(es) “frequently”reference page not in memory n (Over-)simple calculation of average access time:
n Spend more time waiting for I/O then getting work done
n Three different reasons Let h = percentage of references to pages in memory
n process doesn’t reuse memory, so caching doesn’t work Then average access time is
n process does reuse memory, but it does not “fit” h * (cost of memory access)
+ (1-h) * (cost of disk access)
For current technology, this becomes (about)
h * (0.3 microseconds) + (1-h) * (10 milliseconds)
P1 Assume 1 out of 100 references misses.
= .99 * (300 ns) + .01 (10ms)
mem = .99 (300 ns) + .01 (10,000,000ns)
n individually, all processes fit and reuse memory, but too many for = 297 + 100,000 ~ 100 microseconds
system. n or, 300x slower than main memory.
n Which can we actually solve? n Even small miss rates lead to unacceptable average access
times. Can OS help?

3
 Making the best of a bad
situation Methodology for solving?
n Single process thrashing? n Approach 1: working set
n If process does not fit or does not reuse memory, OS can do n thrashing viewed from a caching perspective
nothing! n given locality of reference, how big a cache does the process need?
n Or: how much memory does process need in order to make
n System thrashing? “reasonable” progress (its working set)?
n If thrashing arises because of the sum of several processes then n Only run processes whose memory requirements can be satisfied.
adapt: n Approach 2: page fault frequency
n figure out how much memory each process needs n thrashing viewed as poor ratio of fetch to work
n change scheduling priorities to run processes in groups whose n PFF = page faults / instructions executed
memory needs can be satisfied (shedding load) n if PFF rises above threshold, process needs more memory
n if new processes try to start, can refuse (admission control)
n not enough memory on the system? Swap out.

n if PFF sinks below threshold, memory can be taken away

Working set (1968, Denning) Scheduling: the balance set

n What we want to know: collection of pages process must n If sum of working sets of all runnable processes fits in memory, then
have in order to avoid thrashing scheduling same as before.
n This requires knowing the future. n If they do not fit, then refuse to run some
n How?
n Working set: n Divide into two groups:
n pages referenced by process in last T seconds of execution n active: working set loaded
considered to comprise its working set
n inactive: working set intentionally not loaded

n T: the working set parameter n balance set: sum of working sets of all active processes
n Uses? n Long term scheduler:
n Page replacement: preferentially discard non-working set pages n Keep moving processes from active à inactive until balance set less
n Scheduling: process not executed unless working set in main than memory size.
memory n Must allow inactive to become active. What happens if this changes too
frequently?
n As working set changes, must update balance set…

How to implement working set? Some problems

n Associate an idle time with each page frame n T is magic
n idle time = amount of CPU time received by process since last n what if T too small? Too large?
access to page n How did we pick it? Usually “try and see”
n page’s idle time > T? page not part of working set n Fortunately, systems aren’t too sensitive
n What processes should be in the balance set?
n How to calculate? n Large ones so that they exit faster?
n Scan all resident pages of a process n Small ones since more can run at once?
n use bit on? clear page’s idle time, clear use bit
n How do we compute working set for shared pages?
n use bit off? add process CPU time (since last scan) to idle time
n How much memory is needed in order to keep CPU busy?
n Unix:
n scan happens every few seconds

n T on order of a minute or more

4
 Working sets of real programs Working set less important
n The concept is a good perspective on system behavior.
n As a technique for system optimization it’s less important
Working set size

n While early time sharing systems thrashed distressingly often,

current systems much less so.
n Have OS designers gotten smarter? No. It’s the hardware
guys:
n Memory much larger (more to go around)
n CPU faster (jobs exit quicker, return memory to freelist)
n While some applications can eat as much as you give, the
percentage of them that have “enough” seems to be increasing.
n These will also show up as big factors for file systems
n Typical programs have phases: transition, stable n More generally, while performance was very important OS

n working set of one may have little to do with other research topic in 80-90s, less so now
n balloons during transitions

Virtual memory: a summary

n Goal: multiprogramming with protection + illusion of
infinite memory
n Approaches
n HW-based solution for protection
n dual mode operation + address space

n address translation: virtual address à physical address

n segmentation + paging + multilevel paging

n making address translation faster? use TLB

n demand paged virtual memory
n techniques for dealing with thrashing
n Other topics
n kernel memory allocator (similar to malloc-free packages)
n virtual memory-based hack (exploiting page fault)