1. Copyright ©: Nahrstedt, Angrave, Abdelzaher1 Memory

2. Copyright ©: Nahrstedt, Angrave, Abdelzaher 2 Memory Allocation Compile for overlays Compile for fixed Partitions Separate queue per partition Single queue Relocation and variable partitions Dynamic contiguous allocation (bit maps versus linked lists) Fragmentation issues Swapping Paging

3. Copyright ©: Nahrstedt, Angrave, Abdelzaher 3 Overlays Overlay Manager Overlay Area Main Program Overlay 1 Overlay 2 Overlay 3 Secondary Storage Overlay 1Overlay 2Overlay 3Overlay 1 0K 5k 7k 12k

4. Copyright ©: Nahrstedt, Angrave, Abdelzaher 4 Multiprogramming with Fixed Partitions Divide memory into n (possible unequal) partitions. Problem: Fragmentation Free Space 0k 4k 16k 64k 128k

5. Copyright ©: Nahrstedt, Angrave, Abdelzaher 5 Fixed Partitions Legend Free Space 0k 4k 16k 64k 128k Internal fragmentation (cannot be reallocated)

6. Copyright ©: Nahrstedt, Angrave, Abdelzaher 6 Fixed Partition Allocation Implementation Issues Separate input queue for each partition Requires sorting the incoming jobs and putting them into separate queues Inefficient utilization of memory when the queue for a large partition is empty but the queue for a small partition is full. Small jobs have to wait to get into memory even though plenty of memory is free. One single input queue for all partitions. Allocate a partition where the job fits in. Best Fit Worst Fit First Fit

7. Copyright ©: Nahrstedt, Angrave, Abdelzaher 7 Relocation Correct starting address when a program starts in memory Different jobs will run at different addresses When a program is linked, the linker must know at what address the program will begin in memory. Logical addresses, Virtual addresses Logical address space, range (0 to max) Physical addresses, Physical address space range (R+0 to R+max) for base value R. User program never sees the real physical addresses Memory-management unit (MMU) map virtual to physical addresses. Relocation register Mapping requires hardware (MMU) with the base register

8. Copyright ©: Nahrstedt, Angrave, Abdelzaher 8 Relocation Register Memory Base Register CPU Instruction Address + BA MA MA+BA Physical Address Logical Address

9. Copyright ©: Nahrstedt, Angrave, Abdelzaher 9 Question 1 - Protection Problem: How to prevent a malicious process to write or jump into other user's or OS partitions Solution: Base bounds registers

10. Copyright ©: Nahrstedt, Angrave, Abdelzaher 10 Base Bounds Registers Memory Bounds RegisterBase Register CPU Address <+ Memory Address MA Logical Address LA Physical Address PA Fault Base Address Limit Address MA+BA Base Address BA

11. Copyright ©: Nahrstedt, Angrave, Abdelzaher 11 Contiguous Allocation and Variable Partitions: Bit Maps versus Linked Lists Part of memory with 5 processes, 3 holes tick marks show allocation units shaded regions are free Corresponding bit map

12. Copyright ©: Nahrstedt, Angrave, Abdelzaher 12 More on Memory Management with Linked Lists Four neighbor combinations for the terminating process X

13. Copyright ©: Nahrstedt, Angrave, Abdelzaher 13 Contiguous Variable Partition Allocation schemes Bitmap and link list Which one occupies more space? Depending on the individual memory allocation scenario. In most cases, bitmap usually occupies more space. Which one is faster reclaim freed space? On average, bitmap is faster because it just needs to set the corresponding bits Which one is faster to find a free hole? On average, a link list is faster because we can link all free holes together

14. Copyright ©: Nahrstedt, Angrave, Abdelzaher 14 Storage Placement Strategies Best fit Use the hole whose size is equal to the need, or if none is equal, the whole that is larger but closest in size. Rationale? First fit Use the first available hole whose size is sufficient to meet the need Rationale? Worst fit Use the largest available hole Rationale?

