Operating Systems:

Internals and Design Principles, 6/E

William Stallings

Chapter 8
Virtual Memory – Part II
[H/W Role + OS Role]

Dave Bremer
Otago Polytechnic, N.Z.
©2008, Prentice Hall

*Lecture slides are modified by Dr. Ahmed Salah (FCIS- ASU)*

 GENERAL NOTE
Hidden Slides are Extra Knowledge
Not Included in Exams
 Roadmap
KNOW HOW the Operating System do its Main Jobs?

Solve competition on…

Shared
Memory CPU Resourc
e

Physical Virtual Single Critical

Multi CPU Deadlocks
Mem Mem CPU Sections
(CH.10) (CH.6)
(CH.7) (CH.8) (CH.9) (CH.5)
 From Last Time…

[1] Physical vs. Virtual Memory

[2] Principle of Locality

[3] Thrashing
Address

Time
 From Last Time…
VM view Page Tables RAM view
1111 1111 (level 2)
stack 1) Table Size > Frame Size
Virtual Paging: 11 11101
stack
1111 0000
Single table
2) Partial should fit
required 10 11100
01 10111
1100 0000 Page Table 00 10110
(level 1)
111 in 1 frame 11 null
10 10000
stack
110 null
101 null 01 01111


00 01110
heap 100
011 null
1000 0000
010 heap
• P (present bit): in RAM or Not 001 null
000 11 01101

• M (modified bit): Altered or

data
Min Beside
# Levels subject 10 01100
data
01 01011
Not 0100 0000 This one 00 01010
Problem#1:
to Max # entries per 11 00101
Sparse VM + Large Page Table! page2 # 10 00100
code
code
table (to fit in 1 frame)
01 00011
Solution: 0000 0000 00 00010

page1 # offset Only load

Multilevel Paging these tables
 From Last Time…
Ex: 2-level Address Translation

MMU Role?

OS Role?
 Agenda
• H/W Roles [cont.]
1. Paging PART I
1. Multilevel Paging (Ex)
2. Cache
• OS Roles
– Main Goal
– Fetch Policy PART II
– Placement Policy
– Replacement Policy
• Intel MMU
• Questions (Credits to Dr. Ahmed Salah)
 Learning Outcomes

• Summarize the principles of virtual memory as applied to caching

and paging.
• Describe the various OS mechanisms used to implement virtual
memory.
 References
• Chapter 8
– Section 8.1 (H/W Roles)
– Section 8.2 (OS Roles)

• Stanford CS140
– Lec.5 Virtual Memory (H/W)

• Berkeley CS162
– Lec.13 Address Translation + Caching
 Virtual Paging
• 3 Problems:
1. Sparse VM + Large Page Table!
2. Page table grows in RAM!
• Proportional to virtual memory/process
3. # references to RAM per program reference!!
• 1 Issue:
– Page Size
 Virtual Paging
• 3 Problems:
1. Sparse VM + Large Page Table!
2. Page table grows in RAM!
• Proportional to virtual memory/process
3. # references to RAM per program reference!!
• 1 Issue:
– Page Size
 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Idea:
– In simple paging: each virtual memory reference can cause two
physical memory accesses
• One to fetch the page table
• One to fetch the data

– In 2-level paging, HOW many ref’s to RAM per prog. ref?

What about x86-64, 4-level paging?

512 Entries
Per Table
 IA64: 64bit addresses: Six-level page table!?

64bit Virtual 7 bits 9 bits 9 bits 9 bits 9 bits 9 bits 12 bits

Virtual Virtual Virtual Virtual Virtual Virtual
Address: P1 index P2 index P3 index P4 index P5 index P6 index Offset

No!

Too slow
Too many almost-empty tables

Use inverted page table instead

(Not studies in this course)

10/12/15 Kubiatowicz CS162 ©UCB Fall 2015 Lec 13.14

 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Solution:
– Use a high-speed cache for page table entries
• Called a Translation Lookaside Buffer (TLB)
• Contains page table entries that have been most recently used

– Why it Help? [Locality]

 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Steps:
1. Given a virtual address,
• CPU examines the TLB

2. If page table entry is present (TLB hit),

• the frame# is retrieved & the real address is formed

3. Else, If not found in TLB (TLB miss),

• the page# is used to index the process page table
 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Steps:
4. First checks if page is already in main memory
• If not in main memory a page fault is issued

5. TLB is updated to include the new page entry

 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• TLB

HOW
is this done?
 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Accessing TLB:
