***************************** Problem 1: A Two-Level Table ***************************** Assume we are putting together a 2-level page table (as discussed in class). Given: - a 128 KB virtual address space - 1 MB of physical memory (max) - page size of 128 bytes How much space do you need in a page-table entry (PTE)? Start with the physical address: it must be 20 bits, to be able to address all 1 MB of physical memory. Then, chop it up into pages: each page is 128 bytes, which means you need 7 bits of the 20-bit physical address for the offset. The remaining 13 bits are the number needed for the page frame number (PFN). This makes sense too: with 1 MB of physical memory, chopped up into 128-byte pages, you get (1 MB/128 bytes) or 8192 pages. To pick which of those 8K pages a physical address refers to, you need 13 bits. Now we know a crucial piece of information: the size of the PFN (13 bits). Thus, the PTE must at least be able to hold 13 bits. It probably also needs a valid bit, and perhaps a couple of bits for protection information (read-only, or read-write, or execute). Thus, let's say 16 bits total per page table entry (PTE), or 2 bytes. How much space do you need in a page-directory entry (PDE)? A page directory entry is similar: we need the PFN of the page of the page table we are pointing to (assuming the pages of the page table are page-aligned, which of course they would be), plus a valid bit. Thus at least 14 bits so let's make life easy and round up to 16 bits again, or 2 bytes per PDE. Describe what a 2-level page table would look like. - How many bits of a virtual address are needed to index into a page of a page table? Now let's look at a virtual address. It is 17 bits in size, as it needs to be able to address 128KB. 7 bits of that are offset, leaving 10 bits for the VPN. Now, we have to chop up this VPN into bits that are used to index each page of the page table, and bits that are used to index the page directory. This is done like this: VA: 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 |---------- VPN ------------| |---- offset -------| How many bits of the VPN do we need to index into a page of the page table? Well, to know this, we need to know how many PTEs fit onto a single page. But this is easy: we know that page size is 128b and that each PTE is 2b. Thus, 64 PTEs fit on each page. Once given an address to a page, then, to pick which PTE on that page we need, we need 6 bits, as 2^6 is 64. Thus, the least significant 6 bits of the VPN are used to index into a page of the page table. We'll call this part of the VPN the "ChunkIndex": VA: 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 |---------- VPN ------------| |---- offset -------| |-- ChunkIndex--| - How many bits of a virtual address are needed to index into the page directory? The remaining 4 bits are used to index the page directory: VA: 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 |---------- VPN ------------| |---- offset -------| |-PDIndex-| |-- ChunkIndex--| The page directory index ("PD idx" in the figure above) is used to index into the page directory to find the chunk of the page table we are interested in. Thus, a full lookup, starting with a page table base register that points to the physical address of the page directory, goes like this: - Add page table index to page table base register -> result: address of desired PDE * Fetch PDE, extract PFN of page table chunk from it - Add chunk index to physical address of page table chunk -> result: address of desired PTE * Fetch PTE, extract PFN of desired virtual page - Use PFN + offset from VA to get final physical address (PA) The starred operations represent memory lookups to fetch the contents of the page table. As you can see, with a 2-level page table, 2 memory references are needed just to complete the address translation! And yet another memory reference to actually get the data you wanted. Hope that TLB works well! What happens to the size of the page directory as we add more bits to the virtual address (i.e., increase the size of the address space) ? As the VA grows, more bits get added to the PDIndex in the picture: VA: 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 |--------------- VPN -------------| |---- offset -------| |--- PDIndex ---| |-- ChunkIndex--| With more bits in the page directory index, the page directory thus grows. Thus, the bigger the address space (given a fixed page size and page-table entry size, etc.), the bigger the page directory. The problem, of course, that then arises is one of allocation. When allocating a new page directory (say, when you create a new process), you need to find a free chunk of contiguous memory for the page directory. This is a pain. For this reason, we sometimes chop up the page directory into pages too, as we now see... ***************************** Problem 2: Beyond Two Levels ***************************** Assume we have a 32-bit virtual address space with 1KB pages. Assuming a 4-byte PTE size, how many levels of page table would we need to ensure that no page directory is ever longer than the size of a single page? A 32-bit VA with 1 KB pages has 22 bits of VPN and 10 bits of offset. If each PTE is 4 bytes (and assume PDEs are too), it means that each page holds 1KB/4 or 256 PTEs. We need 8 bits of the VPN to index such a page. This leaves the top (22-8) or 14 bits of VPN. In a 2-level page table, all of these bits would be used to index the page directory; but this page directory with 2^14 entries is too big to fit into one page (it is 64KB, or 2^14 entries * 4 bytes/entry). Thus, we chop it into pages too, and thus use the next 8 bits of the VPN to index into pages of the page directory. This leaves the top (14-8) or 6 bits of the virtual address for the top-level page directory; this page directory clearly fits into a single page (there are only 64 entries, each of size 4 bytes) and thus the answer: 3. You need a 3-level table to make sure no piece of the page table or directories above it exceed the size of a single page. Doing so makes allocating pages for the page table quite easy.