CS 241 Section Week 9 (04/09/09)

1
CS 241 Section Week 9(04/09/09)
2
Topics

• LMP2 Overview
• Memory Management
• Virtual Memory
• Page Tables

3
LMP2 Overview
4
LMP2 Overview

• LMP2 attempts to encode or decode a number of
  files the following way
• encode gt ./mmap -e -b16 file1 file2 ...
• decode gt ./mmap -d -b8 file1 file2 ...
• It has the following parameters
• It reads whether it has to encode (-e) or
  decode(-d)
• the number of bytes (rw_units) for each
  read/write from the file

5
LMP1 Overview

• You have TWO weeks to complete and submit LMP2.
  We have divided LMP2 into two stages
• Stage 1
• Implement a simple virtual memory.
• It is recommended you implement the my_mmap()
  function during this week.
• You will need to complete various data structures
  to deal with the file mapping table, the page
  table, the physical memory, etc.

6
LMP1 Overview

• You have TWO weeks to complete and submit LMP2.
  We have divided LMP2 into two stages
• Stage 2
• Implement various functions for memory mapped
  files including
• my_mread() , my_mwrite() and my_munmap()
• Handle page faults in your my_mread() and
  my_mwrite() functions
• Implement two simple manipulations on files
• encoding
• decoding

7
Memory Management
8
Memory

• Contiguous allocation and compaction
• Paging and page replacement algorithms

9
Fragmentation

• External Fragmentation
• Free space becomes divided into many small pieces
• Caused over time by allocating and freeing the
  storage of different sizes
• Internal Fragmentation
• Result of reserving space without ever using its
  part
• Caused by allocating fixed size of storage

10
Contiguous Allocation

• Memory is allocated in monolithic segments or
  blocks
• Public enemy 1 external fragmentation
• We can solve this by periodically rearranging the
  contents of memory

11
Storage Placement Algorithms

• Best Fit
• Produces the smallest leftover hole
• Creates small holes that cannot be used

12
Storage Placement Algorithms

• Best Fit
• Produces the smallest leftover hole
• Creates small holes that cannot be used
• First Fit
• Creates average size holes

13
Storage Placement Algorithms

• Best Fit
• Produces the smallest leftover hole
• Creates small holes that cannot be used
• First Fit
• Creates average size holes
• Worst Fit
• Produces the largest leftover hole
• Difficult to run large programs

14
Storage Placement Algorithms

• Best Fit
• Produces the smallest leftover hole
• Creates small holes that cannot be used
• First Fit
• Creates average size holes
• Worst Fit
• Produces the largest leftover hole
• Difficult to run large programs
• First-Fit and Best-Fit are better than Worst-Fit
  in terms of SPEED and STORAGE UTILIZATION

15
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit?

16
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit? 20KB, 10KB and 18KB

17
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit? 20KB, 10KB and 18KB
• Best Fit?

18
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit? 20KB, 10KB and 18KB
• Best Fit? 12KB, 10KB and 9KB

19
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit? 20KB, 10KB and 18KB
• Best Fit? 12KB, 10KB and 9KB
• Worst Fit?

20
Exercise

• Consider a swapping system in which memory
  consists of the following hole sizes in memory
  order 10KB, 4KB, 20KB, 18KB, 7KB, 9KB, 12KB, and
  15KB. Which hole is taken for successive segment
  requests of (a) 12KB, (b) 10KB, (c) 9KB for
• First Fit? 20KB, 10KB and 18KB
• Best Fit? 12KB, 10KB and 9KB
• Worst Fit? 20KB, 18KB and 15KB

21
malloc Revisited

• Free storage is kept as a list of free blocks
• Each block contains a size, a pointer to the next
  block, and the space itself

22
malloc Revisited

• Free storage is kept as a list of free blocks
• Each block contains a size, a pointer to the next
  block, and the space itself
• When a request for space is made, the free list
  is scanned until a big-enough block can be found
• Which storage placement algorithm is used?

23
malloc Revisited