– As the TLB only contains some of the page table entries we
cannot simply index into the TLB based on the page number
• Each TLB entry must include the page number as well as the
complete page table entry
– The process is able to simultaneously query numerous TLB
entries to determine if there is a page number match
 Virtual Paging
Pr3: # ref’s to RAM per program ref!!
• Accessing TLB:
Direct Mapping Associative Map.
 Virtual Paging
Cache the Address

TLB &
Cache
Cache the Code/Data
Memory
 Pr3: # ref’s to RAM per program
ref!!
What happens to TLB on a Context Switch?
• Need to do something, since TLBs map virtual addresses
to physical addresses
– Address Space just changed, so TLB entries no longer valid!
• Options?
– Invalidate TLB: simple but might be expensive
» What if switching frequently between processes?
– Include ProcessID in TLB
» This is an architectural solution: needs hardware
What if TLB change?
– e.g., to move page from memory to disk or vice versa…
– Must invalidate TLB entry!
» Otherwise, might think that page is still in memory!
– Called “TLB Consistency”
10/19/15 Kubiatowicz CS162 ©UCB Fall 2015 Lec 14.22
 Virtual Paging
Page Table
Pr3: # ref’s to RAM per program ref!! P# Fr# P M
0 100 1 0
• Example: Given: 1 200 1 1
2 300 1 0
• Virtual size / process = 2 KB
3 400 1 0
• Page size = 64 bytes
4 500 1 1
• “Process A” reference addresses: 5 - 0 0
5, 64, 128, 512, 20, 30, 520,256, 30, 520, 100 6 600 1 1
• TLB size = 3 entries 7 - 0 0

• Questions: 8 700 1 0

• What’s the number of TLB hits & misses?

• What’s the final content of the TLB?
 Virtual Paging
Page Table
Pr3: # ref’s to RAM per program ref!! P# Fr# P M
0 100 1 0
• Example: 1 200 1 1
2 300 1 0
• Answers:
3 400 1 0
• What’s the number of TLB hits & misses? 4 500 1 1
• What’s the final content of the TLB? 5 - 0 0
Ref: 5, 64, 128, 512, 20, 30, 520, 256, 30, 520, 100 6 600 1 1
P#: 0, 1, 2, 8, 0, 0, 8, 4, 0, 8, 1 7 - 0 0
Miss Miss Miss Miss Miss Hit Hit Miss Hit Hit Miss 8 700 1 0
P# P.T.Entry P# P.T.Entry P# P.T.Entry P# P.T.Entry P# P.T.Entry
0 100 1 0 8 700 1 0 8 700 1 0 8 700 1 0 8 700 1 0
TLB 1 200 1 1 1 200 1 1 0 100 1 0 0 100 1 0 0 100 1 0
2 300 1 0 2 300 1 0 2 300 1 0 4 500 1 1 1 200 1 1
Overall
Flowchart
 Agenda
• H/W Roles [cont.]
1. Paging PART I
1. Multilevel Paging (Ex)
2. Cache
• OS Roles
– Main Goal
– Fetch Policy PART II
– Placement Policy
– Replacement Policy
• Intel MMU
• Questions (Credits to Dr. Ahmed Salah)
 OS Main Goal
• Minimize page faults

• No definitive best policy

 Fetch Policy
• Determines when a page should be brought into memory
• Two main types:
1. Demand Paging
2. Prepaging
 Fetch Policy
• Demand paging
– Only brings pages into main memory when a reference is made
to a location on the page
– Many page faults when process first started
• Prepaging
– Brings in more pages than needed, either at:
1. Process Start
2. Page Fault
– More efficient to bring in pages that reside contiguously on the disk
 Agenda
• H/W Roles [cont.]
1. Paging PART I
1. Multilevel Paging (Ex)
2. Cache
• OS Roles
– Main Goal
– Fetch Policy PART II
– Placement Policy
– Replacement Policy
• Intel MMU
• Questions (Credits to Dr. Ahmed Salah)
 Replacement Policy
• Determines which page currently in memory is to be replaced
• Answer 3 questions:
1. When to replace?
1. RAM is Full
2. Process reaches its Max
2. Which page to be replaced?
• Page least likely to be referenced
• Predict future from the past (Based on: Principle of Locality)
• 5 different algorithms
3. From whom?
1. Local from process
2. Global from any other process
 Replacement Policy
• Frame Locking
– Associate a lock bit with each frame… Where?
– Locked frame not replaced
– Examples:
• Kernel of the operating system
• Key control structures
• I/O buffers
 Replacement Policy
• Basic Algorithms:
1. Optimal
2. Least recently used (LRU)
3. First-in-first-out (FIFO)
4. Clock
5. Modified Clock