In the book Operating System Concepts by Silberschatz et al. and in other representations of paging, each Page Table (PT) entry is shown to contain a Frame Number(FN). I have been trying to solve some problems on this topic and the solutions also assume the same.
I am new to this topic and all I've read is that the PT (or part of it) is usually stored in the physical memory. This means that the PT must start at some particular physical address. This value is stored in the PTBR. So when the CPU generates a logical address which is divided into a Page Number(PN) and the offset, the PN must be compared against it's value in the PT to determine the corresponding FN, right? Suppose, p=14. Now, 14, in its binary form, must be checked in the PT to find the entry 14.
So, does this mean that some bits of each entry of the PT store the PN and the rest of them store the corresponding FN? Then what about the problems which calculate the PT size assuming that it's only a multiple of the number of bits of the FN and completely ignore the PN bits? Or is it that since the values in the PT are stored in increasing order of PN, some calculations are performed on the PTBR to get the particular PT entry? If so, once the calculation to access the particular PT entry has been done, how is the memory access switched from the base address in the PTBR to the 'n'th entry? What hardware is used for that switch?
Basically, what I'd like to know is, where is the index, p(page number), which checks for the corresponding FN stored? How exactly is this value checked against the PT entries to get the FN?
Physical Page Frames are stored sequentially in hardware.
A logical address consists of a logical page number and an offset into the page. For page translation, we can ignore the offset.
In the simplest case, the page table is an array of Page Table Entries. The Logical Page Number serves as an indicate into this table.
The Page Table Entry may or may not have a value for a Physical Page Frame.
This means that the PT must start at some particular physical address.
The address and size of the Page Table is usually specified by hardware registers.
So when the CPU generates a logical address which is divided into a Page Number(PN) and the offset, the PN must be compared against it's value in the PT to determine the corresponding FN, right?
You appear to be describing an INVERTED PAGE TABLE that is used on a few processors. In most systems the Page Number is an index into the table. There is no comparison.
Related
Consider a paging system with the page table being stored in memory. The logical address space used is 32 bit and the page size is 8KB. This will result in a very large page table(s) and therefore the system uses hierarchical paging with two levels. The number of entries in the outer page table is 256.
Specify the number of bits in each of the three fields composing the logical address namely, the outer page, the inner page, and the offset.
I found some information on finding the page offset, Page offset = log2(page size in bytes), so for this case, it would be 13, but I haven't found much information on how to find the number of bits for the outer page and inner page. Can anyone shine some light on this problem for me?
Thank you.
I might not be entirely correct, but since VPN to PPN translation is one of my favorite parts from OS, I decided to share my understanding. Maybe this picture can help to understand how is virtual address translated in the physical address.
In this example page directory contains 1024 entries, so you will need 10 bits, to be able to define which entry you need. This entry contains address of the inner table. Then, as the inner page table also contains 1024 entries, once you know the address of it, similarly you still need to find the index of its entry which holds the physical page address. So next 10 bits are used for calculating that index. Finally, when the page table entry gives you the physical address of the page, offset gives the exact physical address. If this is not very clear I can go into more details.
In your case, as you have 8KB pages, as you said last 13 bits will be used to calculate the offset. If the outermost page table contains 256 entries then you will need 8 bits (log2(256)) to be able to determine the index of its entry. Then it depends on the number of the entries of the inner table. Or if the size of the entry is defined, the number of entries can be calculated from it. If we assume that left 11 bits are entirely used for the inner table, than it would have to contain 2048 entries, as based on my understanding one instance of page table fits and fills one physical page.
The lowest bits of a logical address will be used for "offset in 8192-byte page". You'd need 13 bits for that (because 1 << 13 = 8192 or because log2(8192) = 13).
The highest bits of a logical address will be used for "index into 256-entry outer page table". You'd need 8 bits for that (because 1 << 8 = 256 or because log2(2562) = 8).
If a logical address is 32 bits and the lowest 13 bits and highest 8 bits are used for other things; how many bits are left over for the index into the inner page table?
Given a virtual memory system which utilises a 32-bit virtual address.
A page table that takes 1 MiB of memory per process.
Each PTE(page table entry requires 4 bytes.
The system has a total of 256 Megabytes of memory available.
I understand that a Page table is essentially a list of entries(PTE) that provide a mapping of the virtual addresses to a physical address.
I need to calculate the size of each virtual page. But I have no clue how.
So far all I've got is 2^20(page-table size)/2^2(PTE size)=2^18 this gives me the total amount of entries I can have in a page table. I'm not even sure if this is useful to find the size of each virtual page.
Could anyone point me in the right direction? Perhaps I'm misunderstanding in how these metrics relate to the size of a virtual page.
Edit: I've found out the size of the page is determined by the following.
A virtual address consists of bits for a page pointer and an offset.
The last bits of the virtual address are called the offset which is the location difference between the byte address you want and the start of the page. You require enough bits in the offset to be able to get to any byte in the page.For a 4K page you require (4K == (4 * 1024) == 4096 == 212 ==) 12 bits of offset.
The page pointer can be determined by the number of entries in the table. This was simply my formula from before 2^20(page-table size)/2^2(PTE size)=2^18 entries. Which means I have 18 bits being used in my virtual address for my page pointer. I can determine the offset by 2^32(virtual address size)/2^18 which gives me 2^14. Therefore my page size for my virtual address is 2^14 or 16KiB.
The problem as you describe is under-specified. You need to know the width of the page offset field within the virtual address (or, how many levels of indirection the VM system is using). For example, (as in ONE of the modes that x86 system uses), if you have two levels of indirection, then you will have 10x2 bits used for levels of indirection and remaining 12 bits for offset within the page. That gives you a page size (= frame size) of 4KB.
If you instead use one level of indirection (as ANOTHER x86 mode allowed, but is found less often), then you can have a division of 10 bits for the only level of indirection and remaining 22 bits as offset within the page. That gives a page size of 4MB.
You see above that same 32 bit virtual address can follow different levels of indirection for paging and end up with different page sizes.
Page offset size in the virtual address determines the page size.
There is no answer under those fact. You have the page table entry is 32 bits. That puts a theoretical upper bound on the page size as 2^32. However, some bits are going to used for control so the size will be smaller.
The 1MB size of of the page table and 32-bit virtual address facts are irrelevant to the page size.
This question already has an answer here:
Minimum associativity for a PIPT L1 cache to also be VIPT, accessing a set without translating the index to physical
(1 answer)
Closed last year.
Homework question, so please just nudge me in the right direction.
Consider a system with physically-addressed caches, and assume that 40-bit virtual addresses and 32-bit physical addresses are used, and the memory is byte-addressable. Further assume that the cache is 4-way set-associative, the cache line size is 64 Bytes and the total size of the cache is 64 KBytes.
What should be the minimum page size in this system to allow for the overlap of the TLB access and the cache access?
I've been stuck on this question and have no idea how to even begin. Can someone give me a hint towards finding the solution?
I think the most important piece of information in the question is
overlap of the TLB access and the cache access
This means, we access the Cache at the same time we access the TLB. In practice, what we really do is, we index the cache with the index bits from the virtual address and by the time we have located the entry in the cache, we will have the data (physical address) from the TLB. Then we can do the tag comparison with physical address. In other words cache acts as a Virtually indexed, Physically tagged (VIPT) cache.
Even though the scheme sounds efficient, the thing to lookout is, number of bits used to index the cache, cannot be higher than the number of bits needed to represent the page size. Simply, size of a page can put an upper limit on the number of cache entries.
Now coming back to your question,
its a 64KBytes cache with 4 way set assoc. and cacheline of 64Bytes.
Number of cachelines = (64KBytes/4)/64Bytes = 2^8 cachelines
That means if a page is 256Bytes or bigger, we can use this mechanism. If a page is smaller than 256 Bytes, then we cannot assume the index bits of the virtual address and the physical address are going to be the same.
What should be the minimum page size in this system to allow for the
overlap of the TLB access and the cache access?
256Bytes
I solved some question, where the page table entry size needed only 26 bits - 22 for the physical address, and 4 for dirty bits and such. However it was rounded up to 32 - because 26 is not a power of 2. Must be something simple I'm missing but why do we have to do that? Thanks!
I think here that you need to realize that the page table entry needs to accessed like any other piece of data. Typically, this means that it needs to fit into a byte or a word.
Now bytes only hold 8 bits, so that is not enough room. For many machines (and I suspect, your machine too), words are 32 bits.
Thus the page table entry is allocated 32 bits of space.
Number of entries in a page table entry and the size are two things. Obviously the size is equal to the number of entries times size of a single entry. Page table entry is there to tell you which virtual page maps to which physical page. Which means, the number of entries you need in a page table entry is, number of virtual page you have. which can be calculated by dividing the total addressable space by the size of a page. (For example, 32 bit address and a 4k page size gives us 2 to the power 20 entries), virtual part of an entry will be 20 bits. Size of a physical part entry is determined by the available physical memory. Usually the page size remain same. By this way you can calculate the bits needed for a single entry. Then you can multiply this by the number of entries and you have the total size.
I had this problem in an exam today:
Suppose you have a computer system with a 38-bit logical address, page size of 16K, and 4 bytes per page table entry.
How many pages are there in the logical address space? Suppose we use two level paging and each page table can fit completely in a frame.
For the above mentioned system, give the breakup of logical address bits clearly indicating number of offset bits, page table index bits and page directory index bits.
Suppose we have a 32MB program such that the entire program and all necessary page tables (using two level paging) are in memory. How much memory (in number of frames) is used by the program, including its page tables?
How do I go about solving such a problem? Until now I would have thought page size = frame size, but that won't happen in this case.
Here is what I think:
Since the page size is 16K, my offset will be 17 bits (2^17 = 16K). Now how do I divide the rest of the bits, and what will be the frame size? Do I divide the rest of the bits in half?
238 / 16384 = 16777216 pages.
On one hand, the remaining 38-log216384=24 bits of address may be reasonable to divide equally between the page directory and page table portions of the logical address since such a symmetry will simplify the design. On the other hand, each page table should have the same size as a page so they can be offloaded to the disk in exactly the same way as normal/leaf pages containing program code and data. Fortunately, in this case using 12 bits for page directory indices and page table indices gets us both since 212 * 4 bytes of page table entry size = 16384. Also, since a page address always has 14 least significant bits set to zero due to the natural page alignment, only 38-14=24 bits of the page address need to be stored in a page table entry and that gives you 32-24=8 bits for the rest of control data (present, supervisor/user, writable/non-writable, dirty, accessed, etc bits). This is what we get assuming that the physical address is also not longer than 38 bits. The system may have slightly more than 38 bits of the physical address at the expense of having fewer control bits. Anyway, everything fits. So, there, 38=12(page directory index)+12(page table index)+14(offset).
32MB/16KB = 2048 pages for the program itself. Each page table covers 212=4096 pages, so you will need about 2048/4096=0 page tables for this program. We round this up to 1 page table. Then there's also the page directory. 2048+1+1=2050 is how many pages are necessary to contain the entire program with its related pages tables in the memory.