Lecture 23
Lecture 23
Demand Paging
Optional reading:
Operating Systems: Principles and Practice (2nd Edition): Chapter 9
This document is copyright (C) Stanford Computer Science and Nick Troccoli, licensed under
Creative Commons Attribution 2.5 License. All rights reserved.
Based on slides and notes created by John Ousterhout, Jerry Cain, Chris Gregg, and others.
NOTICE RE UPLOADING TO WEBSITES: This content is protected and may not be shared, 1
uploaded, or distributed. (without expressed written permission)
Key Question: what
happens when we run out
of physical pages?
2
CS111 Topic 4: Virtual Memory
Virtual Memory - How can one set of memory be shared among several processes?
How can the operating system manage access to a limited amount of system
memory?
Virtual Dynamic
Demand The Clock
Memory Address
Paging Algorithm
Introduction Translation
Lecture 21 Lecture 22 Today Lecture 24
4
Plan For Today
• Recap: Base and bound, multiple segments, and paging
• Page Map Size
• Demand Paging
5
Plan For Today
• Recap: Base and bound, multiple segments, and paging
• Page Map Size
• Demand Paging
6
Dynamic Address Translation
Key question: how do the MMU / OS translate from virtual addresses to physical
ones? Three designs we’ll consider:
1. Base and bound
2. Multiple Segments
3. Paging
7
Approach #2: Multiple Segments
Key Idea: Each process is split among several variable-size areas of memory,
called segments.
• E.g. one segment for code, one segment for data/heap, one segment for stack.
• Start of each segment is pinned to a specific virtual address
• OS maps each segment individually – each segment has its own base and
bound, kept in a segment map for that process (segment map stored in MMU)
• Also store a protection bit for each segment: whether the process is allowed to
write to it or not in addition to reading
• Now each segment can have its own permissions, grow/shrink independently,
be swapped to disk independently, be moved independently, and even be
shared between processes (e.g. shared code).
• Top bit(s) of virtual address encode segment number, rest encode offset 8
Multiple Segments
∞ Stack
∞
Data
Code
0
Process A Virtual Address Space
∞ Stack
0
Data
Code
0
Process B Virtual Address Space Physical Address Space
9
Multiple Segments – Changing A Bound
stack
bound
• Buffer space between stack + ∞
Stack heap doesn’t need to be initially
mapped.
• Growing a segment upwards
works well for the heap, but not
data
for the stack, for the same reason
bound as base and bound: we can’t
Data move existing stack data after the
program starts.
Code • Still fragmentation problem, plus
need to decide # bits for segment
Process A data base
0 0
number vs. offset.
Process A Virtual
Address Space Physical Address Space
10
Paging
Key Idea: Divide virtual and physical memory into fixed-size chunks called pages.
(Common size is 4KB pages).
• A “page” of virtual memory maps to a “page” of physical memory. No partial
pages. No more external fragmentation! (but some internal fragmentation if
not all of a page is used).
• The page number is a numerical ID for a page. We have virtual page numbers
and physical page numbers.
• Each process has a page map (“page table”) with an entry for each virtual
page, mapping it to a physical page number and other info such as a protection
bit (read-only or read-write).
• First bits of an address encode offset, rest encode (virtual or physical) page
number
11
Paging
∞ • Do not need to map each ∞
Stack segment contiguously. Instead,
we map just one page at a time.
• We can later map more pages
either up or down, because the
start of the segment is not
pinned to a physical address.
Data • We can move each page
separately in physical memory by
Code modifying the page map.
0 0
Process A Virtual
Address Space Physical Address Space
12
Paging
∞ Stack ∞
Data
Code
0 0
Process A Virtual
Address Space Physical Address Space
13
Paging
∞ ∞
Stack
Data
Code
0 0
Process A Virtual
Address Space Physical Address Space
14
Page Map
Index Physical page # Writeable?
… … …
3 0x2342 1
2 0x12625 1
1 0x13241 0
0 0x256 0
Key Idea: to enable quick lookup, the page table is an array where the indexes
are the virtual page numbers. E.g. index 5 corresponds to virtual page 5.
• (Why not e.g. a hashmap? Not feasible at the time with hardware, plus turns
out array ends up working pretty well with optimizations)
This means we must have an entry for every virtual page, even invalid ones –
because missing entries would mean indexes wouldn’t line up anymore. 20
Plan For Today
• Recap: Base and bound, multiple segments, and paging
• Page Map Size
• Demand Paging
21
Paging
Page map has entries for all pages, including invalid ones. We will add an
additional field marking whether it’s valid (“present”).
22
Page Map
Index Physical page # Writeable? Present?
… … … …
3 0x2342 1 1
2 XXX X 0
1 0x13241 0 1
0 XXX X 0
23
Page Map
Index Physical page # Writeable? Present?
… … … …
3 0x2342 1 1
2 XXX X 0
1 0x13241 0 1
0 XXX X 0
25
Page Map Size
Problem: how big is a single process’s page map? An entry for every page?
Example with x86-64: 36-bit virtual page numbers, 8-byte map entries
236 virtual pages x 8 bytes per page entry = 512GB!! (239 bytes)
Plus, most processes are small, so most pages will be “not present”. And even
large processes use their address space sparsely (e.g. code at bottom, stack at
top).
26
Page Map Size
x86-64 solution: represent the page map as a multi-level tree.
• Top level of page map has entries for ranges of virtual pages (0 to 227-1, 227 to
2 * 227 – 1, etc.). Only if any pages in that range are present does that entry
point to a lower level in the tree (saves space).
• Lower levels follow a similar structure – entry for ranges of pages, and they
only map to something if at least one of the pages in that range is present.
• The lowest level of the tree contains actual physical page numbers.
27
Page Map Tree Structure
Tree, level 4:
28
Page Map Tree Structure
Tree, level 4:
29
Page Map Tree Structure
Tree, level 3:
30
Page Map Tree Structure
Tree, level 3:
31
Page Map Tree Structure
Tree, level 2:
32
Page Map Tree Structure
Tree, level 2:
33
Page Map Tree Structure
Tree, level 1:
34
Page Map Tree Structure
Tree, level 1:
35
Page Map Tree Structure
64-bit Virtual Address
16 9 9 9 9 12
37
Plan For Today
• Recap: Base and bound, multiple segments, and paging
• Page Map Size
• Demand Paging
38
What should we do in our
paging design if we run out of
physical memory?
39
Running Out Of Memory
If memory is in high demand, we could fill up all of memory, since a process
needs all its pages in memory to run. What should we do in that case?
• Prohibit further program memory requests until some is freed? Not ideal.
• Another idea – what if we kicked out a page and used that page? We could
save a page to disk, use the page for new data, and load the old data back in to
a physical page later if it’s still needed.
40
Demand Paging
Overall goal: allow programs to run without all their information in memory.
• Keep in memory the information that is being used.
• Keep unused information on disk in paging file (also called backing store, or
swap space)
• Move information back and forth as needed.
• Locality – most programs spend most of their time using a small fraction of
their code and data
Ideally: we have a memory system with the performance of main memory and
the cost/capacity of disk!
41
Demand Paging – 2 Key Questions
1. What is the process for kicking a page out to disk?
2. How do we choose which page to kick out? (next time!)
42
Demand Paging – 2 Key Questions
1. What is the process for kicking a page out to disk?
2. How do we choose which page to kick out? (next time!)
43
Demand Paging
∞ Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 X X 0
Address Space
5 X X 0
4 X X 0
3 X X 0
2 X X 0
1 2 0 1
0 1 0 1 44
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 X X 0
Address Space
5 X X 0
4 X X 0
3 X X 0
1. Pick an existing 2 X X 0
physical page and swap 1 2 0 1
it to disk. 0 1 0 1 46
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 X X 0
Address Space
5 X X 0 Disk Swap
4 X X 0 Space
1. Pick an existing
3 X X 0
physical page and swap Process A, vpage #0
2 X X 0
it to disk, mark not 1 2 0 1
present. 0 1 0 0 47
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 1 1 1
Address Space
5 X X 0 Disk Swap
4 X X 0 Space
3 X X 0
Process A, vpage #0
2. Map this physical 2 X X 0
page to the new virtual 1 2 0 1
page. 0 1 0 0 48
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 1 1 1
Address Space
5 X X 0 Disk Swap
4 X X 0 Space
1. We look in the page 3 X X 0
Process A, vpage #0
map and see it’s not 2 X X 0
1 2 0 1
present.
0 1 0 0 49
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 1
Process A Virtual
6 1 1 1
Address Space
5 X X 0 Disk Swap
2. But it is stored in disk 4 X X 0 Space
swap, so we load it back 3 X X 0
Process A, vpage #0
in (kicking another page if 2 X X 0
needed). 1 2 0 1
0 1 0 0 50
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 0
Process A Virtual
6 1 1 1
Address Space
5 X X 0 Disk Swap
2. But it is stored in disk 4 X X 0 Space
swap, so we load it back 3 X X 0 Process A, vpage #7
in (kicking another page if 2 X X 0 Process A, vpage #0
needed). 1 2 0 1
0 1 0 0 51
Demand Paging
∞
Stack
∞
0
Data Physical Address Space
0
Code Physical page # WR? PR?
7 0 1 0
Process A Virtual
6 1 1 1
Address Space
5 X X 0 Disk Swap
2. But it is stored in disk 4 X X 0 Space
swap, so we load it back 3 X X 0 Process A, vpage #7
in (kicking another page if 2 X X 0
needed). 1 2 0 1
0 0 0 1 52
Demand Paging
If we need another page but memory is full:
1. Pick a page to kick out
2. Write it to disk
3. Mark the old page map entry as not present
4. Update the new page map entry to be present and map to this physical page
53
Demand Paging
If the program accesses a page that was swapped to disk:
1. Triggers a page fault (not-present page accessed)
2. We see disk swap contains data for this page
3. Get a new physical page (perhaps kicking out another one)
4. Load the data from disk into that page
5. Update the page map with this new mapping
We now rely on the present bit to tell us more generally if the page is present in
physical memory or not – if not, could still be a valid access if in disk swap.
54
Thrashing
Demand paging can provide big benefits – but can also run into problematic
scenarios. In the following scenario, what is a bad scenario for demand paging
for what pages this process accesses next?
Stack
Data 0
0
Code Physical Address Space
Process A Virtual
Disk Swap Space
Address Space Process A, vpage #1
Process A, vpage #0
If the pages being actively used don’t all fit in memory, the system will spend all
its time reading and writing pages to/from disk and won’t get much work done.
• Called thrashing
• The page we kick to disk will be needed very soon, so we will bring it back and
kick another page, which will be needed very soon, etc….
• Progress of the program will make it look like access time of memory is as slow
as disk, rather than disk being as fast as memory.
• With personal computers, users can notice thrashing and kill some processes
57
Demand Paging Behaviors
Two additional details about demand paging:
• We don’t always need to write a swapped-out page to disk (e.g., read-only
code pages can always be loaded from executable)
• A page may have initial data even if it’s never been accessed before (e.g.,
initialized global variables at program start.)
58
Kinds of Pages
The pages for a process divide into three groups:
1. Read-only code pages: program code, doesn’t change
A. no need to store in swap when kicked out; can always read them from executable file
B. on first access, the program expects them to contain data
2. Initialized data pages: program data with initial values (e.g., globals)
A. save to swap since contents may have changed from initial values
B. on first access, the program expects them to contain data
3. Uninitialized data pages: e.g., stack, heap
A. save to swap as needed
B. no set initial contents – on first access, just clear memory to all zeros
59
Assign6 Disk Swap
On assign6:
• You’ll only write to disk if a page is “dirty” (modified). Page maps contain a
dirty bit that is set whenever a page is modified.
• A page may have contents on disk from the executable or from a previous
swap – you’ll read into memory in both cases.
60
Page Fetching
Now we have a mechanism to allow programs to run without all their
information in memory. But even if there is space, when should we bring pages
into memory?
• Most modern OSes start with no pages loaded, load pages when referenced
(“demand fetching”).
• Alternative: prefetching - try to predict when pages will be needed and load
them ahead of time (requires predicting the future…)
61
Page Replacement
If we need another physical page but all memory is used, which page should we
throw out?
62
Recap
• Recap: Base and bound, multiple Lecture 23 takeaway: We
segments, and paging
can make memory appear
• Page Map Size
larger than it is by swapping
• Demand Paging pages to disk when we need
more space and swapping
them back later. But
thrashing can occur when the
system spends all its time
Next time: how to choose which doing disk operations and
pages to swap to disk (the clock little time on actual work.
algorithm).
63