7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 1/81
Operating SystemMemory Management
WANG Xiaolin
November 7, 2010
1 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 2/81
Outline
Background
Swapping
Contiguous Memory Allocation
Virtual MemoryPagingSegmentationDemand PagingCopy-on-Write
Page Replacement AlgorithmsAllocation of Frames Thrashing And Working Set ModelOther Issues
2 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 3/81
Memory Management
In a perfect world ...
Memory is large, fast, non-volatile
In real world ...
Registers
Cache
Main memory
Magnetic tape
Magnetic disk
1 nsec
2 nsec
10 nsec
10 msec
100 sec
<1 KB
1 MB
64-512 MB
5-50 GB
20-100 GB
Typical capacityTypical access time
Memory manager handles the memory hierarchy
3 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 4/81
Basic Memory ManagementReal Mode
In the old days ...
Every program simply saw the physical memory
mono-programming without swapping or paging
(a) (b) (c)
0xFFF …
0 0 0
Userprogram
User
program
Userprogram
Operatingsystem in
RAM
Operatingsystem in
RAM
Operating
system inROM
Device
drivers in ROM
.old mainstream .handhold, embedded .MS-DOS4 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 5/81
Basic Memory ManagementRelocation Problem
.Exposing physical memory toprocesses is not a good idea
5 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 6/81
Memory ProtectionProtected mode
We need
Protect the OS from access by user programs
Protect user programs from one another
Protected mode is an operational mode of x86-compatible CPU.
The purpose is to protect everyone else(including the OS) from your program.
6 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 7/81
Memory ProtectionLogical Address Space
Base register holds the smallest legal physical memory
addressLimit register contains the size of the range
A pair of base and limitregisters define the logicaladdress space
JMP 28«
JMP 300068
7 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 8/81
Memory ProtectionBase and limit registers
8 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 9/81
UNIX View of a Process’ Memory
max +------------------+| Stack | Stack segment
+--------+---------+
| | |
| v |
| |
| ^ |
| | |+--------+---------+
| Dynamic storage | Heap
|(from new, malloc)|
+------------------+
| Static variables |
| (uninitialized, | BSS segment
| initialized) | Data segment+------------------+
| Code | Text segment
0 +------------------+
Process’ memory isdivided into logicalsegments
text: program code
data: initialized global andstatic data
bss: uninitialized global andstatic data
heap: dynamically allocatedwith malloc|new|free
stack: local variables..the size (text+data+bss) of
a process is established at
compile time9 / 8 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 10/81
Stack vs. Heap
Stack Heap
compile-time allocation run-time allocation
auto clean-up you clean-up
inflexible flexible
smaller bigger
quicker slower
How large is the ...stack: ~$ ulimit -s
heap: could be as large as your virtual memory
text|data|bss: ~$ size a.out
10/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 11/81
Multi-step Processing of a User ProgramWhen is space allocated?
Static: before program start
running Compile time Load time
Dynamic: as program runs
Execution time
11/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 12/81
Address BindingWho assigns memory to segments?
Static-binding: before program start running
Compile time: Compiler and assembler generate anobject file for each source file
Load time: Linker combines all the object files into a single
executable object file Loader (part of OS) loads an executable object file
into memory at location(s) determined by the OS
Dynamic-binding: as program runs
Execution time: uses new and malloc to dynamically allocate
memory gets space on stack during function calls
12/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 13/81
Static loading
The entire program and all dataof a process must be in physicalmemory for the process to
execute The size of a process is thus
limited to the size of physicalmemory
13/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 14/81
Dynamic Loading
Better memory utilization
Only the main program is loaded into memory andis executed
Routine is not loaded until it is called
Unused routine is never loaded
Useful when large amounts of code are needed tohandle infrequently occurring cases
dynamic_loading(&routine){i f ( i s _ c a l l e d && ! loaded ) {
load_routine_into_memory ( ) ;}pas s _ct rl(& rou t in e ) ;
}
14/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 15/81
Dynamic Linking
Similar to dynamic loading
A dynamic linker is actually a special loader that
loads external shared libraries into a runningprocess
Small piece of code, stub, used to locate theappropriate memory-resident library routine
Only one copy in memory Don’t have to re-link after a library update
i f ( stub_is_executed ){i f ( ! routine_in_memory )
load_into_memory(&r ou ti ne ) ;
s t u b_replace s _it s elf (& rou tin e ) ;execute(&ro utine ) ;
}
15/81
i l h i l dd
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 16/81
Logical vs. Physical Address Space
Mapping logical address space to physical addressspace is central to MM
Logical address generated by the CPU; alsoreferred to as virtual address
Physical address address seen by the memory unit In compile-time and load-time address binding
schemes, LAS and PAS are identical in size
In execution-time address binding scheme, they are
differ.
16/81
L i l Ph i l Add S
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 17/81
Logical vs. Physical Address SpaceMemory-Management Unit (MMU)
The user program deals with logical addresses; it never sees
the real physical addresses
17/81
MMU
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 18/81
MMU
CPUpackage
CPU
The CPU sends virtual
addresses to the MMU
The MMU sends physicaladdresses to the memory
Memory
managementunit
MemoryDisk
controller
Bus
18/81
S i
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 19/81
Swapping
Major part of swap time is transfer time
Total transfer time is directly proportional to theamount of memory swapped
19/81
Memor Protection
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 20/81
Memory Protection
Where are the base and limit registers from?
20/81
Contiguous Memory Allocation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 21/81
Contiguous Memory AllocationMultiple-partition allocation
(a)
Operatingsystem
;
; ;
;
A
(b)
Operatingsystem
;
; ;
;
A
B
(c)
Operatingsystem
;
A
B
C
(d)
Time
Operatingsystem
;
; ;
;
;
; ;
;
B
C
(e)
D
Operatingsystem
;
; ;
;
B
C
(f)
D
Operatingsystem
;
; ;
;
; ;
;
C
(g)
D
Operatingsystem
;
A
C
Operating system maintains information about:a) allocated partitions b) free partitions (hole)
21/81
Dynamic Storage Allocation Problem
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 22/81
Dynamic Storage-Allocation ProblemFirst Fit, Best Fit, Worst Fit
22/81
Dynamic Storage Allocation Problem
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 23/81
Dynamic Storage-Allocation Problem
First-fit: The first hole that is big enough
Best-fit: The smallest hole that is big enough
Must search entire list, unless orderedby size
Produces the smallest leftover hole
Worst-fit: The largest hole Must also search entire list Produces the largest leftover hole
First-fit and best-fit better than worst-fit in terms of speed and storage utilization
First-fit is generally faster
23/81
Fragmentation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 24/81
Fragmentation
000000000000000000000000111111111111111111111111000000000000000000000000111111111111111111111111000000001111111100000000
00000000
00000000
00000000
00000000
11111111
11111111
11111111
11111111
11111111
00000000
00000000
00000000
11111111
11111111
11111111
Process F
Process L
Process C
fragmentationInternal
fragmentation
External
Reduce external fragmentation by
Compaction is possible only if
relocation is dynamic, and is doneat execution time
Noncontiguous memory allocation Paging Segmentation
24/81
Virtual Memory
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 25/81
Virtual MemoryLogical memory can be much larger than physical memory
rtuaaddress
space
Physicalmemoryaddress
60K-64K
56K-60K
52K-56K
48K-52K
44K-48K
40K-44K
36K-40K
32K-36K
28K-32K
24K-28K
20K-24K
16K-20K
12K-16K
8K-12K
4K-8K
0K-4K
28K-32K
24K-28K
20K-24K
16K-20K
12K-16K
8K-12K
4K-8K
0K-4K
Virtual page
Page frame
X
X
X
X
7
X
5
X
X
X
3
4
0
6
1
2
virtual
address
page table−−−−−−→
physical
address
Page 0map to−−−−→ Frame 2
MOV REG, 0
«MOV REG, 8192
0: beginning address of page 0
8192: beginning address of frame 2
20500v = 20K v + 20«
12308 phy = 12K + 20.
.MMU
25/81
Page Fault
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 26/81
Page Faultrtua
addressspace
Physicalmemoryaddress
60K-64K56K-60K
52K-56K
48K-52K
44K-48K
40K-44K
36K-40K
32K-36K
28K-32K
24K-28K
20K-24K
16K-20K12K-16K
8K-12K
4K-8K
0K-4K
28K-32K
24K-28K
20K-24K
16K-20K12K-16K
8K-12K
4K-8K
0K-4K
Virtual page
Page frame
XX
X
X
7
X
5
X
X
X
3
40
6
1
2
What if MOV REG, 32780 ?
26/81
Paging
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 27/81
PagingAddress Translation Scheme
Address generated by CPU is divided into:
Page number(p): an index into a page tablePage offset(d): to be copied into memory
Given logical address space 2m and page size 2n,
number of pages =
2m
2n = 2m−n
Example: addressing to 0010000000000100
m−n=4 0 0 1 0
n=12 0 0 0 0 0 0 0 0 0 1 0 0
m=16
page number = 0010 = 2, page offset = 000000000100
27/81
Outgoingh i l
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 28/81
15
14
1312
11
10
9
8
7
6
5
4
3
2
1
0
000
000
000000
111
000
101
000
000
000
011
100
000
110
001
010
0
0
00
1
0
1
0
0
0
1
1
1
1
1
1Present/
absent bit
Pagetable
12-bit offsetcopied directlyfrom inputto output
Virtual page = 2 is usedas an index into thepage table Incoming
virtualaddress(8196)
physicaladdress(24580)
110
1 1 0 0 0 0 0 0 0 0 0 0 1 0 0
00 1 0 0 0 0 0 0 0 0 0 0 1 0 0
Paging Example The internal operation
of the MMU with 164-KB pages
Physical memory: 32K Virtual memory: 64K
28/81
Shared Pages
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 29/81
Shared Pages
29/81
Page Table Entry
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 30/81
Page Table EntryIntel i386 Page Table Entry
Commonly 4 bytes (32 bits) long Page size is usually 4k (212 bytes). OS dependent
~$ getconf PAGESIZE Could have 232−12 = 220 = 1M pages
Could addressing 1M× 4KB = 4GB memory
31 12 11 0
+--------------------------------------+-------+---+-+-+---+-+-+-+
| | | | | | |U|R| |
| PAGE FRAME ADDRESS 31..12 | AVAIL |0 0|D|A|0 0|/|/|P|
| | | | | | |S|W| |
+--------------------------------------+-------+---+-+-+---+-+-+-+
P - PRESENT
R/W - READ/WRITE
U/S - USER/SUPERVISOR
A - ACCESSED
D - DIRTY
AVAIL - AVAILABLE FOR SYSTEMS PROGRAMMER USE
NOTE: 0 INDICATES INTEL RESERVED. DO NOT DEFINE.30/81
Page Table
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 31/81
Page Table
Page table is kept in main memory Usually one page table for each process
Page-table base register (PTBR): A pointer to thepage table is stored in PCB
Page-table length register (PRLR): indicates size of the page table
Slow Requires two memory accesses. One for the page
table and one for the data/instruction.
TLB
31/81
Translation Lookaside Buffer (TLB)
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 32/81
( )Fact: 80-20 rule
Only a small fraction of the PTEs are heavily read;
the rest are barely used at all
32/81
Multilevel Page Tables
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 33/81
g
a 1M-entry page table eats4M memory
while 100 processesrunning, 400M memory isgone for page tables
avoid keeping all the page
tables in memory all thetime
a two-level scheme
page number | page offset
+----------+----------+------------+
| p1 | p2 | d |
+----------+----------+------------+
10 10 12
33/81
Two-Level Page Tables
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 34/81
gExample
Don’t have to keep all the 1K page tables
(1M pages) in memory. In this example
only 4 page tables are actuallymapped into memory
process
+-------+
| stack | 4M+-------+
| |
| ... | unused
| |
+-------+
| data | 4M
+-------+
| code | 4M
+-------+
Top−levelpage table
Second−levelpage tables
Topages
Pagetable forthe top4M ofmemory
6543210
1023
1023
654321
0
1023
Bits 10 10 12
PT1 PT2 Offset
4M−1
8M−1
Page table
Page table
Page table
Page table
Page table
Page table
Page table
Page table
Page table
00000000010000000011000000000100PT1 = 1 PT2 = 3 Offset = 4
01
23
4K ~ 8K−1
8K ~ 12K−1
12K ~ 16K−1
16K ~ 20K−1
0 ~ 4K−1
34/81
Problem With 64-bit Systems
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 35/81
y
Given:
virtual address space = 64 bits
page size = 4 KB = 212 B
How much space would a simple single-level page tabletake?
Each page table entry takes 4 Bytes, then
The whole page table (264−12 entries) will take
264−12 × 4 B = 254 B = 16 PB ( peta ⇒ tera ⇒ giga)!
And this is for ONE process!
Multi-level?
If 10 bits for each level, then [52/10] = 5 levels arerequired. 5 memory accress for each addresstranslation!
35/81
Inverted Page Tables
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 36/81
Index with frame number
Inverted Page Table: A single global page table for allprocesses; One entry for each physical page
The table is shared — PID is required
Physical pages are now mapped to virtual — eachentry contains a virtual page number instead of aphysical one
The physical page number is not stored, since theindex in the table corresponds to it
Information bits, e.g. protection bit, are as usual
36/81
Standard PTE(32 bit system)
Inverted PTE(64 bit system)
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 37/81
(32-bit system)
page frame address | info
+--------------------+------+
| 20 | 12 |
+--------------------+------+
220 entries, 4 B each
SIZE page table =
220
× 4 = 4 MB(for each process)
(64-bit system)
pid | virtual page number | info
+-----+---------------------+------+
| 16 | 52 | 12 |
+-----+---------------------+------+
Assuming 16 bits for PID 52 bits for virtual page number 12 bits of information,
each entry takes16 + 52 + 12 = 80 bits = 10 bytes
If 1G (230 B) physical memory,
and 4K (212 B) page size, we’llhave 230−12 = 218 pages. So,
SIZE page table = 218 × 10 B = 2.5 MB
(for all processes)
37/81
Find index according to entry contents
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 38/81
( pid, p) ⇒ i
38/81
Inefficient: require searching the entire table
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 39/81
Inefficient: require searching the entire table
39/81
Hashed Inverted Page Tablesh h h bl l l b f h l
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 40/81
A hash anchor table — an extra level before the actualpage table
maps process IDsvirtual page numbers
⇒ page table entries
Since collisions may occur, the page table must dochaining
40/81
Hashed Inverted Page Table
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 41/81
41/81
User’s View: A Program Is A Collection Of S t
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 42/81
SegmentsA segment is a logical unit such as:
main program
procedure
function
method object
local variables
global variables
common block stack
symbol table
arrays
42/81
Logical View of Segmentation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 43/81
1
3
2
4
1
4
2
3
user space physical memory space
43/81
Segmentation Architecture
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 44/81
Logical address consists of a two tuple:
<segment-number, offset>
Segment table maps 2D virtual addresses into 1Dphysical addresses; each table entry has:
base contains the starting physical address where
the segments reside in memory limit specifies the length of the segment
Segment-table base register (STBR) points to thesegment table’s location in memory
Segment-table length register (STLR) indicatesnumber of segments used by a program;
segment number s is legal if s < STLR
44/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 45/81
45/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 46/81
(2, 53)⇒ 4300+53 = 4353
(3, 852)⇒ 3200+852 = 4052
(0, 1222)⇒ Trap!
46/81
The Intel Pentium Segmentation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 47/81
The logical address space of a process Private→LDT Shared→GDT
LDT Local Descriptor TableGDT Global Descriptor Table
Each program has its own LDT for segments local toit (code, data, stack, ...)
GDT is shared by all the programs, describessystem segments, including the OS itself
47/81
A segment descriptor is 64-bit long
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 48/81
An example LDT entry for code segment:
Relativeaddress
0
4
Base 0-15 Limit 0-15
Base 24-31 Base 16-23Limit16-19
G D 0 P DPL TypeS
;
;
32 Bits
the logical address is a pair (selector, offset)
selector | offset
+-----+-+--+--------+
| s |g|p | |
+-----+-+--+--------+
13 1 2 32
Selector is a 16-bit number
+-----+-+--+ s - segment number
| s |g|p | g - 0-global; 1-local
+-----+-+--+ p - protection use
13 1 2
48/81
Segmentation With Paging
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 49/81
selector | offset
+----+---+---+--------+
| s | g | p | |
+----+---+---+--------+
13 1 2 32
49/81
Segmentation With PagingLogical Address ⇒ Linear Address
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 50/81
Logical Address ⇒ Linear Address
50/81
Segmentation With PagingLinear Address ⇒ Physical Address
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 51/81
ea dd ess ⇒ ys ca dd ess
linear
51/81
Linear Address in Linux
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 52/81
Broken into four parts:
52/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 53/81
Demand Paging
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 54/81
Bring a page into memory only when it is needed Less I/O needed Less memory needed Faster response More users
Page is needed ⇒ reference to it invalid reference ⇒ abort not-in-memory ⇒ bring to memory
Lazy swapper never swaps a page into memoryunless page will be needed
Swapper deals with entire processes Pager deals with pages
54/81
Valid-Invalid BitWhen Some Pages Are Not In Memory
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 55/81
55/81
Page Fault Handling
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 56/81
56/81
Copy-on-WriteMore efficient process creation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 57/81
Parent and childprocesses initiallyshare the samepages in memory
Only the modifiedpage is copied uponmodification occurs
Free pages areallocated from a
pool of zeroed-outpages
57/81
Need For Page Replacement
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 58/81
Page replacementfind some page inmemory, but notreally in use, swap it
out
performance - want an algorithm resulting in lowest
page-fault rate Is the victim page modified?
Pick a random page to swap out?
Pick a page from the faulting process’ own pages? Or
from others? 58/81
FIFO Page Replacement Algorithm
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 59/81
Maintain a linked list (FIFO queue) of all pages in order they came into memory
Page at beginning of list replaced
Disadvantage The oldest page may be often used
59/81
Optimal Page Replacement Algorithm
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 60/81
Replace page needed at the farthest point in future Optimal but unrealizable
Estimate by ...
logging page use on previous runs of process although this is impractical. Similar to SJF
CPU-scheduling can be used for comparison studies
60/81
Least Recently Used (LRU) Algorithm
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 61/81
Assume recently-used-pages will used again soon throw out page that has not been used for longest
time
Keep counter in each page table entry choose page with lowest value counter require search update time-of-use field in the page table
every memory reference !! counter overflow — periodically zero the counter
Alternatively keep a linked list (stack) of pages
most recently used at front, least at rear update this list every memory reference !!
61/81
Second Chance Page Replacement Algorithm
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 62/81
62/81
Allocation of Frames
Each process needs minimum number of pages
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 63/81
Each process needs minimum number of pages
Fixed Allocation
Equal allocation — e.g., 100 frames and 5processes, give each process 20 frames.
Proportional allocation — Allocate according to thesize of process
ai = si∑si×m
Si size of process pi
m total number of framesai frames allocated to pi
Priority Allocation — Use a proportional allocation
scheme using priorities rather than size
priority i∑ priority i
or (si∑
si
, priority i∑
priority i)
63/81
Global vs. Local Allocation
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 64/81
If process Pi generates a page fault, it can select areplacement frame
from its own frames — Local replacement
from the set of all frames; one process can take aframe from another — Global replacement from a process with lower priority number
64/81
Thrashing
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 65/81
1. CPU not busy ⇒ add more processes
2. a process needs more frames ⇒ faulting, andtaking frames away from others
3. these processes also need these pages ⇒ alsofaulting, and taking frames away from others ⇒
chain reaction4. more and more processes queueing for the paging
device ⇒ ready queue is empty ⇒ CPU has nothingto do ⇒ add more processes ⇒ more page faults
5. MMU is busy, but no work is getting done, becauseprocesses are busy paging — thrashing
65/81
Thrashing
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 66/81
66/81
Demand Paging and ThrashingLocality Model
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 67/81
A locality is a set of pagesthat are actively usedtogether
Process migrates fromone locality to another
Localities may overlap
locality in a memory reference pattern
Why does thrashing occur?
size of locality > total memory size67/81
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 68/81
The Working-Set Algorithm
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 69/81
Information aboutone page 2084
2204 Current virtual time
2003
1980
1213
2014
2020
2032
1620
Page table
1
1
1
0
1
1
1
0
Time of last use
Page referencedduring this tick
Page not referencedduring this tick
R (Referenced) bit
Scan all pages examining R bit:
if (R == 1)set time of last use to current virtual time
if (R == 0 and age > τ)remove this page
if (R == 0 and age ≤ τ)
remember the smallest time
69/81
The WSClock Page Replacement Algorithm
A
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 70/81
When a page fault occurs,the page the hand ispointing to is inspected.The action taken dependson the R bit:
R = 0: Evict the pageR = 1: Clear R and advance hand
AB
C
D
E
FG
H
I
J
K
L
Fig. 4-17. The clock page replacement algorithm.
70/81
The WSClock Page Replacement Algorithm2204 Current virtual time
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 71/81
1213 0
2084 1 2032 1
1620 0
2020 12003 1
1980 1 2014 1
Time oflast use
R bit
(a) (b)
(c) (d)
New page
1213 0
2084 1 2032 1
1620 0
2020 12003 1
1980 1 2014 0
1213 0
2084 1 2032 1
1620 0
2020 12003 1
1980 1 2014 0
2204 1
2084 1 2032 1
1620 0
2020 12003 1
1980 1 2014 0
Fig. 4-22. Operation of the WSClock algorithm. (a) and (b) givean example of what happens when R = 1. (c) and (d) give anexample of R = 0.
71/81
Page-Fault Frequency Scheme
Establish ”acceptable” page fault rate
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 72/81
Establish acceptable page-fault rate
72/81
Memory Mapped Files
Mapping a file (disk block) to one or more memory
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 73/81
pages
Improved I/Operformance —much faster thanread() and write()system calls
Lazy loading(demand paging) —only a small portionof file is loadedinitially
A mapped file canbe shared, likeshared library
73/81
Other Issues - Prepaging
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 74/81
reduce faulting rate at startup remember working-set
Not always work if prepaged pages are unused, I/O and memory was
wasted
74/81
Other Issues Page Size There is no single best page size
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 75/81
Larger page size« Bigger internal fragmentation
« longer I/O time
Small page size
« Larger page table« more page faults
one page fault for each byte, if page size = 1 byte for a 200k process, with page size = 200k, only one
page fault
No best answer
75/81
Other Issues TLB Reach
TLB Reach - The amount of memory accessible from
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 76/81
ythe TLB
TLB Reach = ( TLB Size)× (Page Size)
Ideally, the working set of each process is stored inthe TLB
Otherwise there is a high degree of page faults Increase the Page Size
This may lead to an increase in fragmentation asnot all applications require a large page size
Provide Multiple Page Sizes This allows applications that require larger page
sizes the opportunity to use them without anincrease in fragmentation
76/81
Other Issues Program Structure
Example
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 77/81
Example
Data — int[128][128] Assume Page Size = 128 words
Each row is stored in one page
Program 1:for ( j =0;j <128; j++)
for ( i =0; i <128; i++)data [ i ] [ j ] = 0;
Worst case:
128 x 128 = 16, 384 page faults
Program 2:for ( i =0;i <128; i++)
for ( j =0;j <128; j++)data [ i ] [ j ] = 0;
Worst case:
128 page faults
77/81
Other Issues I/O interlock
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 78/81
Sometimes it is necessary to lock pages in memory sothat they are not paged out.
78/81
Other Issues I/O interlockCase 1
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 79/81
Be sure the following sequence of events does notoccur:
1. A process issues an I/O request, and then queueingfor that I/O device
2. The CPU is given to other processes3. These processes cause page faults
4. The waiting process’ page is unluckily replaced
5. When its I/O request is served, the specific frame is
now being used by another process
79/81
Other Issues I/O interlockCase 2
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 80/81
Consider the following sequence of events:
1. A low-priority process faults
2. The paging system selects a replacement frame. Then, the necessary page is loaded into memory
3. The low-priority process is now ready to continue,
and waiting in the ready queue4. A high-priority process faults
5. The paging system looks for a replacement
5.1 It sees a page that is in memory but not beenreferenced nor modified: perfect!
5.2 It doesn’t know the page is just brought in for thelow-priority process
80/81
Reference
Operating System Concepts, 8e, Chapter 8-9
7/30/2019 mm-101016203300-phpapp01
http://slidepdf.com/reader/full/mm-101016203300-phpapp01 81/81
Modern Operating System, 3e, Chapter 3
Understanding the Linux Kernel, 3e, Chapter 2
The Linux Kernel, Chapter 3
Intel 80386 Programmer’s Reference Manual,
Chapter 5
Linkers and Loaders
Understanding Memory
Wikipedia — x86-64
Beej’s Guide to IPC, Section 10: Memory MappedFiles
81/81