• Free storage is kept as a list of free blocks
• Each block contains a size, a pointer to the next
  block, and the space itself
• When a request for space is made, the free list
  is scanned until a big-enough block can be found
• Which storage placement algorithm is used?
• If the block is found, return it and adjust the
  free list. Otherwise, another large chunk is
  obtained from the OS and linked into the free list

24
malloc Revisited (continued)

• typedef long Align / for alignment to long /
• union header / block header /
• struct
• union header ptr / next block if on free
  list /
• unsigned size / size of this block /
• s
• Align x / force alignment of blocks /
• typedef union header Header

25
Compaction

• After numerous malloc() and free() calls, our
  memory will have many holes
• Total free memory is much greater than that of
  any contiguous chunk
• We can compact our allocated memory
• Shift all allocations to one end of memory, and
  all holes to the other end
• Temporarily eliminates of external fragmentation

26
Compaction (example)

• Lucky that A fit in there! To be sure that there
  is enough space, we may want to compact at (d),
  (e), or (f)
• Unfortunately, compaction is problematic
• It is very costly. How much, exactly?
• How else can we eliminate external fragmentation?

27
Paging

• Divide memory into pages of equal size
• We dont need to assign contiguous chunks
• Internal fragmentation can only occur on the last
  page assigned to a process
• External fragmentation cannot occur at all
• Need to map contiguous logical memory addresses
  to disjoint pages

28
Page Replacement

• We may not have enough space in physical memory
  for all pages of every process at the same time.
• But which pages shall we keep?
• Use the history of page accesses to decide
• Also useful to know the dirty pages

29
Page Replacement Strategies

• It takes two disk operations to replace a dirty
  page, so
• Keep track of dirty bits, attempt to replace
  clean pages first
• Write dirty pages to disk during idle disk time
• We try to approximate the optimal strategy but
  can seldom achieve it, because we dont know what
  order a process will use its pages.
• Best we can do is run a program multiple times,
  and track which pages it accesses

30
Page Replacement Algorithms

• Optimal last page to be used in the future is
  removed first
• FIFO First in First Out
• Based on time the page has spent in main memory
• LRU Least Recently Used
• Locality of reference principle again
• MRU most recently used removed first
• When would this be useful?
• LFU Least Frequently Used
• Replace the page that is used least often

31
Example

• Physical memory size 4 pages
• Pages are loaded on demand
• Access history 0 1 2 3 4 0 1 2 3 4
• Which algorithm does best here?
• Access history 0 1 2 3 4 4 3 2 1 0
• And here?

32
Virtual Memory
33
Why Virtual Memory?

• Use main memory as a Cache for the Disk
• Address space of a process can exceed physical
  memory size
• Sum of address spaces of multiple processes can
  exceed physical memory

34
Why Virtual Memory?

• Use main memory as a Cache for the Disk
• Address space of a process can exceed physical
  memory size
• Sum of address spaces of multiple processes can
  exceed physical memory
• Simplify Memory Management
• Multiple processes resident in main memory.
• Each process with its own address space
• Only active code and data is actually in memory

35
Why Virtual Memory?

• Use main memory as a Cache for the Disk
• Address space of a process can exceed physical
  memory size
• Sum of address spaces of multiple processes can
  exceed physical memory
• Simplify Memory Management
• Multiple processes resident in main memory.
• Each process with its own address space
• Only active code and data is actually in memory
• Provide Protection
• One process cant interfere with another.
• because they operate in different address spaces.
• User process cannot access privileged information
• different sections of address spaces have
  different permissions.

36
Principle of Locality

• Program and data references within a process tend
  to cluster

37
Principle of Locality

• Program and data references within a process tend
  to cluster
• Only a few pieces of a process will be needed
  over a short period of time (active data or code)

38
Principle of Locality

• Program and data references within a process tend
  to cluster
• Only a few pieces of a process will be needed
  over a short period of time (active data or code)
• Possible to make intelligent guesses about which
  pieces will be needed in the future

