1. 1 CMSC421: Principles of Operating Systems Nilanjan Banerjee Principles of Operating Systems Acknowledgments: Some of the slides are adapted from Prof. Mark Corner and Prof. Emery Berger’s OS course at Umass Amherst Assistant Professor, University of Maryland Baltimore County nilanb@umbc.edu http://www.csee.umbc.edu/~nilanb/teaching/421/

2. 2 Announcements Project 2 progress report due one week from Nov. 9th

3. 3 Coalescing kernel Text region stack free allocated malloc(200) brk

4. 4 Jobs of a memory allocator like malloc  Manage heap space in virtual memory –Use sbrk to ask for more memory from OS  Coalescing  Keep track of free blocks  Merge them together when adjacent blocks are free  Malloc needs to be really fast  Decide which free block to allocate  Lets take a look at the data structure that is used for implementing malloc and free

5. 5 Memory layout of the heap http://gee.cs.oswego.edu/dl/html/malloc.html this linked list can be ordered in different ways

6. 6 Selecting the free block to allocate: Fragmentation Intuitively, fragmentation stems from “breaking” up heap into unusable spaces –More fragmentation = worse utilization External fragmentation –Wasted space outside allocated objects Internal fragmentation –Wasted space inside an object

7. 7 Classical Algorithms First-fit –find first chunk of desired size

8. 8 Classical Algorithms Best-fit –find chunk that fits best Minimizes wasted space

9. 9 Classical Algorithms Worst-fit –find chunk that fits worst –name is a misnomer! –keeps large holes around Reclaim space: coalesce free adjacent objects into one big object

10. char * x = new char[16]; 10 virtual memory layout Allocate some memory 0x40001000 0x40001040 → 0x4000104F A Day in the Life of a Page

11. char * x = new char[16]; 11 virtual memory layout Update page tables 0x40001000 0x40001040 → 0x4000104F physical memory layout A Day in the Life of a Page

12. strcpy(x, “hello”); 12 virtual memory layout Write contents – dirty page 0x40001000 0x40001040 → 0x4000104F physical memory layout A Day in the Life of a Page

13. 13 virtual memory layout Other processes fill up memory… physical memory layout A Day in the Life of a Page

14. 14 virtual memory layout Forcing our page to be evicted (paged out) physical memory layout swap space (disk) A Day in the Life of a Page

15. 15 virtual memory layout Now page nonresident & protected physical memory layout swap space (disk) A Day in the Life of a Page

16. y[0] = x[0]; 16 virtual memory layout Touch page – swap it in 0x40001000 0x40001040 → 0x4000104F physical memory layout swap space (disk) A Day in the Life of a Page

17. y[0] = x[0]; 17 virtual memory layout Touch page – swap it in 0x40001000 0x40001040 → 0x4000104F physical memory layout swap space (disk) A Day in the Life of a Page

18. 18 Talked about malloc? What about physical frame mgmt?  malloc works in virtual memory (works in user space) –Manages free blocks –Allocates virtual address on the heap  Remember the OS still has to manage physical frames  The problem that the OS faces with physical frame allocation is the similar to malloc  Manage physical frames that all processes in the system requests.  Difference with malloc  Has to work across all processes  Each process perceives 4GB of space, but in actuality there is only 4GB of physical memory space

19. 19 Tasks of the OS physical page management unit  Allocate new pages to applications –OS do this lazily –malloc call would usually return immediately –OS allocates a new physical only when the process reads/writes to the page –Similar to the Copy-on-Write policy for fork()  In the event that all physical frames are taken  OS needs to evict pages  Take page from main memory and store it on swap space  Needs a policy for evicting pages

20. 20 Page replacement policy for Demand Paging? What is the optimal page replacement policy?

21. 21 Optimal Page Replacement policy  Find the page that is going to used farthest into the future –Evict the page from main memory to swap space –Allocate the freed page to the new process –Problems: it is impossible to predict the future  Approximation is LRU (least recently used page)  Find the page that is least recently used and evict it  Remember this has to be super-fast  What would be techniques to implement this in the kernel?

22. 22 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

23. 23 A1A1 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

24. 24 A1A1 B2B2 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

25. 25 A1A1 B2B2 C3C3 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

26. 26 A1A1 B4B4 C3C3 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

27. 27 A1A1 B4B4 C5C5 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

28. 28 A1A1 B4B4 C6C6 A, B, C, B, C, C, D Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used

29. 29 A, B, C, B, C, C D, A1A1 B4B4 C6C6 D7D7 LRU page How should we implement this? Implementing Exact LRU On each reference, time stamp page When we need to evict: select oldest page = least-recently used A0A0

30. 30 Implementing Exact LRU Could keep pages in order – optimizes eviction –Priority queue: update = O(log n), eviction = O(log n) Optimize for common case! –Common case: hits, not misses –Hash table: update = O(1), eviction = O(n)

31. 31 Cost of Maintaining Exact LRU Hash tables: too expensive –On every reference: Compute hash of page address Update time stamp

32. 32 Cost of Maintaining Exact LRU Alternative: doubly-linked list –Move items to front when referenced –LRU items at end of list –Still too expensive 4-6 pointer updates per reference Can we do better?

33. 33 A1A1 B1B1 C1C1 A, B, C, B, C, C, D Hardware Support and approximate LRU (Linux Kernel) Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits

34. 34 A0A0 B0B0 C0C0 A, B, C, B, C, C, D reset reference bits Hardware Support Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits

35. 35 A0A0 B1B1 C0C0 A, B, C, B, C, C, D Hardware Support Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits

36. 36 A0A0 B1B1 C1C1 A, B, C, B, C, C, D Hardware Support Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits

37. 37 A0A0 B1B1 C1C1 A, B, C, B, C, C, D Hardware Support Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits

38. 38 A0A0 A, B, C, B, C, C, D B1B1 C1C1 D1D1 Hardware Support Maintain reference bits for every page –On each access, set reference bit to 1 –Page replacement algorithm periodically resets reference bits –Evict page with reference bit = 0 Cost per miss = O(n)

39. 39 A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case:

40. 40 A A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

41. 41 AB A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

42. 42 ABC A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

43. 43 ABD A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

44. 44 ABD A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

45. 45 ABD A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

46. 46 ABD A, B, C, D, A, B, C, D,... size of available memory Most-Recently Used (MRU) Evict most-recently used page Shines for LRU’s worst-case: loop that exceeds RAM size

47. 47 FIFO First-in, first-out: evict oldest page As competitive as LRU, but performs miserably in practice! –Ignores locality –Suffers from Belady’s anomaly: More memory can mean more paging! –LRU & similar algs. do not Stack algorithms – more memory means ≥ hits

48. 48 Tricks with Page Tables: Sharing Paging allows sharing of memory across processes –Reduces memory requirements Shared stuff includes code, data –Code typically R/O

49. Tricks with Page Tables: COW Copy on write (COW) –Just copy page tables –Make all pages read-only What if process changes mem? All processes are created this way!

50. 50 In-class Discussion