We have a system that uses 3-level hierarchical page table. Logical address is 32 bit.
We know that the same amount of bits is allocated for each level in the logical address.
The system is byte-addressable.
Physical address is 27 bits, and we have 8192 frames is the physical memory.
I want to calculate the number of entries in each level of the page table.
We have 8192 frames, that is 2^13, so we need 13 bits to represent the frame number.
So 27-13=14 bits for the offset.
That gives us 32-14=18 bits for page number.
We know that we can split it equally, so 6 bits represents each level of the hierarchical page table.
But how many entries are in each level? 2^6? If so - why is that?
Thanks!
I understand why a multi-level page table saves memory. In the classic 32-bit example, the size of each Page Table Entry (PTE) in a single-level table is 32 bit (4 Bytes). The fact that 20 of the 32 bits are used for page number means there are 2^20 (~1M) possible entries in this table. The total size of a single-level table is therefore 4 Bytes * 1M = 4MB.A two-level page table requires less memory because it does not need all of the second-level pages at the same time.
However, in a lot of examples for the calculations of two-level page table on the internet, people still use 4 Bytes to indicate the size of each PTE. Since we are only accessing 10 of the 32 bits at the first level, shouldn't the size of these PTEs be smaller than 4 Bytes?
The virtual address is broken to 10-10-12 first 10 bits are an index in the first level page table, there, you will find the address of the second level page table, which you index with the seconds 10 bits to find the start of the physical frame which you index with the remaining 12 bits.
Actually each entry contains the number of the virtual page (there are 2^20 such pages) and 12 flag bits.
Assuming a 4-level page-tables, where the first 3 levels are 9-bits and the last one is 12 bits, then shouldn't the maximum virtual address be 3*9+12=39 bits?
Today i have noticed by accident that my addresses where 47 bits long.
e.g 0x7fb329caa3c0
A page addresses 212 bytes of memory. A page table is one page large, and each entry is 8 bytes, so a page table contains 29 entries, so a page table addresses 221 bytes. A page directory is similar, and so addresses 230 bytes. A page directory pointer table (PDPT) is one level higher, and so addresses 239 bytes. Lastly, the current Intel architecture has one more level, the PML4, addressing 248 bits. I think you are missing this last level in your analysis. Canonical addressing breaks this up into two halves, so you have a lower 247-byte space and an upper 247-byte space.
I have been given the format for page table entries:
Bit 23: Valid Bit
Bit 22: Modify Bit
Bits 22-18: LRU Bits
Bits 17-0: Frame Number
Im told that the system uses 32-bit virtual addresses and pages that are 8192 bytes in size.
How could I calculate the maximum amount of physical memory the system can contain?
So you have 18 bits for page numbers. How many possible numbers (and therefore pages) can be represented by 18 bits?
From the above you'll find how many pages there can be. Then each page has 8192 bytes. How many bytes are there in all possible pages?
Consider a virtual memory system with a 38-bit virtual byte address, 1KB pages and 512 MB of physical memory. What is the total size of the page table for each process on this machine, assuming that the valid, protection, dirty and use bits take a total of 4 bits, and that all the virtual pages are in use? (assume that disk addresses are not stored in the page table.)
Well, if the question is simply "what is the size of the page table?" irrespective of whether it will fit into physical memory, the answer can be calculated thus:
First physical memory. There are 512K pages of physical memory (512M / 1K). This requires 19 bits to represent each page. Add that to the 4 bits of accounting information and you get 23 bits.
Now virtual memory. With a 38-bit address space and a 10-bit (1K) page size, you need 228 entries in your page table.
Therefore 228 page table entries at 23 bits each is 6,174,015,488 bits or 736M.
That's the maximum size needed for a single-level VM subsystem for each process.
Now obviously that's not going to work if you only have 512M of physical RAM so you have a couple of options.
You can reduce the number of physical pages. For example, only allow half of the memory to be subject to paging, keeping the other half resident at all time. This will save one bit per entry, not really enough to make a difference.
Increase the page size, if possible. A 1K page on a 38-bit address space is the reason for the very chunky page tables. For example, I think the '386, with its 32-bit address space, uses 4K pages. That would result in a million page table entries, far less than the 260 million required here.
Go multi-level. A bit more advanced but it basically means that the page tables themselves are subject to paging. You have to keep the first level of page tables resident in physical memory but the second level can go in and out as needed. This will greatly reduce the physical requirements but at the cost of speed, since two levels of page faults may occur to get at an actual process page (one for the secondary paging tables then one for the process page).
Let's look a little closer at option 3.
If we allow 32M for the primary paging table and give each entry 4 bytes (32 bits: only 23 are needed but we can round up for efficiency here), this will allow 8,388,608 pages for the secondary page table.
Since each of those secondary page table pages is 1K long (allowing us to store 256 secondary page table entries at 4 bytes each), we can address a total of 2,147,483,648 virtual pages.
This would allow 8,192 fully-loaded (i.e., using their entire 28-bit address space) processes to run side by side, assuming you have a fair chunk of disk space to store the non-resident pages.
Now obviously the primary paging table (and the VM subsystem, and probably a fair chunk of the rest of the OS) has to stay resident at all times. You cannot be allowed to page out one of the primary pages since you may well need that page in order to bring it back in :-)
But that's a resident cost of only 32M of the 512M for the primary paging table, much better than the (at a minimum, for one fully-loaded process) of 736M.
size of the page table= total no of page table entries*size of the page table entry
STEP 1:FINDING THE NO OF ENTRIES IN PAGE TABLE:
no of page table entries=virtual address space/page size
=2^38/2^10=2^28
so there are 2^28 entries in the page table
STEP2:NO OF FRAMES IN PHYSICAL MEMORY:
no of frames in the physical memory=(512*1024*1024)/(1*1024)=524288=2^19
so we need 19 bits and additional 4 bits for valid, protection, dirty and use bits
totally 23 bits=2.875 bytes
size of the page table=(2^28)*2.875=771751936B=736MB
1KB pages = 2^10, 512MB = 2^29 => Offset = 29 - 10 = 19 bit.
virtual includes two part: page frame + offset => page frame + dirty bit = 38 - 19 = 29 bit.
29 bit includes 4 bit dirty (above) => 25 bit for real page frame, each page frame has 10 bit long.
So, page table size: 2^25 * 10 = 320M.
Hope this correct.