Post on 16-Dec-2015
transcript
1
Memory Management
Managing memory hierarchies
2
Memory Management
• Ideally programmers want memory that is– large
– fast
– non volatile
– transparent
• Memory hierarchy – small amount of fast, expensive memory – cache
– some medium-speed, medium price main memory
– gigabytes of slow, cheap disk storage
• Memory manager handles the memory hierarchy
3
Basic Memory ManagementMonoprogramming without Swapping or Paging
Three simple ways of organizing memory- an operating system with one user process
4
Multiprogramming
• We usually want more than one program…– Multiprogramming!
• Flexibility
• Utilization (CPU vs. I/O)
• Multi-user environments
• First try: partition the memory!
5
Multiprogramming with Fixed Partitions
• Fixed memory partitions– separate input queues for each partition– single input queue
6
Multiprogramming
Sidestep: How much do we actually gain from multiprogramming?
5 tasks @ 80% idle = 100% CPU utilization?
7
Modeling Multiprogramming
Degree of multiprogramming
np1on UtilizatiCPU
8
Analysis of Multiprogramming System Performance
• Arrival and work requirements of 4 jobs• CPU utilization for 1 – 4 jobs with 80% I/O wait• Sequence of events as jobs arrive and finish
– note numbers show amount of CPU time jobs get in each interval
9
Where to place a program?
• Where in the memory should we place our programs?– Memory starts at 0 and ends at 232!– We might want more than one program!– Programs might have different sizes!– Program size might grow (or shrink)!
10
Swapping (1)
Memory allocation changes as – processes come into memory– leave memory
Solution for relocation needed
11
Swapping (2)
• Allocating space for growing data segment• Allocating space for growing stack & data segment
12
Memory Management with Bit Maps
• Part of memory with 5 processes, 3 holes– tick marks show allocation units– shaded regions are free
• Corresponding bit map• Same information as a list
13
Memory Management with Linked Lists
Four neighbor combinations for the terminating process X
14
Issues with memory
• We want:– A lot of memory (more than RAM)– Transparency (Relocation)– Protection (rouge processes)– Speed (Cache is fast, RAM is OK, disk is slow)
• (Partial) Solution: Virtual Memory
15
Virtual Memory
• Separates:– Virtual (logical) addresses– Physical addresses
• Requires a translation at run time– Virtual Physical– Handled in HW (MMU)
16
Virtual MemoryPaging
The position and function of the MMU
17
Paging
• The relation betweenvirtual addressesand physical memory addres-ses given bypage table
• One page table per process is needed (per thread?)
• Page table needs to be reloaded at context switch
18
Address Translation
3 2 1 011 10 9 815 14 13 1231 30 29 28 27
Page offsetVirtual page number
Virtual address
3 2 1 011 10 9 815 14 13 1229 28 27
Page offsetPhysical page number
Physical address
Translation
© Patterson & Hennesy 1998
2048211
19
Page Tables
Internal operation of MMU with 16 4 KB pages
20
Hierarchical Page Tables
• 32 bit address with 2 page table fields
• Two-level page tables
Second-level page tables
Top-level page table
21
Page Tables
Typical page table entry
22
Paging
Every memory lookup:
1. Find the page in the page table
2. Find the (physical) memory location
Now we have two memory accesses (per reference)
Solution: Translation Lookaside Buffer (TLB)
(again a cache…)
23
TLBs – Translation Lookaside Buffers
A TLB to speed up paging
24
TLB Handling
Memory lookup:
• Look for page in TLB (fast)– If hit, fine go ahead!– If miss, find it and put it in the TLB:
• Find the page in the page table (hit)
• Reload the page from disk (miss)
25
Inverted Page Tables
Comparison of a traditional page table with an inverted page table
26
So where is the cache?
Valid Tag Data
Page offset
Page offset
Virtual page number
Virtual address
Physical page numberValid
1220
20
16 14
Cache index
32
Cache
DataCache hit
2
Byteoffset
Dirty Tag
TLB hit
Physical page number
Physical address tag
TLB
Physical address
31 30 29 15 14 13 12 11 10 9 8 3 2 1 0
© Patterson & Hennesy 1998
27
Paging
• So we know how to find a page table entry
• If it is not in the page table– Get it from disk
• What if the physical memory is full?– Throw some page out!– Remember cache replacement policies?
28
Page Replacement Algorithms
• Page fault forces choice – which page must be removed– make room for incoming page(s)
• Modified page must first be saved– unmodified just overwritten
• Better not to choose an often used page– will probably need to be brought back in soon
29
Optimal Page Replacement Algorithm
• 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
30
Not Recently Used Page Replacement Algorithm
• Each page has Reference bit, Modified bit– Bits are set by HW when page is referenced, modified– Reference bit is periodically unset (at clock ticks)
• Pages are classifiedClass 0: not referenced, not modifiedClass 1: not referenced, modifiedClass 2: referenced, not modifiedClass 3: referenced, modified
• NRU removes page at random– From lowest numbered non empty class
• NRU is simple and gives decent performance
31
FIFO Page Replacement Algorithm
• Maintain a linked list of all pages – in the order they came into memory
• Page at beginning of list replaced
• Disadvantage– page in memory the longest may be used often
32
Second Chance Page Replacement Algorithm
• Operation of a second chance– pages sorted in FIFO order– Inspect the R bit, give the page a second chance if R=1– Put the page at the end of the list (like a new page)– Eventually the page might be selected anyway (how?)Example: Page fault @ 20, A has R bit set
• 2nd Chance moves pages around in the list …
33
The Clock Page Replacement Algorithm
How does this compare with second chance?
Hand points to oldest page
34
Locality
• Locality in:– Time
• A page recently used, will be used soon again
– Space• Adjacent pages are likely to be used together
35
Least Recently Used (LRU)
• Locality: pages used recently will be used soon– throw out the page that has been unused longest
• Must keep a linked list of pages– most recently used at front, least at rear– update this list every memory reference !!
• Alternative: counter (64 bit) in the page table entry– Update on memory reference– choose page with lowest value counter– periodically zero the counter
36
Least Recently Used
LRU using a matrix – pages referenced in order 0,1,2,3,2,1,0,3,2,3
1. Set row k to 12. Set column k to 0
37
Simulating LRU in Software
• Both solutions (counter, matrix) require extra hardware
• and they don’t scale very well with large page tables …
• Approximations of LRU can be done in SW
38
Simulating LRU in Software
NFU (Not Frequently Used)
• A counter is associated with each page
• At each clock interrupt add R to the counter
• Problems?
39
NFU
• NFU tends to have a long memory!
• Pages frequently used in pass 1 may still be hot in later passes, even though they are not used!
• Solution: instead of adding R, shift R from the left (R=1, c=010 c’=101)
• This algorithm is called aging
40
Simulating LRU in Software
• The aging algorithm simulates LRU in software• Note 6 pages for 5 clock ticks, (a) – (e)
41
Aging
• This algorithm works fine, but consider– Granularity
• Page accesses between ticks?
– Memory• How long is the memory?
• Tannenbaum: 8 bits @ 20ms ticks works ok
42
Memory Management
• Managing hierarchies of memory– Caches– RAM– Disk
• Paging– Page tables– Page replacement algorithms
Virtual Memory