10/9/2013 Anthony D. Joseph and John Canny CS162 UCB Fall 2013

Transcription

1 Post Project 1 lass Format S162 Operating Systems and Systems Programming Lecture 11 Page llocation and Replacement Mini quizzes after each topic Not graded! Simple True/False Immediate feedback for you (and me) Separate from pop quizzes October 9, 2013 nthony. Joseph and John anny Quiz 11.1: aches & TLs Q1: True _ False _ ssociative caches have fewer compulsory misses than direct mapped caches Q2: True _ False _ Two-way set associative caches can cache two addresses with same cache index Q3: True _ False _ With write-through caches, a read miss can result in a write Q5: True _ False _ TL caches translations to virtual addresses Quiz 11.1: aches & TLs Q1: True _ False _ X ssociative caches have fewer compulsory misses than direct mapped caches Q2: True X_ False _ Two-way set associative caches can cache two addresses with same cache index Q3: True _ False _ X With write-through caches, a read miss can result in a write Q5: True _ False X_ TL caches translations to virtual addresses Page 1

2 ddress: Review: Two-level table 10 bits 10 bits 12 bits P1 index P2 index Offset Physical ddress: Physical Page # Offset X86_64: Four-level table! 9 bits 9 bits 9 bits 9 bits 12 bits 48-bit Offset ddress: P1 index P2 index P3 index P4 index 4K PageTablePtr PageTablePtr 4 bytes 8 bytes 4096-byte s (12 bit offset) Page tables also 4k bytes (able) 4 bytes Physical ddress: (40-50 bits) Physical Page # 12bit Offset I64: 64bit addresses: Six-level table?!? I64: Inverse Page Table (IPT) Idea: index the table by physical s instead of VM 64bit 7 bits 9 bits 9 bits 9 bits 9 bits 9 bits 12 bits ddress: P1 index P2 index P3 index P4 index P5 index P6 index Offset No! Too slow Too many almost-empty tables VM0 VM1 VM2 VM3 Process id 0 memory VM0 0x0 pid 1 0x1 VM2 0x2 VM1 0x3 xx free 0x4 pid 2 0x5 pid 1 0x6 VM3 0x7 Inverse Page Table 0x0000 0x1000 0x2000 0x3000 0x4000 0x5000 0x6000 0x7000 VM0, proc0 VM2, proc0 VM1, proc0 VM3, proc0 Physical memory in 4k s Page numbers in red Page 2

3 IPT address translation Need an associative map from VM to IPT address: Use a hash map. Process 0 virtual address VM2 (52b) Offset (12b) Physical address 0x3 Offset (12b) IPT address translation Note: can t share memory: only one hashed entry will match. Process 0 address VM2 (52b) Offset (12b) Hash VM # pid 1 xx pid 2 pid 1 VM0 VM1 VM2 free VM3 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x0000 0x1000 0x2000 0x3000 0x4000 0x5000 0x6000 VM0, proc0 VM2, proc0 VM1, proc0 Process 1 address VM4 (52b) Offset (12b) pid 1 xx pid 2 pid 1 VM0 VM1 VM2 free VM3 0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 Inverse Page Table 0x7000 VM3, proc0 Inverse Page Table I64: Inverse Page Table (IPT) Pros: Page table size naturally linked to physical memory size. Only two memory accesses (most of the time). Shouldn t need to out the table. Hash function can be very fast if implemented in hardware. ons: an t (easily) share s. Have to manage collisions, e.g. by chaining, which adds memory accesses. Quiz 11.2: ddress Translation Q1: True _ False _ Paging does not suffer from external fragmentation Q2: True _ False _ The segment offset can be larger than the segment size Q3: True _ False _ Paging: to compute the physical address, add physical # and offset Q4: True _ False _ Uni-programming doesn t provide address protection Q5: True _ False _ address space is always larger than physical address space Q6: True _ False _ Inverted tables keeps fewer entries than multi-level tables Page 3