15. Copyright ©: Nahrstedt, Angrave, Abdelzaher 15 Storage Placement Strategies Every placement strategy has its own problem Best fit Creates small holes that cant be used Worst Fit Gets rid of large holes making it difficult to run large programs First Fit Creates average size holes

16. Copyright ©: Nahrstedt, Angrave, Abdelzaher 16 How Bad Is Fragmentation? Statistical arguments - Random sizes First-fit Given N allocated blocks 0.5  N blocks will be lost because of fragmentation Known as 50% RULE

17. Copyright ©: Nahrstedt, Angrave, Abdelzaher 17 Solve Fragmentation w. Compaction MonitorJob 3 Free Job 5Job 6Job 7Job 8 5 MonitorJob 3 Free Job 5Job 6Job 7Job 8 6 MonitorJob 3 Free Job 5Job 6Job 7Job 8 7 MonitorJob 3 Free Job 5Job 6Job 7Job 8 8 MonitorJob 3 Free Job 5Job 6Job 7Job 8 9

18. Copyright ©: Nahrstedt, Angrave, Abdelzaher 18 Storage Management Problems Fixed partitions suffer from internal fragmentation Variable partitions suffer from external fragmentation Compaction suffers from overhead

19. Copyright ©: Nahrstedt, Angrave, Abdelzaher 19 Question What if there are more processes than what could fit into the memory?

20. Copyright ©: Nahrstedt, Angrave, Abdelzaher 20 Swapping Monitor Disk User Partition

21. Copyright ©: Nahrstedt, Angrave, Abdelzaher 21 Swapping Monitor Disk User 1 User Partition

22. Copyright ©: Nahrstedt, Angrave, Abdelzaher 22 Swapping Monitor User 1 Disk User 1 User Partition

23. Copyright ©: Nahrstedt, Angrave, Abdelzaher 23 Swapping Monitor User 2 User 1 Disk User 1 User Partition

24. Copyright ©: Nahrstedt, Angrave, Abdelzaher 24 Swapping Monitor Disk User 2 User Partition User 1

25. Copyright ©: Nahrstedt, Angrave, Abdelzaher 25 Swapping Monitor Disk User 2 User Partition User 1

26. Copyright ©: Nahrstedt, Angrave, Abdelzaher 26 Swapping Monitor Disk User 1 User 2 User Partition User 1

27. Copyright ©: Nahrstedt, Angrave, Abdelzaher 27 Paging Provide user with virtual memory that is as big as user needs Store virtual memory on disk Cache parts of virtual memory being used in real memory Load and store cached virtual memory without user program intervention

28. Copyright ©: Nahrstedt, Angrave, Abdelzaher 28 Benefits of Virtual Memory Use secondary storage($) Extend DRAM($$$) with reasonable performance Protection Programs do not step over each other Convenience Flat address space Programs have the same view of the world Load and store cached virtual memory without user program intervention Reduce fragmentation: make cacheable units all the same size (page) Remove memory deadlock possibilities: permit pre-emption of real memory

29. Copyright ©: Nahrstedt, Angrave, Abdelzaher 29 Paging Request 31 2 3 4 Disk Cache Virtual Memory Stored on Disk 12345678 1234 1 2 3 4 Page Table VMFrame Real Memory Request Address within Virtual Memory Page 3

30. Copyright ©: Nahrstedt, Angrave, Abdelzaher 30 Paging 31 12 3 4 Disk Cache Virtual Memory Stored on Disk 1234567 8 1234 1 2 3 4 Page Table VMFrame Real Memory Request Address within Virtual Memory Page 1

31. Copyright ©: Nahrstedt, Angrave, Abdelzaher 31 Paging 31 1 6 2 3 4 Disk Cache Virtual Memory Stored on Disk 12345678 1234 1 2 3 4 Page Table VMFrame Real Memory Request Address within Virtual Memory Page 6

