1 00:00:00,570 --> 00:00:05,840 Virtual memory allows programs to behave as if they have a larger memory than they actually 2 00:00:05,840 --> 00:00:06,900 do. 3 00:00:06,900 --> 00:00:14,049 The way this works is by using virtual addresses, which refer to addresses on disk, in our programs. 4 00:00:14,049 --> 00:00:18,910 The virtual addresses are translated into physical addresses using the page map which 5 00:00:18,910 --> 00:00:23,589 is a lookup table that has one entry per virtual page. 6 00:00:23,589 --> 00:00:29,099 The page map knows whether the virtual page is in physical memory and if so it immediately 7 00:00:29,099 --> 00:00:31,939 returns the physical page number. 8 00:00:31,939 --> 00:00:36,940 If the page is not in physical memory, then this causes a fault which means that the virtual 9 00:00:36,940 --> 00:00:42,370 page must be brought in from disk to physical memory before it can be accessed. 10 00:00:42,370 --> 00:00:48,500 To do this the least recently used (LRU) page in the physical memory is removed to make 11 00:00:48,500 --> 00:00:52,579 room for the address that is currently being requested. 12 00:00:52,579 --> 00:00:58,110 The page map is also updated with the new mapping of virtual to physical pages. 13 00:00:58,110 --> 00:01:03,420 Since bringing data to and from disk is an expensive operation, data is moved in chunks. 14 00:01:03,420 --> 00:01:09,210 This makes sense because of the concept of locality which we studied as part of our Caches 15 00:01:09,210 --> 00:01:10,210 unit. 16 00:01:10,210 --> 00:01:15,370 The idea is that instructions, or data, that are close to the current address are likely 17 00:01:15,370 --> 00:01:22,030 to be accessed as well, so it makes sense to fetch more than one word of data at a time. 18 00:01:22,030 --> 00:01:26,380 This is especially true if the cost of fetching the first word is significantly higher than 19 00:01:26,380 --> 00:01:33,110 the cost of fetching adjacent memory locations as is the case with accesses to disk. 20 00:01:33,110 --> 00:01:37,200 So data is moved back and forth from disk in pages. 21 00:01:37,200 --> 00:01:41,950 The size of a page is the same in both virtual and physical memory. 22 00:01:41,950 --> 00:01:46,119 Lets look at an example of how virtual memory is used. 23 00:01:46,119 --> 00:01:50,860 While it is usually the case that the virtual address space is larger than the physical 24 00:01:50,860 --> 00:01:55,460 address space, this is not a requirement and in this problem the virtual address space 25 00:01:55,460 --> 00:01:59,720 happens to be smaller than the physical address space. 26 00:01:59,720 --> 00:02:07,280 Specifically, virtual addresses are 16 bits long so they can address 2^16 bytes. 27 00:02:07,280 --> 00:02:12,110 Physical addresses are 20 bits long so that means that our physical memory is of size 28 00:02:12,110 --> 00:02:14,910 2^20 bytes. 29 00:02:14,910 --> 00:02:20,790 Our page size is 2^8 bytes or 256 bytes per page. 30 00:02:20,790 --> 00:02:26,730 This means that the 16 bit virtual address consists of 8 bits of page offset and another 31 00:02:26,730 --> 00:02:29,320 8 bits for the virtual page number (or VPN). 32 00:02:29,320 --> 00:02:36,730 The 20 bit physical address consists of the same 8 bit page offset and another 12 bits 33 00:02:36,730 --> 00:02:39,000 for the physical page number (or PPN). 34 00:02:39,000 --> 00:02:46,450 The first question we want to consider is what is the size of the page map in this example? 35 00:02:46,450 --> 00:02:52,000 Recall that a page map has 1 entry per virtual page in order to map each virtual page to 36 00:02:52,000 --> 00:02:54,220 a physical page. 37 00:02:54,220 --> 00:03:00,500 This means that the number of entries in the page map is 2^8 where 8 is the number of bits 38 00:03:00,500 --> 00:03:02,230 in the VPN. 39 00:03:02,230 --> 00:03:10,060 The size of each page map entry is 14 bits, 12 for the PPN, 1 for the dirty bit and 1 40 00:03:10,060 --> 00:03:11,940 for the resident bit. 41 00:03:11,940 --> 00:03:16,950 Suppose that you are told that the page size is doubled in size so that there are now 2^9 42 00:03:16,950 --> 00:03:22,970 bytes per page, but the size of your physical and virtual addresses remain the same. 43 00:03:22,970 --> 00:03:26,750 We would like to determine what effect this change would have on some of the page map 44 00:03:26,750 --> 00:03:28,450 attributes. 45 00:03:28,450 --> 00:03:33,790 The first question is how does the size of each page map entry in bits change? 46 00:03:33,790 --> 00:03:39,340 Since the size of a physical address continues to be 20 bits long, then the change in page 47 00:03:39,340 --> 00:03:45,840 offset size from 8 to 9 bits implies that the size of the PPN decreased by 1 bit from 48 00:03:45,840 --> 00:03:48,040 12 to 11. 49 00:03:48,040 --> 00:03:53,760 This implies that the size of each page map entry also decreases by 1 bit. 50 00:03:53,760 --> 00:03:59,520 How are the number of entries in the page map affected by the change in page size? 51 00:03:59,520 --> 00:04:04,450 Since the number of entries in a page map is equal to the number of virtual pages, that 52 00:04:04,450 --> 00:04:09,920 means that if the size of each page doubled, then we have half as many virtual pages. 53 00:04:09,920 --> 00:04:15,670 This is shown in the size of the VPN which has decreased from 8 to 7 bits. 54 00:04:15,670 --> 00:04:21,420 This also means that the number of entries in the page map have halved in size from 2^8 55 00:04:21,420 --> 00:04:24,980 entries down to 2^7 entries. 56 00:04:24,980 --> 00:04:30,280 How about the number of accesses of the page map that are required to translate a single 57 00:04:30,280 --> 00:04:32,409 virtual address? 58 00:04:32,409 --> 00:04:37,950 This parameter does not change as a result of the pages doubling in size. 59 00:04:37,950 --> 00:04:43,470 Suppose we return to our original page size of 256 bytes per page. 60 00:04:43,470 --> 00:04:49,130 We now execute these two lines of code, a load followed by a store operation. 61 00:04:49,130 --> 00:04:54,100 The comment after each instruction shows us the value of the PC when each of the instructions 62 00:04:54,100 --> 00:05:01,000 is executed, so it is telling us that the load instruction is at address 0x1FC and the 63 00:05:01,000 --> 00:05:04,380 store instruction is at address 0x200. 64 00:05:04,380 --> 00:05:10,410 To execute these two lines of code, we must first fetch each instruction and then perform 65 00:05:10,410 --> 00:05:14,070 the data access required by that instruction. 66 00:05:14,070 --> 00:05:19,560 Since our pages are 2^8 bytes long, that means that the bottom 8 bits of our address correspond 67 00:05:19,560 --> 00:05:21,720 to the page offset. 68 00:05:21,720 --> 00:05:26,380 Notice that our instruction addresses are specified in hex so 8 bits correspond to the 69 00:05:26,380 --> 00:05:29,320 bottom 2 hex characters. 70 00:05:29,320 --> 00:05:35,780 This means that when accessing the LD instruction, the VPN = 1 (which is what remains of our 71 00:05:35,780 --> 00:05:40,460 virtual address after removing the bottom 8 bits.) 72 00:05:40,460 --> 00:05:45,810 The data accessed by the LD instruction comes from VPN 3. 73 00:05:45,810 --> 00:05:52,150 Next we fetch the store instruction from VPN 2, and finally we store an updated value to 74 00:05:52,150 --> 00:05:54,550 VPN 6. 75 00:05:54,550 --> 00:05:59,930 Given the page map shown here, we would like to determine the unique physical addresses 76 00:05:59,930 --> 00:06:03,190 that are accessed by this code segment. 77 00:06:03,190 --> 00:06:08,100 Recall that the four virtual addresses that will be accessed are: 78 00:06:08,100 --> 00:06:16,810 0x1FC which is in VPN 1 0x34C which is in VPN 3 79 00:06:16,810 --> 00:06:25,660 0x200 which is in VPN 2 and 0x604 which is in VPN 6. 80 00:06:25,660 --> 00:06:31,170 Assume that all the code and data required to handle page faults is located at physical 81 00:06:31,170 --> 00:06:37,700 page 0, your goal is to determine the 5 different physical pages that will get accessed and 82 00:06:37,700 --> 00:06:41,800 the order in which they will get accessed by this code segment. 83 00:06:41,800 --> 00:06:46,040 We begin by looking up VPN 1 in our page map. 84 00:06:46,040 --> 00:06:49,760 We see that its resident bit is set to 1. 85 00:06:49,760 --> 00:06:55,669 This means that the virtual page is in physical memory and its PPN is 0x007. 86 00:06:55,669 --> 00:07:03,311 Thus the first physical page that we access is page 0x7, and the first physical address 87 00:07:03,311 --> 00:07:07,700 is determined by concatenating the PPN to the page offset. 88 00:07:07,700 --> 00:07:11,690 This results in a physical address of 0x7FC. 89 00:07:11,690 --> 00:07:20,680 Next, we want to load the data at virtual address 0x34C which is in VPN 3. 90 00:07:20,680 --> 00:07:27,240 Looking up VPN 3 in our page map, we find out that its not resident in physical memory. 91 00:07:27,240 --> 00:07:31,610 This means that we need to make room for it by removing the least recently used page from 92 00:07:31,610 --> 00:07:33,400 physical memory. 93 00:07:33,400 --> 00:07:40,990 The least recently used page is VPN 2 which maps to PPN 0x602. 94 00:07:40,990 --> 00:07:46,290 Since the dirty bit of our LRU page is 0, that means that we have not done any writes 95 00:07:46,290 --> 00:07:51,620 to this page while it was in physical memory so the version in physical memory and on disk 96 00:07:51,620 --> 00:07:53,310 are identical. 97 00:07:53,310 --> 00:07:59,740 So to free up physical page 0x602, all we need to do is change the resident bit of VPN 98 00:07:59,740 --> 00:08:07,139 2 to 0 and now we can bring VPN 3 into physical page 0x602. 99 00:08:07,139 --> 00:08:12,169 Recall that the code for handling the page fault is in physical page 0 so the second 100 00:08:12,169 --> 00:08:15,700 physical page that we access is page 0. 101 00:08:15,700 --> 00:08:21,230 The updated page map, after handling the page fault, looks like this, where the resident 102 00:08:21,230 --> 00:08:30,430 bit for VPN 2 has been set to 0, and PPN 0x602 is now used for VPN 3. 103 00:08:30,430 --> 00:08:37,520 Since this is a LD operation, we are not modifying the page so the dirty bit is set to 0. 104 00:08:37,520 --> 00:08:50,830 The physical address for virtual address 0x34C is now 0x6024C which is now in VPN 0x602. 105 00:08:50,830 --> 00:08:55,980 Next we need to fetch the store instruction from virtual address 0x200 which is in VPN 106 00:08:55,980 --> 00:08:57,620 2. 107 00:08:57,620 --> 00:09:03,270 Since we just removed VPN 2 from physical memory we get another page fault. 108 00:09:03,270 --> 00:09:08,110 This time we will remove the next LRU page from physical memory in order to make room 109 00:09:08,110 --> 00:09:10,820 for VPN 2 once again. 110 00:09:10,820 --> 00:09:18,541 In this case, the dirty bit is set to 1 which means that we have written to PPN 0x097 after 111 00:09:18,541 --> 00:09:20,580 it was fetched from disk. 112 00:09:20,580 --> 00:09:27,120 This means that the page fault handler will need to first write physical page 0x097 back 113 00:09:27,120 --> 00:09:35,690 to virtual page 5 before we can use physical page 0x097 for VPN 2. 114 00:09:35,690 --> 00:09:39,890 After handling the page fault, our updated page map looks like this. 115 00:09:39,890 --> 00:09:49,920 VPN 5 is no longer resident, and instead VPN 2 is resident in physical page 0x097. 116 00:09:49,920 --> 00:09:55,760 In addition, we set the dirty bit to 0 because we have not made any changes to this virtual 117 00:09:55,760 --> 00:09:57,480 page. 118 00:09:57,480 --> 00:10:07,149 We now know that virtual address 0x200 maps to physical address 0x09700 after the handling 119 00:10:07,149 --> 00:10:08,810 of the page fault. 120 00:10:08,810 --> 00:10:16,620 Finally, we need to perform the store to virtual address 0x604 which is in VPN 6. 121 00:10:16,620 --> 00:10:23,540 Since VPN 6 is resident in physical memory, we can access it at physical page 0x790 as 122 00:10:23,540 --> 00:10:25,820 shown in the page map. 123 00:10:25,820 --> 00:10:35,820 This means that virtual address 0x604 maps to physical address 0x79004. 124 00:10:35,820 --> 00:10:41,399 Note that because the dirty bit of VPN 6 was already a 1, we don't need to make any further 125 00:10:41,399 --> 00:10:46,330 modifications to the page map as a result of executing the store operation. 126 00:10:46,330 --> 00:10:52,170 If the dirty bit had been a 0, then we would have set it to 1. 127 00:10:52,170 --> 00:10:59,410 So the five physical pages that were accessed by this program are: page 0x7, page 0 for 128 00:10:59,410 --> 00:11:08,639 the page faults, page 0x602, page 0x097, and page 0x790.