4 Quiz 11.2: ddress Translation Q1: True _ X False _ Paging does not suffer from external fragmentation Q2: True _ False _ X The segment offset can be larger than the segment size Q3: True _ False _ X Paging: to compute the physical address, add physical # and offset Q4: True _ X False _ Uni-programming doesn t provide address protection Q5: True _ False _ X address space is always larger than physical address space Q6: True _ False _ X Inverted tables keeps fewer entries than multi-level tables PageTablePtr Review: Translation Lookaside uffer ddress: P1 index P2 index Offset Page Table (1 st level) TL: Page Table (2 nd level) Physical ddress: Physical Page # Offset Physical Memory: ddress: P1 index P2 index PageTablePtr Offset Review: ache Physical ddress: Physical Page # Offset Physical Memory: Goals for Today Page Replacement Policies FIFO LRU lock lgorithm Page Table (1 st level) Page Table (2 nd level) tag index byte cache: tag: block: TL: Note: Some slides and/or pictures in the following are adapted from slides 2005 Silberschatz, Galvin, and Gagne. Many slides generated from my lecture notes by Kubiatowicz Page 4

5 emand Paging Modern programs require a lot of physical memory Memory per system growing faster than 25%-30%/year ut they don t use all their memory all of the time rule: programs spend 90% of their time in 10% of their code Wasteful to require all of user s code to be in memory Solution: use main memory as cache for disk/ss Processor ore ore aching Main Memory (RM) aching Secondary Storage (SS) Secondary Storage (isk) emand Paging is aching Since emand Paging is aching, we must ask: Question What is the block size? What is the organization of this cache (i.e., direct-mapped, setassociative, fully-associative)? How do we find a in the cache? What is replacement policy? (i.e., LRU, Random, ) What happens on a miss? What happens on a write? (i.e., write-through, write-back) hoice 1 Fully-associative: arbitrary virtual physical mapping First check TL, then traverse tables Requires more explanation (kinda LRU) Go to lower level to fill a miss (i.e., disk) efinitely write-back. Need a dirty bit ()! emand Paging Mechanisms PTE helps us implement demand paging Valid Page in memory, PTE points at physical Not Valid Page not in memory; use info in PTE to find it on disk when necessary Suppose user references with invalid PTE? Memory Management Unit (MMU) traps to OS» Resulting trap is a Page Fault What does OS do on a Page Fault?:» hoose an old to replace» If old modified ( =1 ), write contents back to disk» hange its PTE and any cached TL to be invalid» Load new into memory from disk» Update table entry, invalidate TL for new entry» ontinue thread from original faulting location TL for new will be loaded when thread continued! While pulling s off disk for one process, OS runs another process from ready queue» Suspended process sits on wait queue Steps in Handling a Page Fault Page 5

6 emand Paging Example Since emand Paging like caching, can compute average access time! ( Effective ccess Time ) ET = Hit Rate x Hit Time + Miss Rate x Miss Time Example: Memory access time = 200 nanoseconds verage -fault service time = 8 milliseconds Suppose p = Probability of miss, 1-p = Probably of hit Then, we can compute ET as follows: ET = (1 p) x 200ns + p x 8 ms = (1 p) x 200ns + p x 8,000,000ns = 200ns + p x 7,999,800ns If one access out of 1,000 causes a fault, then ET = 8.2 μs: This is a slowdown by a factor of 40! What if want slowdown by less than 10%? ET < 200ns x 1.1 p < 2.5 x 10-6 This is about 1 fault in 400,000! What Factors Lead to Misses? ompulsory Misses: Pages that have never been d into memory before How might we remove these misses?» Prefetching: loading them into memory before needed» Need to predict future somehow! More later. apacity Misses: Not enough memory. Must somehow increase size. an we do this?» One option: Increase amount of RM (not quick fix!)» nother option: If multiple processes in memory: adjust percentage of memory allocated to each one! onflict Misses: Technically, conflict misses don t exist in virtual memory, since it is a fully-associative cache Policy Misses: aused when s were in memory, but kicked out prematurely because of the replacement policy How to fix? etter replacement policy Page Replacement Policies Why do we care about Replacement Policy? Replacement is an issue with any cache Particularly important with s» The cost of being wrong is high: must go to disk» Must keep important s in memory, not toss them out FIFO (First In, First Out) Throw out oldest. e fair let every live in memory for same amount of time. ad, because throws out heavily used s instead of infrequently used s MIN (Minimum): Replace that won t be used for the longest time Great, but can t really know future Makes good comparison case, however RNOM: Pick random for every replacement Typical solution for TL s. Simple hardware Unpredictable Replacement Policies (on t) FIFO: Replace that has been in for the longest time. e fair to s and give them equal time. ad idea because use is not even. We want to give more time to heavily used s. How to implement FIFO? It s a queue (can use a linked list) Head(Oldest) Page 6 Page 7 Page 1 Page 2 Oldest is at head Tail(Newest) When a is brought in, add it to tail. Eject head if list longer than capacity Page 6

