Ch10-Virtual Memory
Ch10-Virtual Memory
Operating System Concepts – 10th Edition 10.2 Silberschatz, Galvin and Gagne
Objectives
Operating System Concepts – 10th Edition 10.3 Silberschatz, Galvin and Gagne
Background
Code needs to be in memory to execute, but entire
program rarely used
• Error code, unusual routines, large data structures
Entire program code not needed at same time
Consider ability to execute partially-loaded program
• Program no longer constrained by limits of physical
memory
• Each program takes less memory while running ->
more programs run at the same time
Increased CPU utilization and throughput with no
increase in response time or turnaround time
• Less I/O needed to load or swap programs into
memory -> each user program runs faster
Operating System Concepts – 10th Edition 10.4 Silberschatz, Galvin and Gagne
Virtual memory
Operating System Concepts – 10th Edition 10.5 Silberschatz, Galvin and Gagne
Virtual memory (Cont.)
Operating System Concepts – 10th Edition 10.6 Silberschatz, Galvin and Gagne
Virtual Memory That is Larger Than Physical Memory
Operating System Concepts – 10th Edition 10.7 Silberschatz, Galvin and Gagne
Virtual-address Space
Usually design logical address
space for stack to start at Max
logical address and grow “down”
while heap grows “up”
• Maximizes address space
use
• Unused address space
between the two is hole
No physical memory
needed until heap or
stack grows to a given
new page
Enables sparse address spaces
with holes left for growth,
dynamically linked libraries, etc.
System libraries shared via
mapping into virtual address
space
Shared memory by mapping
pages read-write into virtual
address space
Operating System Concepts – 10th Edition 10.8 Silberschatz, Galvin and Gagne
Shared Library Using Virtual Memory
Operating System Concepts – 10th Edition 10.9 Silberschatz, Galvin and Gagne
Demand Paging
Operating System Concepts – 10th Edition 10.10 Silberschatz, Galvin and Gagne
Demand Paging
Operating System Concepts – 10th Edition 10.11 Silberschatz, Galvin and Gagne
Basic Concepts
With swapping, pager guesses which pages will be used
before swapping out again
Instead, pager brings in only those pages into memory
How to determine that set of pages?
• Need new MMU functionality to implement demand
paging
If pages needed are already memory resident
• No difference from non demand-paging
If page needed and not memory resident
• Need to detect and load the page into memory from
storage
Without changing program behavior
Without programmer needing to change code
Operating System Concepts – 10th Edition 10.12 Silberschatz, Galvin and Gagne
Valid-Invalid Bit
With each page table entry a valid–invalid bit is
associated
(v in-memory – memory resident, i not-in-memory)
Initially valid–invalid bit is set to i on all entries
Example of a page table snapshot:
Operating System Concepts – 10th Edition 10.13 Silberschatz, Galvin and Gagne
Page Table When Some Pages Are Not
in Main Memory
Operating System Concepts – 10th Edition 10.14 Silberschatz, Galvin and Gagne
Steps in Handling Page Fault
Operating System Concepts – 10th Edition 10.15 Silberschatz, Galvin and Gagne
Steps in Handling a Page Fault (Cont.)
Operating System Concepts – 10th Edition 10.16 Silberschatz, Galvin and Gagne
Aspects of Demand Paging
Operating System Concepts – 10th Edition 10.17 Silberschatz, Galvin and Gagne
Instruction Restart
Operating System Concepts – 10th Edition 10.18 Silberschatz, Galvin and Gagne
Free-Frame List
Operating System Concepts – 10th Edition 10.19 Silberschatz, Galvin and Gagne
Stages in Demand Paging – Worse Case
Operating System Concepts – 10th Edition 10.20 Silberschatz, Galvin and Gagne
Stages in Demand Paging (Cont.)
Operating System Concepts – 10th Edition 10.21 Silberschatz, Galvin and Gagne
Performance of Demand Paging
Three major activities
• Service the interrupt – careful coding means just
several hundred instructions needed
• Read the page – lots of time
• Restart the process – again just a small amount of
time
Page Fault Rate 0 p 1
• if p = 0 no page faults
• if p = 1, every reference is a fault
Effective Access Time (EAT)
EAT = (1 – p) x memory access
+ p (page fault overhead
+ swap page out
+ swap page in )
Operating System Concepts – 10th Edition 10.22 Silberschatz, Galvin and Gagne
Demand Paging Example
Memory access time = 200 nanoseconds
Average page-fault service time = 8 milliseconds
EAT = (1 – p) x 200 + p (8 milliseconds)
= (1 – p x 200 + p x 8,000,000
= 200 + p x 7,999,800
If one access out of 1,000 causes a page fault, then
EAT = 8.2 microseconds.
This is a slowdown by a factor of 40!!
If want performance degradation < 10 percent
• 220 > 200 + 7,999,800 x p
20 > 7,999,800 x p
• p < .0000025
• < one page fault in every 400,000 memory accesses
Operating System Concepts – 10th Edition 10.23 Silberschatz, Galvin and Gagne
Demand Paging Optimizations
Swap space I/O faster than file system I/O even if on the same
device
• Swap allocated in larger chunks, less management needed
than file system
Copy entire process image to swap space at process load time
• Then page in and out of swap space
• Used in older BSD Unix
Demand page in from program binary on disk, but discard
rather than paging out when freeing frame
• Used in Solaris and current BSD
• Still need to write to swap space
Pages not associated with a file (like stack and heap) –
anonymous memory
Pages modified in memory but not yet written back to
the file system
Mobile systems
• Typically don’t support swapping
• Instead, demand page from file system and reclaim read-
only pages (such as code)
Operating System Concepts – 10th Edition 10.24 Silberschatz, Galvin and Gagne
Copy-on-Write
Copy-on-Write (COW) allows both parent and child processes to
initially share the same pages in memory
• If either process modifies a shared page, only then is the
page copied
COW allows more efficient process creation as only modified
pages are copied
In general, free pages are allocated from a pool of zero-fill-on-
demand pages
• Pool should always have free frames for fast demand page
execution
Don’t want to have to free a frame as well as other
processing on page fault
• Why zero-out a page before allocating it?
vfork() variation on fork() system call has parent suspend and
child using copy-on-write address space of parent
• Designed to have child call exec()
• Very efficient
Operating System Concepts – 10th Edition 10.25 Silberschatz, Galvin and Gagne
Before Process 1 Modifies Page C
Operating System Concepts – 10th Edition 10.26 Silberschatz, Galvin and Gagne
After Process 1 Modifies Page C
Operating System Concepts – 10th Edition 10.27 Silberschatz, Galvin and Gagne
What Happens if There is no Free Frame?
Used up by process pages
Also in demand from the kernel, I/O buffers, etc
How much to allocate to each?
Page replacement – find some page in memory, but not
really in use, page it out
• Algorithm – terminate? swap out? replace the page?
• Performance – want an algorithm which will result in
minimum number of page faults
Same page may be brought into memory several times
Operating System Concepts – 10th Edition 10.28 Silberschatz, Galvin and Gagne
Page Replacement
Prevent over-allocation of memory by modifying page-fault
service routine to include page replacement
Use modify (dirty) bit to reduce overhead of page transfers
– only modified pages are written to disk
Page replacement completes separation between logical
memory and physical memory – large virtual memory can
be provided on a smaller physical memory
Operating System Concepts – 10th Edition 10.29 Silberschatz, Galvin and Gagne
Need For Page Replacement
Operating System Concepts – 10th Edition 10.30 Silberschatz, Galvin and Gagne
Basic Page Replacement
1. Find the location of the desired page on disk
2. Find a free frame:
- If there is a free frame, use it
- If there is no free frame, use a page replacement
algorithm to select a victim frame
- Write victim frame to disk if dirty
3. Bring the desired page into the (newly) free frame;
update the page and frame tables
4. Continue the process by restarting the instruction that
caused the trap
Operating System Concepts – 10th Edition 10.31 Silberschatz, Galvin and Gagne
Page Replacement
Operating System Concepts – 10th Edition 10.32 Silberschatz, Galvin and Gagne
Page and Frame Replacement Algorithms
Operating System Concepts – 10th Edition 10.33 Silberschatz, Galvin and Gagne
Graph of Page Faults Versus the Number of Frames
Operating System Concepts – 10th Edition 10.34 Silberschatz, Galvin and Gagne
First-In-First-Out (FIFO) Algorithm
Reference string:
7,0,1,2,0,3,0,4,2,3,0,3,0,3,2,1,2,0,1,7,0,1
3 frames (3 pages can be in memory at a time per
process)
15 page faults
Operating System Concepts – 10th Edition 10.35 Silberschatz, Galvin and Gagne
FIFO Illustrating Belady’s Anomaly
Operating System Concepts – 10th Edition 10.36 Silberschatz, Galvin and Gagne
Optimal Algorithm
Replace page that will not be used for longest period of
time
• 9 is optimal for the example
How do you know this?
• Can’t read the future
Used for measuring how well your algorithm performs
Operating System Concepts – 10th Edition 10.37 Silberschatz, Galvin and Gagne
Least Recently Used (LRU) Algorithm
Operating System Concepts – 10th Edition 10.38 Silberschatz, Galvin and Gagne
LRU Algorithm (Cont.)
Counter implementation
• Every page entry has a counter; every time page is
referenced through this entry, copy the clock into the
counter
• When a page needs to be changed, look at the
counters to find smallest value
Search through table needed
Stack implementation
• Keep a stack of page numbers in a double link form:
• Page referenced:
move it to the top
requires 6 pointers to be changed
• But each update more expensive
• No search for replacement
Operating System Concepts – 10th Edition 10.39 Silberschatz, Galvin and Gagne
LRU Algorithm (Cont.)
LRU and OPT are cases of stack algorithms that don’t have
Belady’s Anomaly
Use Of A Stack to Record Most Recent Page References
Operating System Concepts – 10th Edition 10.40 Silberschatz, Galvin and Gagne
LRU Approximation Algorithms
LRU needs special hardware and still slow
Reference bit
• With each page associate a bit, initially = 0
• When page is referenced bit set to 1
• Replace any with reference bit = 0 (if one exists)
We do not know the order, however
Operating System Concepts – 10th Edition 10.41 Silberschatz, Galvin and Gagne
LRU Approximation Algorithms (cont.)
Second-chance algorithm
• Generally FIFO, plus hardware-provided reference bit
• Clock replacement
• If page to be replaced has
Reference bit = 0 -> replace it
reference bit = 1 then:
– set reference bit 0, leave page in memory
– replace next page, subject to same rules
Operating System Concepts – 10th Edition 10.42 Silberschatz, Galvin and Gagne
Second-chance Algorithm
Operating System Concepts – 10th Edition 10.43 Silberschatz, Galvin and Gagne
Enhanced Second-Chance Algorithm
Operating System Concepts – 10th Edition 10.44 Silberschatz, Galvin and Gagne
Counting Algorithms
Keep a counter of the number of references that have
been made to each page
• Not common
Lease Frequently Used (LFU) Algorithm:
• Replaces page with smallest count
Most Frequently Used (MFU) Algorithm:
• Based on the argument that the page with the
smallest count was probably just brought in and
has yet to be used
Operating System Concepts – 10th Edition 10.45 Silberschatz, Galvin and Gagne
Page-Buffering Algorithms
Keep a pool of free frames, always
• Then frame available when needed, not found at fault
time
• Read page into free frame and select victim to evict
and add to free pool
• When convenient, evict victim
Possibly, keep list of modified pages
• When backing store otherwise idle, write pages there
and set to non-dirty
Possibly, keep free frame contents intact and note what
is in them
• If referenced again before reused, no need to load
contents again from disk
• Generally useful to reduce penalty if wrong victim
frame selected
Operating System Concepts – 10th Edition 10.46 Silberschatz, Galvin and Gagne
Applications and Page Replacement
All of these algorithms have OS guessing about future
page access
Some applications have better knowledge – i.e.
databases
Memory intensive applications can cause double
buffering
• OS keeps copy of page in memory as I/O buffer
• Application keeps page in memory for its own work
Operating system can given direct access to the disk,
getting out of the way of the applications
• Raw disk mode
Bypasses buffering, locking, etc.
Operating System Concepts – 10th Edition 10.47 Silberschatz, Galvin and Gagne
Allocation of Frames
Each process needs minimum number of frames
Example: IBM 370 – 6 pages to handle SS MOVE
instruction:
• instruction is 6 bytes, might span 2 pages
• 2 pages to handle from
• 2 pages to handle to
Maximum of course is total frames in the system
Two major allocation schemes
• fixed allocation
• priority allocation
Many variations
Operating System Concepts – 10th Edition 10.48 Silberschatz, Galvin and Gagne
Fixed Allocation
Equal allocation – For example, if there are 100 frames
(after allocating frames for the OS) and 5 processes,
give each process 20 frames
• Keep some as free frame buffer pool
Operating System Concepts – 10th Edition 10.49 Silberschatz, Galvin and Gagne
Global vs. Local Allocation
Global replacement – process selects a replacement frame
from the set of all frames; one process can take a frame
from another
• But then process execution time can vary greatly
• But greater throughput so more common
Local replacement – each process selects from only its
own set of allocated frames
• More consistent per-process performance
• But possibly underutilized memory
Operating System Concepts – 10th Edition 10.50 Silberschatz, Galvin and Gagne
Reclaiming Pages
A strategy to implement global page-replacement policy
All memory requests are satisfied from the free-frame
list, rather than waiting for the list to drop to zero
before we begin selecting pages for replacement,
Page replacement is triggered when the list falls below
a certain threshold.
This strategy attempts to ensure there is always
sufficient free memory to satisfy new requests.
Operating System Concepts – 10th Edition 10.51 Silberschatz, Galvin and Gagne
Reclaiming Pages Example
Operating System Concepts – 10th Edition 10.52 Silberschatz, Galvin and Gagne
Non-Uniform Memory Access
So far, we assumed that all memory accessed equally
Many systems are NUMA – speed of access to memory
varies
• Consider system boards containing CPUs and
memory, interconnected over a system bus
NUMA multiprocessing architecture
Operating System Concepts – 10th Edition 10.53 Silberschatz, Galvin and Gagne
Non-Uniform Memory Access (Cont.)
Optimal performance comes from allocating memory
“close to” the CPU on which the thread is scheduled
• And modifying the scheduler to schedule the thread
on the same system board when possible
• Solved by Solaris by creating lgroups
Structure to track CPU / Memory low latency
groups
Used my schedule and pager
When possible schedule all threads of a process
and allocate all memory for that process within
the lgroup
Operating System Concepts – 10th Edition 10.54 Silberschatz, Galvin and Gagne
Thrashing
Operating System Concepts – 10th Edition 10.55 Silberschatz, Galvin and Gagne
Thrashing (Cont.)
Thrashing. A process is busy swapping pages in and
out
Operating System Concepts – 10th Edition 10.56 Silberschatz, Galvin and Gagne
Demand Paging and Thrashing
Operating System Concepts – 10th Edition 10.57 Silberschatz, Galvin and Gagne
End of Chapter 10
Operating System Concepts – 10th Edition 10.59 Silberschatz, Galvin and Gagne
Need For Page Replacement
Operating System Concepts – 10th Edition 10.60 Silberschatz, Galvin and Gagne