Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
Search cs492-stevens
Lectures
Lecture 32 Template
32 -
Outline
Least Recently Used (LRU)
Announcements
Reading:
Least Recently Used
Demand Paging & Prepaging
Not Frequently Used
Working Sets
Recall optimal: replace page most distantly used
Approximate optimal by examining history:
LRU: replace the oldest used page
Example:
Example:
Example: 3 frames
Issue:
Issues:
Issues:
We can fix it though.
Similar to NFU, but counter is instead a shift-
right value.
Example: 3 frames
3 frames
references
priority list
Priority List implementation
Hardware Counter implementation
Not Frequently Used (NFU)
Aging
Demand Paging vs. Prepaging
Working Sets
12 page faults. not optimal, but better than FIFO
Aging
1)
a)
b)
a)
2)
MOS 3.3 - 3.7
PA 5 due Friday
Page Replacement
-
-
-
Second Chance doesn't guarantee removal of
the oldest used page
recently, heavily used pages are likely to be
used again soon
long unused pages are not likely to be used
again soon
7 0 1 2 0 3 0 4 2 3 0 3 2 1 2 0 1 7 0 1
7 7 7 2 2 4 4 4 0 1 1 1
_ 0 0 0 0 0 0 3 3 3 0 0
_ _ 1 1 3 3 2 2 2 2 2 7
Pros:
Cons:
effective in terms of page faults
exact solution expensive to implement practically
-
-
-
-
-
-
most recently used at front
Pure software implementation
Updating on every reference is expensive!
Only evicts from current process
Linear search page table for lowest counter
not actually LRU: doesn't forget references.
tracks overall frequency of use, not recent use
Since the list is maintained by kernel, not limited
to current process pages.
least recently used at end
on every reference, move page to front
on page fault, evict page at end
4
7
7
0
1
0
4
7
0
0
0
0
7
7
1
1
7
7
4
4
4
Keep a hardware counter that increments on every
instruction.
Approximate LRU using clock and existing R bit
instead of dedicated counter
Algorithm:
-
-
MMU updates page table entry after each
reference with counter value
on page fault, OS replaces page with lowest
counter value
page table
600
415
220
347
1
2
3
4
1
2
2
3
1
2
3
4
0
0
0
0
frame #
frame #
evicted
frame #
0
1
2
3
...
...
references
page 2
page 1
page 2
page 3
page 1
page 0
@ C=47
@ C=114
@ C=220
@ C=347
@ C=415
@ C=600
-
-
-
-
-
-
adds 1 if page was recently used, 0 otherwise
approximates frequency of use
on clock interrupt, add R to PTE counter field,
then clear R bit
on page fault, evict page with lowest counter
-
-
(R bit only set once in an interval, regardless of # accesses)
page table counters
0
1
2
3
...
references
0, 1, 2
1, 0, 2, 1
1, 2, 1, 0
2, 0
0, 3
interrupt
update
interrupt
update
interrupt
update
interrupt
update
page
fault
Algorithm:
-
-
-
on clock interrupt, shift counter field right and
append R bit to left
on page fault, evict page with lowest counter
forgets bits after some number of interrupts
Example: 3 frames
1000
1100
1110
1111
0111
1000
1100
0110
1011
1101
1000
1100
1110
1111
1111
0000
0000
0000
0000
0000
page table counters
0
1
2
3
...
references
R bits
0, 1, 2
1110
1110
1110
1010
0110
1, 0, 2, 1
1, 2, 1, 0
2, 0
3
2, 1, 2
interrupt
interrupt
interrupt
interrupt
interrupt
page
fault
Issues:
Example: k = 10
Visualizations
Working Sets by Window Size (k)
In practice, pretty good.
So far, we've seen demand paging algorithms
We can attempt to avoid faults with prepaging.
Demand and prepaging are not mutually exclusive.
still not actually LRU:
linear search of counters on fault
-
-
-
-
-
-
-
-
-
-
-
-
counters can be kept on per-frame basis to
consider pages from other processes
pages are loaded ("fetched") on-demand,
not in advance.
pre-fetch pages and hope for fewer page faults
which pages and # of pages change over time
process spend most time waiting for kernel to
copy pages between RAM and disk
most time blocked on disk accesses (in kernel)
requires educated guessing!
always eat the initial page fault
-
-
limited past horizon (finite # bits)
limited information (clock interval)
what if multiple counters 0? pick at random
what if multiple counters same?
don't know which was first. pick at random
stack
heap
bss
data
code
faults
disk
fetch
Which pages to prefetch?
A process's working set is the the set of pages it
is actively using.
In practice, choice of k doesn't matter
significantly because of locality of references
the set of pages used by the k most recent
memory references
programs spend significant time in same place
If entire working set is loaded, no page faults
Next time: Working Set Algorithm
Thrashing occurs when there is insufficient
memory for the working set
Evangelos P. Markatos. 1997. Visualizing working sets.
SIGOPS Oper. Syst. Rev. 31, 4 (Oct. 1997), 3–11.
2 6 1 5 7 7 7 7 5 1 6 2 3 4 1 2 3 4 4 4 3 4 3 4 4 4 1 3 2 3 4 4 4
k
24
15
18
23
24
17
18
24
18
17
17
15
24
17
24
18
24
24, 15
15, 18
18, 23
23, 24
24, 17
17, 18
18, 24
-
18, 17
17
17, 15
15, 24
24, 17
-
24, 18
24
24, 15
24, 15, 18
15, 18, 23
18, 23, 24
23, 24, 17
24, 17, 18
-
18, 24
24, 18, 17
18, 17
17, 15
17, 15, 24
-
24, 17
17, 24, 18
24
24, 15
24, 15, 18
24, 15, 18, 23
-
18, 23, 24, 17
-
24, 17, 18
-
-
-
18, 17, 15
17, 15, 24
-
-
17, 24, 18
24
24, 15
24, 15, 18
24, 15, 18, 23
-
15, 18, 23, 24, 17
18, 23, 24, 17
-
24, 17, 18
-
-
24, 18, 17, 15
-
17, 15, 24
-
15, 17, 24, 18
references
k = 2
k = 3
k = 4
k = 5
Thrashing