32. Copyright ©: Nahrstedt, Angrave, Abdelzaher 32 Paging 31 1 6 2 3 4 Disk Cache Virtual Memory Stored on Disk 12345678 1234 1 2 3 4 Page Table VMFrame Real Memory Request Address within Virtual Memory Page 2 2

33. Copyright ©: Nahrstedt, Angrave, Abdelzaher 33 Paging 31 1 6 2 3 4 Disk Cache Virtual Memory Stored on Disk 12345678 1234 1 2 3 4 Page Table VMFrame Real Memory Store Virtual Memory Page 1 to disk 2 Request Address within Virtual Memory 8

34. Copyright ©: Nahrstedt, Angrave, Abdelzaher 34 Paging 31 6 2 3 4 Disk Cache Virtual Memory Stored on Disk 12345678 1234 1 2 3 4 Page Table VM Frame Real Memory 2 Load Virtual Memory Page 8 to cache 8

35. Copyright ©: Nahrstedt, Angrave, Abdelzaher 35 Page Mapping Hardware Contents(P,D) Contents(F,D) PD FD P-> F 0 1 0 1 1 0 1 Page Table Virtual Memory Physical Memory Virtual Address (P,D) Physical Address (F,D) P F D D P

36. Copyright ©: Nahrstedt, Angrave, Abdelzaher 36 Page Mapping Hardware Contents(4006) Contents(5006) 004006 005006 4-> 5 0 1 0 1 1 0 1 Page Table Virtual Memory Physical Memory Virtual Address (004006) Physical Address (F,D) 004 005 006 4

37. Copyright ©: Nahrstedt, Angrave, Abdelzaher 37 Paging Issues size of page is 2 n, usually 512, 1k, 2k, 4k, or 8k E.g. 32 bit VM address may have 2 20 (1 meg) pages with 4k (2 12 ) bytes per page Rational?

38. Copyright ©: Nahrstedt, Angrave, Abdelzaher 38 Paging Issues 2 20 (1 meg) 32 bit page entries take 2 22 bytes (4 meg) page frames must map into real memory

39. Copyright ©: Nahrstedt, Angrave, Abdelzaher 39 Paging Issues Question Physical memory size: 32 MB (2^25 ) Page size 4K bytes How many pages? 2^13 Page Table base register must be changed for context switch Why? Different page table NO external fragmentation Internal fragmentation on last page ONLY

40. Copyright ©: Nahrstedt, Angrave, Abdelzaher 40 Paging - Caching the Page Table Can cache page table in registers and keep page table in memory at location given by a page table base register Page table base register changed at context switch time

41. Copyright ©: Nahrstedt, Angrave, Abdelzaher 41 Paging Implementation Issues Caching scheme can use associative registers, look-aside memory or content-addressable memory TLB Page address cache (TLB) hit ratio: percentage of time page found in associative memory If not found in associative memory, must load from page tables: requires additional memory reference

42. Copyright ©: Nahrstedt, Angrave, Abdelzaher 42 Page Mapping Hardware PD FD P-> F 0 1 0 1 1 0 1 Page Table Virtual Memory Address (P,D) Physical Address (F,D) P Associative Look Up PF First

43. Copyright ©: Nahrstedt, Angrave, Abdelzaher 43 Page Mapping Hardware 004006 009006 004-> 009 0 1 0 1 1 0 1 Page Table Virtual Memory Address (P,D) Physical Address (F,D) 4 Associative Look Up 112 7 19 3 6 3 7 First Table organized by LRU 49

44. Copyright ©: Nahrstedt, Angrave, Abdelzaher 44 Page Mapping Hardware 004006 009006 004-> 009 0 1 0 1 1 0 1 Page Table Virtual Memory Address (P,D) Physical Address (F,D) 4 Associative Look Up 112 4 19 3 9 3 7 First Table organized by LRU