I understand that (for intel) the virtual address translation process is :
1. The incoming virtual address is divided into a page table number, a page number, and an offset.
2. The process desriptor base register (PDBR) in the CPU tells where the directory starts.
3. The page table number is multiplied by four to use as an offset into the directory, and the directory entry is looked up.
4. The directory entry contains the address of the page table, and validity and protection information. If this information says that either the page table isn't present in memory or the protections aren't OK, the translation stops and an exception is raised.
5. The page number is multiplied by four to use as an offset into the page table, and the page table entry is looked up.
6. The page table entry contains the address of the page, and validity and protection information. If this information says that either the page isn't present in memory or the protections aren't OK, the translation stops and an exception is raised.
7. The offset is used as an index into the page.
8. The data is at the address finally arrived at.
And that all makes sense up to step 6 where I get confused because
the table entry format only specifies 20 bits for the physical page frame address which means it can only access up to 1 megabyte, or is it shifted left 12 bits (multiplied by 4096: size of page) to be able to access 4 gigabytes
This is the 32-bit translation process. Each page table entry is 32 bits, but the low 12 bits are used for flags. The upper 20 bits are the page address.
Related
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.
We have question:
Calculate the maximum and minimum sizes of a single 3-level page table
for a 32-bit machine with a 4kB page size. The partitioning of the 20
bits representing a virtual page in this 3-level pge table is: (7, 7,
whatever bits remain).
I understand that minimum size should be 4k+4k+4k=12k because a process needs to have at least one frame allocated for itself. However I'm confused as to how to calculate the maximum. It works nicely with 2-level page tables because we can slice the 20 bits into 10 and 10 which works out nicely to 1024 entries * 4 bytes each which is a nice factor of 4k. But with 2^7 entires we get a strange number, any ideas on how to solve? Thanks.
Sadly, your question does not have an answer. This type of question is typical of the horrible operating systems textbooks out there.
First of all, you have no indication of the page table entry. Is is 32bits? 64bits? Are the entries the same size at each level of the page table?
It's not really possible for a process to have a 0-byte page table. There would need to be a least one page mapped for the process to executive. A minimum would then be 3 page table entries of whatever unspecified size (probably something like 12-bytes).
At to the maximum, that depends upon how the hardware and OS divides up the address space.
Excluding the valid, dirty and reference bits, considering only actual "mapping" from virtual address space to physical address space, why is it said that the size of a page table entry is determined by the number of bits required to reference a page from the main memory (Like here: https://stackoverflow.com/a/14770650/3684931)
My argument is that since a physical address can be in secondary storage too (which is the point of using virtual memory), the size of a page table entry should simply be equal to the number of bits to required to reference any page among all the pages in the virtual memory.
To give an example, if virtual address space is addressable by 64 bits, main memory is addressable by 48 bits and page size is 16KB (addressable by 14 bits), a page table should map (64 - 14) 50 bit addresses to (64 - 14) 50 bit addresses and not (48 - 14) 34 bit addresses.
It could map to 34 bit addresses if the page exists in main memory, but otherwise, the upperbound should be 50 bits which should be considered while calculating the size of a page table.
Am I missing something here?
Page table entries are sized to support the virtual address size and the maximum amount of physical memory supported. They are not sized based on any aspect of the secondary storage.
In your example, the page table has to support mapping 2^50 virtual pages to a possible 2^34 physical pages. Thus a page table entry will use 34 bits to hold the physical page number.
If a page is not present in memory, and it was previously paged out to secondary storage, then a data structure (like a hash table) can be used to locate where in the paging file the page is located. You don't need to use the page table structure to do this.
The size of a page table must account for:
1. Control bits
2. Access restriction bits
3. The page size
4. The number of bits requires to access the required number of pages.
The page table entries correspond to the virtual memory. The number of entries times the page size is the virtual address size.
The entries themselves only need to address physical memory.
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.
What would be the total size in bytes of the page map table?
If an inverted page map table is used what would be its total size in bytes if the LRU field within each PTE is reduced to 3 bits?
I have been helped with this problem, and calculated that the maximum physical memory of the system is 2GB. I'm not sure if I need to take the 32 bit virtual address data given into consideration when calculating the total size of the page map table.
Looks like there isn't enough information to answer this question.
See, the page table size is equal to the number of entries in it times the size of each entry.
First, I don't know if the page table entries are 24-bit-long or 32-bit-long or bigger. That's not explicitly specified.
Second, if there's only one page table involved in translation of virtual addresses into physical addresses, a page table has to cover the entire 32 bits of the virtual address. Since a single PTE only handles 13 (because the page size is 2^13=8192 bytes), you'd need 2^(32-13)=2^19 entries in this case.
Now, if there's a hierarchy of page tables involved in the translation, in other words, the entries of the first page table (often called page directory) point to a second-level page table and those either point to the code/data pages or to a third-level page table and so on, you get the idea... in this case the answer is going to be different. But it's not specified whether there's just one page table or a chain of multiple page tables.
In my opinion, a page table of 2^19 entries is unlikely. A page table is usually the size of a single page (sometimes smaller). So, if, for example, PTEs are 32-bit, you have 8192/4=2048 PTEs in a PT and that covers only 11 (2^11=2048) out of the remaining 32-13=19 bits of the virtual address. The other 19-11=8 bits of the virtual address must be taken care of by another page table, page directory, having only 2^8=256 entries, provided the entries are the same in the page table and page directory.
Given the provided information, there's no definitive answer here, only guesses.
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.