Get documents about "Virtual Memory Demand Paging
Document Sample
Virtual Memory & Demand Paging
accommodating 32-bit (& larger) addresses
Finally! A Lecture
I wish we were on Something I
still doing Understand -
NAND gates... PAGING!
6.004 Fall ‘97... L41 11/13 1
SAW 8/7/00 10:07
Top 10 reasons for a
BIG Address Space
10. Keeping TI’s memory division in business.
9. Unique addresses within every internet host.
8. Generating good 6.004 Final problems.
7. Performing ADD via table lookup
6. Support for meaningless advertising hype
5. Emulation of a Turning Machine’s tape.
4. Supporting lazy programmers.
3. Isolating ISA from ______________________
2. Usage _________________________________
1. Programming ____________________________
6.004 Fall ‘97... L41 11/13 2
SAW 8/7/00 10:07
Squandering Address Space...
Address
COMPLEX, modular program Space
(eg, EMACs).... modules like
• DOCTOR
• LIFE
• convert-to-piglatin
•••
STACK: How much to reserve?
(consider RECURSION!)
DATA: N variable-size records...
Bound N? Bound Size?
OBSERVATIONS:
• Can’t BOUND each usage...
without compromising use.
• Actual use is SPARSE
• Working set even MORE sparse
6.004 Fall ‘97... L41 11/13 3
SAW 8/7/00 10:07
Transparently Extending
the Memory Hierarchy
FAST DYNAMIC
CPU DISK
STATIC RAM
"CACHE" "MAIN "Secondary
MEMORY" Storage"
So, we’ve used SMALL fast memory + BIG slow
memory to fake BIG FAST memory.
Can we combine RAM and DISK to fake DISK
size at RAM speeds?
VIRTUAL MEMORY
VIRTUAL MEMORY
••use of RAM as cache to much larger storage pool, on
use of RAM as cache to much larger storage pool, on
slower devices
slower devices
••TRANSPARENCY --VM locations "look" the same to
TRANSPARENCY VM locations "look" the same to
program whether on DISK or in RAM.
program whether on DISK or in RAM.
••ISOLATATION of RAM size from software.
ISOLATATION of RAM size from software.
6.004 Fall ‘97... L41 11/13 4
SAW 8/7/00 10:07
Virtual Memory
ILLUSION: Huge memory (232 bytes? 264bytes?)
ACTIVE USAGE: Tiny fraction (220 bytes?)
HARDWARE:
• 2 20 bytes of RAM
• 2 32 bytes of DISK...
... maybe much less!
ELEMENTS OF DECEIT:
• Partition memory into “Pages” (2K-4K-8K)
• MAP a few to RAM, others to DISK
• Keep “HOT” pages in RAM.
VA MMU PA
CPU RAM
6.004 Fall ‘97... L41 11/13 5
SAW 8/7/00 10:07
Simple Pagemap Design
VirtPg #
FUNCTION: Given Virtual Adr,
• Map to PHYSICAL adr
OR
• Cause PAGE FAULT allowing
PhysPg # page replacement
Virtual Memory Physical Memory
DR
X
X
X
PAGEMAP
"DIRTY" and "RESIDENT" bits in each entry.
Why use HIGH address bits to select page?
... LOCALITY. Keep related data on same page.
Why use LOW address bits to select cache line?
... LOCALITY. Keep related data from competing
for same cache lines.
6.004 Fall ‘97... L41 11/13 6
SAW 8/7/00 10:07
Virtual Memory vs. Cache
CACHE: • RELATIVELY SHORT BLOCKS
• FEW LINES: SCARCE RESOURCE
• MISS TIME: 3X-10X HIT TIMES.
CACHE: TAG DATA
A <A> MAIN
MEMORY
B <B>
=?
VM:
VPAGE NO. OFFS
PAGEMAP PHYSICAL MEMORY
• VERY LONG ACCESS TIME, FAST TRANSFER
5
=> MISS TIME: ~10 x Hit Time (=> WRITE-BACK!)
=> Long Blocks (PAGES) in RAM.
• PLENTIFUL LINES (eg, tag for each virtual page)
• TAGs stored in PAGEMAP; DATA in Physical Mem
6.004 Fall ‘97... L41 11/13 7
SAW 8/7/00 10:07
Virtual Memory: the 6-1 view
The address translation:
Virtual Memory Physical Memory
DR
1
1
0 X
0 X
1
1
0 X
PAGEMAP
Pagemap Characteristics:
• One entry per ____________________ Page!
• RESIDENT bit = 1 for pages stored in RAM, or
0 for non-resident (disk or unallocated)
• Contains PHYSICAL page number of each
resident page
• DIRTY bit says we’ve changed this page since
loading it from disk
• PAGE FAULT on R=0
6.004 Fall ‘97... L41 11/13 8
SAW 8/7/00 10:07
Virtual Memory: the 6-3 view
VirtPg #
Problem: Translate
VIRTUAL ADDRESS
to PHYSICAL ADDRESS
PhysPg #
Algorithm: “Demand Paging”
int VtoP(VPageNo, PO)
{ if (!R[VPageNo]) PageFault(VPageNo);
return (PA[VPageNo] << p) + PO;
}
/* Handle a missing page... */
PageFault(VPageNo)
{ int i;
i = SelectLRUPage();
WritePage(DiskAdr[i], PA[i]);
R[i] = 0;
PA[VPageNo] = PA[i];
ReadPage(DiskAdr[VPageNo], PA[i]);
R[VPageNo] = 1;
}
6.004 Fall ‘97... L41 11/13 9
SAW 8/7/00 10:07
The HW/SW Balance
IDEA: • DEVOTE HARDWARE TO HIGH-TRAFFIC,
PERFORMANCE-CRITICAL PATH
• USE (slow, cheap) SOFTWARE to handle
exceptional cases.
int VtoP(VPageNo, PO)
{ if (!R[VPageNo]) PageFault(VPageNo);
return (PA[VPageNo] << p) + PO;
}
/* Handle a missing page... */
PageFault(VPageNo)
{ int i;
i = SelectLRUPage();
WritePage(DiskAdr[i], PA[i]);
R[i] = 0;
PA[VPageNo] = PA[i];
ReadPage(DiskAdr[VPageNo], PA[i]);
R[VPageNo] = 1;
}
HARDWARE performs address translation,
DETECTS page faults, whence
• Running program suspended ("interrupted");
• PageFault(...) call is forced;
• On return from PageFault, running program
continues.
6.004 Fall ‘97... L41 11/13 10
SAW 8/7/00 10:07
Pagemap Arithmetic
p
D R PA
VPageNo PO 1
1
1
0
v 1
m
PAGEMAP PHYSICAL MEMORY
PPageNo PO
(v+p) bits in virtual address
(m+p) bits in physical address
v
2 number of VIRTUAL pages.
m
2 # of main memory (PHYSICAL) pages.
p
2 page size.
v +p
2 virtual memory locations
m+p
2 physical memory locations
v
2 x (m+2) pagemap size. (in bits)
TYPICAL PAGE SIZE: 1K - 8K bytes.
TYPICAL (v+p): 32 (or more!) bits.
TYPICAL (m+p): 20-28 bits (1-256 MB).
6.004 Fall ‘97... L41 11/13 11
SAW 8/7/00 10:07
Pagemap Arithmetic -- continued
VirtPg #
SUPPOSE...
32-bit VA v
213 page size (8KB)
220 RAM (1MB)
p
m
PhysPg #
THEN:
# Physical Pages = ____________________
# Virtual Pages = _____________________
# Page Map Entries = _________________
Use SRAM for page map??? OUCH!
6.004 Fall ‘97... L41 11/13 12
SAW 8/7/00 10:07
RAM-resident page maps
SMALL page maps can use dedicated SRAM...
... gets expensive for bigger ones.
SOLUTION: Move page map to MAIN MEMORY.
Physical Memory
int VtoP(VPageNo, PO)
{ if (!R[VPageNo]) PageFault(VPageNo);
return PA[VPageNo]<<p + PO;
}
PROBLEM: 2X Performance hit!
Each memory reference now takes 2
accesses!
6.004 Fall ‘97... L41 11/13 13
SAW 8/7/00 10:07
Translation Lookaside Buffer
PROBLEM: 2X Performance hit...
... Each memory reference now takes 2 accesses!
SOLUTION: CACHE the pagemap entries!
TLB
(dedicated Physical Memory
cache)
IDEA: LOCALITY in memory reference patterns ==>
SUPER locality in references to pagemap.
MANY variations on this theme -- eg
Sparse pagemap storage
Paging the pagemap
6.004 Fall ‘97... L41 11/13 14
SAW 8/7/00 10:07
Optimizing for SPARSELY POPULATED VM
TLB
(dedicated Physical Memory
cache)
On TLB Miss:
Lookup VPN in data structure (say, list of
VPN-PPN pairs);
Use (e.g.) hash coding to speed up search.
IDEA (Demand Paging):
Store only pagemap entries for ALLOCATED
pages!
Allocate new entries “on demand” (say, on
stack overflow)
TIME PENALTY? LOW if TLB hit rate is high!
6.004 Fall ‘97... L41 11/13 1 5
SAW 8/7/00 10:07
Moving page map to DISK...
Given HUGE virtual memory, even storing pagemap
in RAM may be too expensive...
... seems like we could store little-used parts of it
on the disk.
SAY, isn’t that what VIRTUAL MEMORY is for???
0:
SUPPOSE we store page map in VP
virtual memory 0
• starting at (virtual)
address 0
VP
• 4 bytes/entry
1
• 4KB/page
Then there’s _____________ VP
entries per page of pagemap... 2
Pagemap entry for VP v is stored
at virtual address v*4
6.004 Fall ‘97... L41 11/13 16
SAW 8/7/00 10:07
Virtual Storage of PageMap
Scheme:
• Page table stored starting at VA 0
• Mapping of page 0 "wired in": vpn 0 = ppn 0
• 4096-byte (212) page size
• Note RECURSION to map PT adrs!
• Each level removes 10 VAdr bits (at 4 bytes per
page table entry)
/* Translate VA to PA...
* assumes page resident,4096-byte pages */
int VtoP(vpn, PO)
{ if (vpn == 0) return PO;
else return PO + /* offset + */
VFetch(vpn*4)<<12; /*PMap[vpn] */
}
/* fetch contents word at VIRTUAL
address vadr */
VFetch(vadr)
{ return PFetch(VtoP(vadr>>12,
vadr&0xFFF));
}
/* Fetch contents of word at PHYSICAL
address padr */
PFetch(padr)
{ ... }
6.004 Fall ‘97... L41 11/13 17
SAW 8/7/00 10:07
Contexts
a CONTEXT is a mapping of VIRTUAL to PHYSICAL
locations, as dictated by pagemap contents.
Virtual Memory Physical Memory
D R
X
X
X
PAGEMAP
SEVERAL programs may be simultaneously loaded
into main memory, each in its separate context:
Virtual Physical Virtual
Memory 1 Memory Memory 2
“________________ ________________”:
RELOAD PAGEMAP
6.004 Fall ‘97... L41 11/13 18
SAW 8/7/00 10:07
Roles of CONTEXTs ...
... a preview
Virtual Physical Virtual
Memory 1 Memory Memory 2
1. TIMESHARING among several programs --
• Separate context for each program
• OS loads appropriate context into
pagemap when switching among pgms
2. Separate context for OS “Kernel” (eg,
interrupt handlers)...
• “Kernel” vs “User” contexts
• Switch to Kernel context on interrupt;
• Switch back on interrupt return.
HARDWARE SUPPORT: 2 HW pagemaps
6.004 Fall ‘97... L41 11/13 19
SAW 8/7/00 10:07
Using caches
with virtual memory
Virtual Cache: Tags match virtual addresses
Virtual Cache: Tags match virtual addresses
DYNAMIC
CPU CACHE MMU RAM
• FAST: No MMU time on HIT. DISK
• Problem: Cache invalid after context
switch
Physical Cache: Tags match physical addresses
Physical Cache: Tags match physical addresses
DYNAMIC
CACHE RAM
CPU MMU
DISK
• Avoids STALE
CACHE DATA after
context switch.
• SLOW: MMU time on HIT.
6.004 Fall ‘97... L41 11/13 20
SAW 8/7/00 10:07
Physical vs. Virtual Cache:
BEST OF BOTH WORLDS
MMU DISK
DYNAMIC
CPU RAM
CACHE
OBSERVATION: If cache line selection is based on
unmapped page offset bits, RAM access in a
physical cache can overlap pagemap access:
v PAGEMAP select bits
PHYSICAL cache, overlapped
with pagemap lookup.
CACHE select bits
Šp
6.004 Fall ‘97... L41 11/13 21
SAW 8/7/00 10:07
Virtual Memory: Issues
• Integration with memory system hardware:
• Translation Lookaside Buffers, caches
• Multi-level memory mapping
• Hardware support for multiple contexts
• Integration with system software:
• Page Fault handling
• Working set management heuristics
• Contexts as a programming construct
• Transparency issues & compromises
6.004 Fall ‘97... L41 11/13 22
SAW 8/7/00 10:07
Related docs