7 Replacement Policies (on t) LRU (Least Recently Used): Replace that hasn t been used for the longest time Programs have locality, so if something not used for a while, unlikely to be used in the near future. Seems like LRU should be a good approximation to MIN. How to implement LRU? Use a list? Replacement Policies (on t) LRU (Least Recently Used): Replace that hasn t been used for the longest time Programs have locality, so if something not used for a while, unlikely to be used in the near future. Seems like LRU should be a good approximation to MIN. ifferent if we access a that is already loaded: Head(LRU) Page 6 Page 7 Page 1 Page 2 Head(LRU) Page 6 Page 2 Page 1 Page 2 LRU is at head Tail (MRU) When a is used for the first time, add it to tail. Eject head if list longer than capacity LRU is at head Tail (MRU) When a is used again, remove from list, add it to tail. Eject head if list longer than capacity Replacement Policies (on t) LRU (Least Recently Used): Replace that hasn t been used for the longest time Programs have locality, so if something not used for a while, unlikely to be used in the near future. Seems like LRU should be a good approximation to MIN. ifferent if we access a that is already loaded: Head(LRU) Page 6 Page 1 Page 2 LRU is at head Tail (MRU) When a is used again, remove from list, add it to tail. Eject head if list longer than capacity Problems with this scheme for paging? Updates are happening on use, not just swapping List structure requires extra pointers c.f. FIFO, more updates In practice, people approximate LRU (more later) Suppose we have 3 frames, 4 virtual s, and following reference stream: onsider FIFO Page replacement: Ref: Page: Example: FIFO FIFO: 7 faults. When referencing, replacing is bad choice, since need again right away Page 7

8 Example: MIN Suppose we have the same reference stream: onsider MIN Page replacement: Ref: Page: MIN: 5 faults Look for not referenced farthest in future. What will LRU do? Same decisions as MIN here, but won t always be true! When will LRU perform badly? onsider the following: LRU Performs as follows (same as FIFO here): Ref: Page: Every reference is a fault! MIN oes much better: Ref: Page: Graph of Page Faults Versus The Number of Frames dding Memory oesn t lways Help Fault Rate oes adding memory reduce number of faults? Yes for LRU and MIN Not necessarily for FIFO! (alled elady s anomaly) Page: E E E Page: E E One desirable property: When you add memory the miss rate goes down oes this always happen? Seems like it should, right? No: elady s anomaly ertain replacement algorithms (FIFO) don t have this obvious property! E 2 E 3 4 fter adding memory: With FIFO, contents can be completely different In contrast, with LRU or MIN, contents of memory with X s are a subset of contents with X+1 Page Page 8

9 dministrivia Project #1: esign doc (submit proj1 final design) and group evals (Google ocs form) due today at 11:59PM» Group evals are anonymous to your group Midterm #1 is Monday Oct 21 5:30-7pm in 145 winelle (-L) and 2060 Valley LS (M-Z) losed book, double-sided handwritten of notes, no calculators, smartphones, Google glass etc. overs lectures #1-13 (isks/sss, Filesystems), readings, handouts, and projects 1 and 2 Review session 390 Hearst Mining, Fri October 18, 5-7 PM 5min reak lass feedback is always welcome! Implementing LRU & Second hance Second hance Illustration Perfect: Timestamp on each reference Keep list of s ordered by time of reference Too expensive to implement in reality for many reasons Second hance lgorithm: pproximate LRU» Replace an old, not the oldest FIFO with use bit etails use bit per physical» set when accessed On fault check at head of queue» If use bit=1 clear bit, and move to tail (give the second chance!)» If use bit=0 replace Moving s to tail still complex Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives first loaded last loaded u: Page 9