39
Principle of Locality

• Program and data references within a process tend
  to cluster
• Only a few pieces of a process will be needed
  over a short period of time (active data or code)
• Possible to make intelligent guesses about which
  pieces will be needed in the future
• This suggests that virtual memory may work
  efficiently

40
VM Address Translation

• Parameters
• P 2p page size (bytes).
• N 2n Virtual address limit
• M 2m Physical address limit

41
Page Table

• Keeps track of what pages are in memory

42
Page Table

• Keeps track of what pages are in memory
• Provides a mapping from virtual address to
  physical address

43
Handling a Page Fault

• Page fault
• Look for an empty page in RAM
• May need to write a page to disk and free it

44
Handling a Page Fault

• Page fault
• Look for an empty page in RAM
• May need to write a page to disk and free it
• Load the faulted page into that empty page

45
Handling a Page Fault

• Page fault
• Look for an empty page in RAM
• May need to write a page to disk and free it
• Load the faulted page into that empty page
• Modify the page table

46
Addressing

• 64MB RAM (226)

47
Addressing

• 64MB RAM (226)
• 231 (2GB) total memory

Virtual Address (31 bits)
48
Addressing

• 64MB RAM (226)
• 231 (2GB) total memory
• 4KB page size (212)

Virtual Address (31 bits)
49
Addressing

• 64MB RAM (226)
• 231 (2GB) total memory
• 4KB page size (212)
• So we need 212 for the offset, we can use the
  remainder bits for the page

Virtual Address (31 bits)
Virtual Page number (19 bits)
Page offset (12 bits)
50
Addressing

• 64MB RAM (226)
• 231 (2GB) total memory
• 4KB page size (212)
• So we need 212 for the offset, we can use the
  remainder bits for the page
• 19 bits, we have 219 pages (524288 pages)

Virtual Address (31 bits)
Virtual Page number (19 bits)
Page offset (12 bits)
51
Address Conversion

• That 19bit page address can be optimized in a
  variety of ways
• Translation Look-aside Buffer

52
Translation Lookaside Buffer (TLB)

• Each virtual memory reference can cause two
  physical memory accesses
• One to fetch the page table
• One to fetch the data

53
Translation Lookaside Buffer (TLB)

• Each virtual memory reference can cause two
  physical memory accesses
• One to fetch the page table
• One to fetch the data
• To overcome this problem a high-speed cache is
  set up for page table entries

54
Translation Lookaside Buffer (TLB)

• Each virtual memory reference can cause two
  physical memory accesses
• One to fetch the page table
• One to fetch the data
• To overcome this problem a high-speed cache is
  set up for page table entries
• Contains page table entries that have been most
  recently used (a cache for page table)

55
Translation Lookaside Buffer (TLB)
56
Address Conversion

• That 19bit page address can be optimized in a
  variety of ways
• Translation Look-aside Buffer
• Multilevel Page Table

57
Multilevel Page Tables

• Given
• 4KB (212) page size
• 32-bit address space
• 4-byte PTE

58
Multilevel Page Tables

• Given
• 4KB (212) page size
• 32-bit address space
• 4-byte PTE
• Problem
• Would need a 4 MB page table!
• 220 4 bytes

59
Multilevel Page Tables

• Given
• 4KB (212) page size
• 32-bit address space
• 4-byte PTE
• Problem
• Would need a 4 MB page table!
• 220 4 bytes
• Common solution
• multi-level page tables
• e.g., 2-level table (P6)
• Level 1 table 1024 entries, each of which points
  to a Level 2 page table.
• Level 2 table 1024 entries, each of which
  points to a page

60
Summary Multi-level Page Tables

• Instead of one large table, keep a tree of tables
• Top-level table stores pointers to lower level
  page tables
• First n bits of the page number index of the
  top-level page table
• Second n bits index of the 2nd-level page
  table
• Etc.

61
Example Two-level Page Table

• 32-bit address space (2GB)

62
Example Two-level Page Table

