Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | kelly-atkins |
View: | 216 times |
Download: | 2 times |
Paging
Memory Partitioning Troubles
• Fragmentation
• Need for compaction/swapping
• A process size is limited by the available physical memory
• Dynamic growth of partition is troublesome
• No winning policy on allocation/deallocation P2
P3
The Basic Problem
• A process needs a contiguous partition(s)
But
• Contiguity is difficult to manage
Contiguity mandates the use of physical memory addressing (so far)
The Basic Solution
• Give illusion of a contiguous address space
• The actual allocation need not be contiguous
• Use a Memory Management Unit (MMU) to translate from the illusion to reality
A solution: Virtual Addresses
• Use n-bit to represent virtual or logical addresses
• A process perceives an address space extending from address 0 to 2n-1
• MMU translates from virtual addresses to real ones
• Processes no longer see real or physical addresses
Paged Memory
• Subdivide the address space (both virtual and physical) to “pages” of equal size
• Use MMU to map from virtual pages to physical ones
• Physical pages are called frames
Paging: Example
0 0Virtual VirtualPhysical
Process 0
Process 1
Key Facts
• Virtual address spaces of different processes are independent– Two or more may have the same address range
– Yet the mappings differentiate between them
• A virtual page has no storage of its own– It must be backed by a physical frame (real page) that provides the
actual storage
– A contiguous virtual space need not be physically contiguous
Key Facts
• Physical address space is independent of virtual address spaces– They can have different sizes
– Allows process size to be independent of available physical memory size
• Page size is always a power of 2, to simplify hardware addressing
Page Tables
0
Virtual
Page Table
Page Table Structure
• Indexed by virtual page number
• Contains frame number (if any)
• Contains protection bits
• Contains reference bit
Frame No. v w r x f
Frame No. v w r x f
Frame No. v w r x f
v: valid bitw: write bitr: read bitx: execute bit (rare)f: reference bitm: modified bit
m
m
m
Mapping Virtual to Real Addresses
Virtualaddress
n bits
virtual page number offset
index intopage table
frame no. offset
Physical addressp bits
s bits
s bits
s: log (page size)
Example: PDP-11
Virtualaddress
16 bits
vpn offset
frame no. offset
Physical address22 bits
13 bits
13 bits
Page size: 8KUp to 4M mem
8-entrypagetable
(in hardware)
Weird Stuff: Free Page ManagementVirtual VirtualPhysical
Process 0 Process 1
Key fact:A memory framecannot be accessedunless mappedFree space
Fun Stuff: Sharing
0 0Virtual VirtualPhysical
Process 0
Process 1
Sharing
• Processes can share pages by mapping their virtual pages to the same memory frame
• In UNIX and Windows, code segments of processes running the same program to share the pages containing executables– saves a lot of memory
– saves loading time for frequently run programs
• Fine tuning using protection bits (rwx)
Fork Revisited: Copy-on-WriteVirtual VirtualPhysical
Father Child
W
W
W
W
W
W
Copy-on-Write Fork
• Initially no memory copying– Efficient
– If an exec follows, no much harm
• Page tables set the protection to disallow writes
• If either father or child attempts to write, a page fault occurs
Copy-on-WriteVirtual VirtualPhysical
Father Child
W
W
W
W
W
W
Requirements for Sharing
• Page frames must have a reference count– Cannot be deallocated unless unmapped
– Adds complexity to memory manager
• Protection bits must be set properly
Page Table Implementation
Page Table Implementations
Key issues:
• Each instruction requires one or more memory accesses:– Mapping must be done very quickly
• Where do we store the page table?– It is now part of the context, with implications on context
switching
• Hardware must support auxiliary bits
PDP-11 Example Revisited
• Page table is small (8 entries)– Can be implemented in hardware
– Moderate effect on context switching time
• Each process will need an 8-entry array in its PCB to store page table when not running
• Protections works fine
But: what if address space is 32-bit
Page Table Size Problems
Assume 16K page size and 32-bit address space
Then:
• For each process, there are 219 virtual pages
• Page table size: 219 * 4 bytes/entry– Page table requires 2 Mbytes
– Cannot be stored in hardware, slowing down the mapping from virtual to physical addressing
Solution1: Multi-Level Page Tables
• Use two or three levels page tables
• All entries in the topmost level must be there
• Entries in lower levels are there only if needed
• Store page tables in memory
• Have one CPU register contain address of top-most level table
Example: SPARC
Context table(up to 4K registers)
3-level page table
offsetindex 1 index 2 index 3
Context
8 6 6 12
Level 1Level 2
Page
Level 3
SPARC: Cont’d
• Only level 1 table need be there entirely– 256 entries * 4 bytes/entry = 1K /process
• Context switching is not affected– Just save and restore the context register/process
• Second and third level tables are there only if necessary
Translation Lookaside Buffer
• A small associative memory in processor
• Contains recent mapping results
• Typically 8 to 32 entries
• If access is localized, works very well
• Must be flushed on context switching
• If TLB misses, then must resolve through page tables in main memory (slow)
Other Varieties
• 2-level page table in VAX systems
• 4-level page table in the 68030/68040
• Organize the cache memory by virtual addresses (instead of physical addresses)– Remove the TLB from critical path
– Combine cache misses with address translations
– e.g. MIPS 3000/4000
Solution 2: Inverted Page Tables
Rationale:
• Conventional per-process page tables depend on virtual memory size
• Virtual address space is getting larger (e.g. 64 bits)
• Size of physical memory projected is less than virtual memory in foreseeable future
Inverted Page Table
Main Idea:
• Global page table indexed by frame number
• Each entry contains virtual address & pid
• Use TLB to reduce the need to access PT
• On a TLB miss:– Search page table for the <virtual address, pid>
– Physical address is obtained from the index of the entry (frame number)
Inverted Page Table Structure
• Indexed by frame number
• Entry contains virtual address and pid using the frame number (if any)
• Contains protection & reference
Virtual addr v w r x f
v w r x f
v w r x f
v: valid bitw: write bitr: read bitx: execute bit (rare)f: reference bitm: modified bit
m
m
m
Virtual addr
Virtual addr
pid
pid
pid
Mapping Virtual to Real Addresses
Virtualaddress
n bits
virtual page number offset
+ pid:searchkey intoinvertedpage table
frame no. offset
Physical addressp bits
s bits
s bits
Properties & Problems
• Table size is independent of virtual address size, only function of physical memory size
• TLB misses are expensive– We don’t know where to look
– May require searching entire table (very bad)
• Virtual memory more expensive
• Sharing becomes very difficult
A Solution
• Organize Inverted Page Table as a hash table– Search key <pid, vaddr>
– Search in hardware or software
• Examples: IBM 38, RS/6000, HP PA-RISC systems
Sharing & Inverted Page Tables• Conceivably possible with a general
hashing function
• Requires an additional field in page table entry
Virtual addr v w r x f
v w r x f
v w r x f
m
m
m
Virtual addr
Virtual addr
pid
pid
pid
Frame no.
Frame no.
Frame no.
• Size no longer limited, so no system implements
it