10 Second hance Illustration Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives Second hance Illustration Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives first loaded last loaded first loaded last loaded u:1 u:1 F Second hance Illustration Second hance Illustration Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives ccess Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives ccess Page E arrives first loaded last loaded first loaded last loaded u:1 u:1 F u:1 u:1 F Page 10

11 Second hance Illustration Second hance Illustration Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives ccess Page E arrives Max table size 4 Page arrives Page arrives ccess Page arrives Page arrives ccess Page E arrives first loaded last loaded first loaded last loaded u:1 F F E lock lgorithm lock Replacement Illustration lock lgorithm: more efficient implementation of second chance algorithm rrange physical s in circle with single clock hand etails: On fault:» heck use bit: 1 used recently; clear and leave it alone 0 selected candidate for replacement» dvance clock hand (not real time) Will always find a or loop forever? Max table size 4 Invariant: point at oldest Page arrives Page 11

12 lock Replacement Illustration Max table size 4 Invariant: point at oldest lock Replacement Illustration Max table size 4 Invariant: point at oldest Page arrives Page arrives ccess Page arrives Page arrives ccess Page arrives u: lock Replacement Illustration lock Replacement Illustration Max table size 4 Max table size 4 Invariant: point at oldest Invariant: point at oldest Page arrives Page arrives ccess Page arrives Page arrives u:1 Page arrives Page arrives ccess Page arrives Page arrives ccess F u: Page 12

13 lock Replacement Illustration lock lgorithm: iscussion Max table size 4 Invariant: point at oldest What if hand moving slowly? Good sign or bad sign?» Not many faults and/or find quickly Page arrives Page arrives ccess Page arrives Page arrives ccess Page E arrives E F u:1 u:1 What if hand is moving quickly? Lots of faults and/or lots of reference bits set N th hance version of lock lgorithm N th chance algorithm: Give N chances OS keeps counter per : # sweeps On fault, OS checks use bit:»1 clear use and also clear counter (used in last sweep)»0 increment counter; if count=n, replace Means that clock hand has to sweep by N times without being used before is replaced How do we pick N? Why pick large N? etter approx to LRU» If N ~ 1K, really good approximation Why pick small N? More efficient» Otherwise might have to look a long way to find free What about dirty s? Takes extra overhead to replace a dirty, so give dirty s an extra chance before replacing? ommon approach:» lean s, use N=1» irty s, use N=2 (and write back to disk when N=1) Quiz 11.3: emand Paging Q1: True _ False _ emand paging incurs conflict misses Q2: True _ False _ LRU can never achieve higher hit rate than MIN Q3: True _ False _ The LRU miss rate may increase as the cache size increases Q4: True _ False _ The lock algorithm is a simpler implementation of the Second hance algorithm Q5: ssume a cache with 100 s. The number of s that the Second hance algorithm may need to check before finding a to evict is at most Page 13

14 Quiz 11.3: emand Paging Q1: True _ False _ X emand paging incurs conflict misses Q2: True _ X False _ LRU can never achieve higher hit rate than MIN Q3: True _ False _ X The LRU miss rate may increase as the cache size increases Q4: True _ X False _ The lock algorithm is a simpler implementation of the Second hance algorithm Q5: ssume a cache with 100 s. The number of s that the Second hance algorithm may need to check before finding a to evict is at most Summary (1/2) emand Paging: Treat memory as cache on disk ache miss find free, get from disk Transparent Level of Indirection User program is unaware of activities of OS behind scenes ata can be moved without affecting application correctness Replacement policies FIFO: Place s on queue, replace at head» Fair but can eject in-use s, suffers from elady s anomaly MIN: Replace that will be used farthest in future» enchmark for comparisons, can t implement in practice LRU: Replace used farthest in past» For efficiency, use approximation Summary (2/2) lock lgorithm: pproximation to LRU rrange all s in circular list Sweep through them, marking as not in use If not in use for one pass, than can replace Page 14