• 32-bit address space (2GB)
• 12-bit page offset (4kB pages)

63
Example Two-level Page Table

• 32-bit address space (2GB)
• 12-bit page offset (4kB pages)
• 20-bit page address
• First 10 bits index the top-level page table
• Second 10 bits index the 2nd-level page table
• 10 bits 1024 entries 4 bytes 4kB 1
  page

64
Example Two-level Page Table

• 32-bit address space (2GB)
• 12-bit page offset (4kB pages)
• 20-bit page address
• First 10 bits index the top-level page table
• Second 10 bits index the 2nd-level page table
• 10 bits 1024 entries 4 bytes 4kB 1
  page
• Need three memory accesses to read a memory
  location

65
Why use multi-level page tables?

• Split one large page table into many page-sized
  chunks
• Typically 4 or 8 MB for a 32-bit address space

66
Why use multi-level page tables?

• Split one large page table into many page-sized
  chunks
• Typically 4 or 8 MB for a 32-bit address space
• Advantage less memory must be reserved for the
  page tables
• Can swap out unused or not recently used tables

67
Why use multi-level page tables?

• Split one large page table into many page-sized
  chunks
• Typically 4 or 8 MB for a 32-bit address space
• Advantage less memory must be reserved for the
  page tables
• Can swap out unused or not recently used tables
• Disadvantage increased access time on TLB miss
• n1 memory accesses for n-level page tables

68
Address Conversion

• That 19bit page address can be optimized in a
  variety of ways
• Translation Look-aside Buffer
• Multilevel Page Table
• Inverted Page Table

69
Inverted Page Table

• Normal page table
• Virtual page number index
• Physical page number value

70
Inverted Page Table

• Normal page table
• Virtual page number index
• Physical page number value
• Inverted page table
• Virtual page number value
• Physical page number index

71
Inverted Page Table

• Normal page table
• Virtual page number index
• Physical page number value
• Inverted page table
• Virtual page number value
• Physical page number index
• Need to scan the table for the right value to
  find the index
• More efficient way use a hash table

72
Example
Virtual Address (1010110)
73
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
74
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
1010
75
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
1010
76
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
Index 4 (100)
1010
77
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
Index 4 (100)
78
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
Index 4 (100)
79
Example
Page Table
Virtual Address (1010110)
Index Present Virtual Addr
Index 4 (100)
Physical Address (100110)
80
Why use inverted page tables?

• One entry for each page of physical memory
• vs. one per page of logical address space

81
Why use inverted page tables?

• One entry for each page of physical memory
• vs. one per page of logical address space
• Advantage less memory needed to store the page
  table
• If address space gtgt physical memory

82
Why use inverted page tables?

• One entry for each page of physical memory
• vs. one per page of logical address space
• Advantage less memory needed to store the page
  table
• If address space gtgt physical memory
• Disadvantage increased access time on TLB miss
• Use a hash table to limit the search to one or
  at most a few extra memory accesses

83
Summary Address Conversion

• That 19bit page address can be optimized in a
  variety of ways
• Translation Look-aside Buffer
• m memory cycle, ? - hit ratio, ? - TLB lookup
  time
• Effective access time (Eat)
• Eat (m ?)????(2m ?)(1 ?) 2m ?  m?
• Multilevel Page Table
• Similar to indirect pointers in I-nodes
• Split the 19bits into multiple sections
• Inverted Page Table
• Much smaller, but is slower and more difficult to
  lookup

84
Summary Page Tables

• 64kB logical address space
• 8 pages 4kB 32kB RAM
• 16-bit virtual address consists of
• Page number (4 bits)
• Page offset (12 bits)
• Virtual page number table index
• Physical frame number value
• Present bit is page in memory?

85
Summary Virtual Memory

• RAM is expensive (but fast), disk is cheap (but
  slow)
• Need to find a way to use the cheaper memory
• Store memory that isnt frequently used on disk
• Swap pages between disk and memory as needed
• Treat main memory as a cache for pages on disk