WEBVTT 00:00:00.570 --> 00:00:05.840 Virtual memory allows programs to behave as if they have a larger memory than they actually 00:00:05.840 --> 00:00:06.900 do. 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. 00:00:14.049 --> 00:00:18.910 The virtual addresses are translated into physical addresses using the page map which 00:00:18.910 --> 00:00:23.589 is a lookup table that has one entry per virtual page. 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 00:00:29.099 --> 00:00:31.939 returns the physical page number. 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 00:00:36.940 --> 00:00:42.370 page must be brought in from disk to physical memory before it can be accessed. 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 00:00:48.500 --> 00:00:52.579 room for the address that is currently being requested. 00:00:52.579 --> 00:00:58.110 The page map is also updated with the new mapping of virtual to physical pages. 00:00:58.110 --> 00:01:03.420 Since bringing data to and from disk is an expensive operation, data is moved in chunks. 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 00:01:09.210 --> 00:01:10.210 unit. 00:01:10.210 --> 00:01:15.370 The idea is that instructions, or data, that are close to the current address are likely 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. 00:01:22.030 --> 00:01:26.380 This is especially true if the cost of fetching the first word is significantly higher than 00:01:26.380 --> 00:01:33.110 the cost of fetching adjacent memory locations as is the case with accesses to disk. 00:01:33.110 --> 00:01:37.200 So data is moved back and forth from disk in pages. 00:01:37.200 --> 00:01:41.950 The size of a page is the same in both virtual and physical memory. 00:01:41.950 --> 00:01:46.119 Lets look at an example of how virtual memory is used. 00:01:46.119 --> 00:01:50.860 While it is usually the case that the virtual address space is larger than the physical 00:01:50.860 --> 00:01:55.460 address space, this is not a requirement and in this problem the virtual address space 00:01:55.460 --> 00:01:59.720 happens to be smaller than the physical address space. 00:01:59.720 --> 00:02:07.280 Specifically, virtual addresses are 16 bits long so they can address 2^16 bytes. 00:02:07.280 --> 00:02:12.110 Physical addresses are 20 bits long so that means that our physical memory is of size 00:02:12.110 --> 00:02:14.910 2^20 bytes. 00:02:14.910 --> 00:02:20.790 Our page size is 2^8 bytes or 256 bytes per page. 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 00:02:26.730 --> 00:02:29.320 8 bits for the virtual page number (or VPN). 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 00:02:36.730 --> 00:02:39.000 for the physical page number (or PPN). 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? 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 00:02:52.000 --> 00:02:54.220 a physical page. 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 00:03:00.500 --> 00:03:02.230 in the VPN. 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 00:03:10.060 --> 00:03:11.940 for the resident bit. 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 00:03:16.950 --> 00:03:22.970 bytes per page, but the size of your physical and virtual addresses remain the same. 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 00:03:26.750 --> 00:03:28.450 attributes. 00:03:28.450 --> 00:03:33.790 The first question is how does the size of each page map entry in bits change? 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 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 00:03:45.840 --> 00:03:48.040 12 to 11. 00:03:48.040 --> 00:03:53.760 This implies that the size of each page map entry also decreases by 1 bit. 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? 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 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. 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. 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 00:04:21.420 --> 00:04:24.980 entries down to 2^7 entries. 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 00:04:30.280 --> 00:04:32.409 virtual address? 00:04:32.409 --> 00:04:37.950 This parameter does not change as a result of the pages doubling in size. 00:04:37.950 --> 00:04:43.470 Suppose we return to our original page size of 256 bytes per page. 00:04:43.470 --> 00:04:49.130 We now execute these two lines of code, a load followed by a store operation. 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 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 00:05:01.000 --> 00:05:04.380 store instruction is at address 0x200. 00:05:04.380 --> 00:05:10.410 To execute these two lines of code, we must first fetch each instruction and then perform 00:05:10.410 --> 00:05:14.070 the data access required by that instruction. 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 00:05:19.560 --> 00:05:21.720 to the page offset. 00:05:21.720 --> 00:05:26.380 Notice that our instruction addresses are specified in hex so 8 bits correspond to the 00:05:26.380 --> 00:05:29.320 bottom 2 hex characters. 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 00:05:35.780 --> 00:05:40.460 virtual address after removing the bottom 8 bits.) 00:05:40.460 --> 00:05:45.810 The data accessed by the LD instruction comes from VPN 3. 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 00:05:52.150 --> 00:05:54.550 VPN 6. 00:05:54.550 --> 00:05:59.930 Given the page map shown here, we would like to determine the unique physical addresses 00:05:59.930 --> 00:06:03.190 that are accessed by this code segment. 00:06:03.190 --> 00:06:08.100 Recall that the four virtual addresses that will be accessed are: 00:06:08.100 --> 00:06:16.810 0x1FC which is in VPN 1 0x34C which is in VPN 3 00:06:16.810 --> 00:06:25.660 0x200 which is in VPN 2 and 0x604 which is in VPN 6. 00:06:25.660 --> 00:06:31.170 Assume that all the code and data required to handle page faults is located at physical 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 00:06:37.700 --> 00:06:41.800 the order in which they will get accessed by this code segment. 00:06:41.800 --> 00:06:46.040 We begin by looking up VPN 1 in our page map. 00:06:46.040 --> 00:06:49.760 We see that its resident bit is set to 1. 00:06:49.760 --> 00:06:55.669 This means that the virtual page is in physical memory and its PPN is 0x007. 00:06:55.669 --> 00:07:03.311 Thus the first physical page that we access is page 0x7, and the first physical address 00:07:03.311 --> 00:07:07.700 is determined by concatenating the PPN to the page offset. 00:07:07.700 --> 00:07:11.690 This results in a physical address of 0x7FC. 00:07:11.690 --> 00:07:20.680 Next, we want to load the data at virtual address 0x34C which is in VPN 3. 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. 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 00:07:31.610 --> 00:07:33.400 physical memory. 00:07:33.400 --> 00:07:40.990 The least recently used page is VPN 2 which maps to PPN 0x602. 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 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 00:07:51.620 --> 00:07:53.310 are identical. 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 00:07:59.740 --> 00:08:07.139 2 to 0 and now we can bring VPN 3 into physical page 0x602. 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 00:08:12.169 --> 00:08:15.700 physical page that we access is page 0. 00:08:15.700 --> 00:08:21.230 The updated page map, after handling the page fault, looks like this, where the resident 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. 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. 00:08:37.520 --> 00:08:50.830 The physical address for virtual address 0x34C is now 0x6024C which is now in VPN 0x602. 00:08:50.830 --> 00:08:55.980 Next we need to fetch the store instruction from virtual address 0x200 which is in VPN 00:08:55.980 --> 00:08:57.620 2. 00:08:57.620 --> 00:09:03.270 Since we just removed VPN 2 from physical memory we get another page fault. 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 00:09:08.110 --> 00:09:10.820 for VPN 2 once again. 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 00:09:18.541 --> 00:09:20.580 it was fetched from disk. 00:09:20.580 --> 00:09:27.120 This means that the page fault handler will need to first write physical page 0x097 back 00:09:27.120 --> 00:09:35.690 to virtual page 5 before we can use physical page 0x097 for VPN 2. 00:09:35.690 --> 00:09:39.890 After handling the page fault, our updated page map looks like this. 00:09:39.890 --> 00:09:49.920 VPN 5 is no longer resident, and instead VPN 2 is resident in physical page 0x097. 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 00:09:55.760 --> 00:09:57.480 page. 00:09:57.480 --> 00:10:07.149 We now know that virtual address 0x200 maps to physical address 0x09700 after the handling 00:10:07.149 --> 00:10:08.810 of the page fault. 00:10:08.810 --> 00:10:16.620 Finally, we need to perform the store to virtual address 0x604 which is in VPN 6. 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 00:10:23.540 --> 00:10:25.820 shown in the page map. 00:10:25.820 --> 00:10:35.820 This means that virtual address 0x604 maps to physical address 0x79004. 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 00:10:41.399 --> 00:10:46.330 modifications to the page map as a result of executing the store operation. 00:10:46.330 --> 00:10:52.170 If the dirty bit had been a 0, then we would have set it to 1. 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 00:10:59.410 --> 00:11:08.639 the page faults, page 0x602, page 0x097, and page 0x790.