I have a HW problem for my architecture class about determining page table size. I see that there is already a SO entry about this here:
Determine page table size for virtual memory
But I am having trouble applying that to my problem.
I understand that the general equation is:
(Total # pages) x (size of page)
But when I do the math the numbers don't make sense. Could somebody please help me see what I am doing wrong?
byte-addressable memory,
48 bit virtual space,
16 kB page size (14 bits to represent),
4 GB physical memory (22 bits to represent), &
Valid, dirty, reference bits for each page
What is the table size for one application?
Total # pages = 2^48 / 2^14 = 2^34
Page size = 16 kB
Total page size = (total # pages) x (page size) = 2^34 x 16 kB = 274877906944 kB ?!?!?
Some help would be much appreciated - there is clearly something I am doing wrong.
Thank you.
You confuse the page with a page table entry:
The page table consists of page table entries
Each page table entry holds an address to physical memory of a page
The page is a 16kB slice of memory
You want to map 4GB of physical memory onto a number of 16kB pages.
So you need (4*10^6 / 16*10^3) = 250 pages (adresses)
Each address is held in a page table entry which is a 32-bit integer that consists of the address in physical memory of a page and some modifier/info bits about that page.
Each process needs atleast one page table. Here it consists of 250 page table entries. Each page table entry size is an 32-bit (4B) number (call it whatever you want)
So the total size needed for one process is:
250 * 4B = 1000 B = 1kB
Why this approach isn't used based on the paging model used by the x86 MMU:
The problem with a one single level paging mechanism as you describe is that every (no matter how small) process will need:
4GB/16kb = 4 * 10^6 B / 16 * 10^3 B = 0,25 * 1000 = 250 page table entries
250 * 4 byte (32 bit per entry) = 1 kB per process
It doesn't seem like much but here you have used 16 kB pages (for example most x86 systems use 4kb pages so you would need 1MB for each process)
This is why the x86 uses a two-level paging process in which each process has 1024 page directory entries and each of those entries hold the address of the page table (which holds 1024 page table entries). So the minimal allocated memory of a process becomes:
4 bytes (page directory entry) + 1024 * 4 bytes (1024 32-bit page table entries)
Each page table entry points to a 4kB physical page in memory.
1024 page directory entries * 1024 page table entries for each directory * 4kB page = 4GB of addressable memory
The virtual address consists is roughly:
Page directory entry index
Page table entry index
Offset in the 4kB page
This means that even if you increase the size of a single page (thus reducing the number of page table entries needed) then you need a bigger number to describe the offset.
Related
Consider a 32-bit virtual and physical address space with physical page size of 4KB. Assume that a process has
just been created and its program copied into memory. Size of program is 1 KB. How much memory will be
required to store the page tables of this process?
I did this :
.
PTE size for 32bit physical address = 32 bits
= 4 bytes.
no of PTEs in single level page table = virtual pages= virtual address space / page = 2^32 / 2^ = 2^20
so no of pages = 2^20.
But in the solution they have also written as:
"#Pages in single level page table = #PTEs x PTE size / page size
= 2^20 x 4 bytes / 2^12 bytes
= 2^10. "
as far as I understand page table is an array of page table entries ,one per virtual page . So no of page table entries should be equal to no of Pages.
so then why #Pages is equal to 2^10??
Another thing what is "with physical page size of 4KB." ?? Pages are virtual address so does that mean a page occupy 4KB of space on physical memory??
Any sort of help will be appreciated.
For a single level of page tables; the virtual address space is 4 GiB and a page is 4 KiB so you will need "4 GiB/4 KiB = 1048576 pages = 1048576 page table entries". This is the answer you came up with (2^20 page table entries).
If there are 1048576 page table entries and you have no idea how large a page table entry is, then the total amount of memory needed for all page table entries will be "1048576 * unknown = unknowable".
However, with a 32-bit physical address space size and 4 KiB page size we know that 12 bits of an address will be used for "offset within page" and the remaining 20 bits of an address will be used for "page number"; therefore we know that a page table entry must be at least 20 bits, so we know that the total amount of memory needed for all page table entries will be at least "1048576 * 20 bits = 20971520 bits = 2560 KiB".
If we make random potentially false assumptions (based on educated guesses) and decide that maybe a page table entry is 4 bytes, we could say that the total amount of memory needed for all page table entries will probably be "1048576 * 4 bytes = 4 MiB".
If the total amount of memory needed for all page table entries is 4 MiB and a physical page is 4 KiB; then you will need "4 MiB / 4 KiB = 1024 pages" to store all the page table entries. This is the answer they came up with (2^10 pages).
Another thing what is "with physical page size of 4KB." ?? Pages are virtual address so does that mean a page occupy 4KB of space on physical memory??
Pages aren't virtual addresses; and there are both virtual pages and physical pages.
The basic idea is to split a virtual address into two parts (with masking/AND and shifting) so that "(virtual_page_number << K) + offset_within_page = virtual_address", then use "virtual_page_number" (and page tables) to find "physical_page_number", then do "physical_address = (physical_page_number << K) + offset_within_page".
For this to work, the size of a virtual page must be the same as the size of a physical page; so the words "page size" are used to refer to both the virtual page size and the physical page size.
I was learning Linux memory management recently, now I am stopped by the paging mechanism.
As with Regular Paging for 32-bit processors, why page directory entries (32 bits in total) need 20 bits to indicate 2^10 Page Tables? I think 10-bits is just enough and no waste.
What is wrong with my understanding?
Thank you.
A page has a size of 4096 bytes, i.e., 2^12 bytes.
This means that pages are aligned to a multiple of 4 KB, and that the address of a page is xxxxxxxxxxxxxxxxxxxx000000000000.
In other words, a page address needs 12 bits less than the address bus size.
For 32-bit addresses, this ends up being 20 bits.
A page directory entry has 32 bits, so 2^10 of them fit into a 4 KB page.
Regular x86 uses 2 level pagetable, but i think the case is that they talk here about one-level page table ... So you have one huge structure with 2^20 entries, each entry associate virtual page address (mentioned 20 bits) with physical page address. Can you provide a link where have you found this picture?
For a 32-bit processor, it will generate 32-bit address.
If an address generated is 32-bit then, addressable memory is 4GB.(As 2^32 = 4GB)
Now, both page table and page directory reside on memory within a single page.
Also, page size is 4kB.
And in page directory and page table, entries always point to border or edge of page table and page directory respectively.
If you divide 4G(1G=2^30) by 4k(1k = 2^10), you'll get 2^20
That is we need 20bits to access all of 4kb chunks within 4GB memory or maximum addressable memory.
That is why, entries for page table and page directory are always 20-bits
I had operating exam a week a go and I faced the following question:
I solved the first part in this way :
2^32/2^12=2^20 * 4 =4* 2^20 size of page table
First I want to see if my answer is right? then for the second part I have no Idea how to solve it I read chapter 8 of operating system concept but could not get any idea how to solve it...
Can anyone help?
The question talks about two cases:
1st Case: When single level paging is enabled (1st Question)
2nd Case: When two level paging is enabled (2nd question)
(Refer this link to see how two-level paging is perceived graphically )
Now, to get the size of page-table we need Number of Page-Table Entries and Size of each entry and we multiply it to get size of page table.
Given, Size of page-table entry - 4 Bytes
For Question 1:
Given, Size of virtual memory: 2^32 bytes
Size of each page: 2^12 bytes
So, Max number of pages that virtual mermory can allocate: 2^(32-12) - 2^20 pages
This means, in a case of single level paging page table will consists of 2^20 page table entries.
Currently, we have number of page table entries and size of each page table entry which consitute size of single level page-table i.e
**2^20(page-table entries) * 4 ( size of each page-table entry in bytes)**
2nd Question:
The statement says that page-size used for paging the page-table is 2^12 bytes which means single-level page-table is further divided into blocks of 2^12 bytes each which means after dividing the page-table into 2^12 bytes blocks we, get
( 2^20 * 4 ( size of page table ) ) / ( 2 ^ 12 ( block size) ) = 2 ^ 10 page-tables
2^10 page tables can be formed at maximum.
To, find the size of 2nd level page table we need numer of entries and size of each page-table entry.
Number of entries are 2 ^ 10 as found above.
Size of each page table entry will be 10 bits which has to be converted into bytes, so we have to make it 16 bits to make it two bytes and size of second page - table will be
2 ^ 10 * 2
This is the answer to the second question
A computer uses 46-bit virtual address, 32-bit physical address, and a three-level paged page table
organization. The page table base register stores the base address of the first-level table (T1), which
occupies exactly one page. Each entry of T1 stores the base address of a page of the second-level table (T2).
Each entry of T2 stores the base address of a page of the third-level table (T3). Each entry of T3 stores a page
table entry (PTE). The PTE is 32 bits in size. The processor used in the computer has a 1 MB 16-way set
associative virtually indexed physically tagged cache. The cache block size is 64 bytes.
Q.What is the size of a page in KB in this computer?
(A) 2 (B) 4 (C) 8 (D) 16
Q.What is the minimum number of page colours needed to guarantee that no two synonyms map to
different sets in the processor cache of this computer?
(A) 2 (B) 4 (C) 8 (D) 16
A question from last Gate exam . how do I solve this kind of question?
All the page table reside in the physical memory(RAM)
since the physical address is 32 bit addressable each level table holds a 32 bit
(4 byte)address of the RAM
Assume the size of a page is x bytes. (which we need to find)
As the size of level 1 table is also x (as given in the question that level 1 table accommodate exactly a page)it can hold x/4 base addresses of x/4 level 2 tables (which also accommodate exactly a page) and each level 2 table hold base addresses of x/4 level 3 tables.
the level 3 table has entities equal to 2^46/x
ie. (x/4)(x/4)(x/4) = 2^46/x
on solving x=8192 which is in bytes
so 8192/1024 = 8 K bytes
answer to 2nd part .... as its virtually indexed and physically tagged so for caches L group bits and B byte bits can accommodate a Full page of Ram for the efficient use so for efficient use we have
cache size /2^A = 2^l+b =page size ................http://cseweb.ucsd.edu/classes/fa10/cse240a/pdf/08/CSE240A-MBT-L18-VirtualMemory.ppt.pdf
Page size = 1 MB /16 = 64 KB .........
so cache will have 8 different pages copied on same l+b bits
so we will color 8 Pages to differentiate between them.
Why do we save memory if we use inverted page tables to map virtual addresses to physical ones? If we have for example two processes which both have 4 pages we would have 8 entries in two different tables pointing from virtual to physical address:
Process 1:
[0] = 1
[1] = 5
[2] = 63
[3] = 0
Process 2:
[20] = 14
[21] = 55
[22] = 11
[25] = 9
If we would use inverted page tables we would only have one big table pointing it the other way around. But in size they equal.
2) Inverted page table
[0] = <p1 | 3>
[1] = <p1 | 0>
[5] = <p1 | 1>
[9] = <p2 | 25>
[11]= <p2 | 22>
[14]= <p2 | 20>
[55]= <p2 | 21>
[63]= <p1 | 2>
The page table in the first case is a per process data structure.Every process has a pointer to its own page table ,this pointer gets loaded in the %CR3 register when the process is scheduled.Also it is saved when is it context switched along with other registers.
But an inverted hash table is a global data structure.The OS which uses this technique will use some locking mechanism to give access to only 1 process at a given point of time.(imagine 2 process on 2 cores accessing a global data simultaneously).
Assuming 4GB of per process ram and 4096 page size, In the first case each process has 4GB/4096 , (no of entries in its page table * size of each page table entry) and all this will eat up space, for every process that is created/forked.The total memory used for mapping virtual to physical is sum total of page table size of all process.This is simpler approach since on every context switch you will only change a pointer ,nothing complex.
In the second case you will have a single table with only 4GB/4096 entries,so space is saved,but the memory management becomes complicated, since this a global data , you will have to add more information in each entry telling how the current owner is (as you have shown)etc.The MMU/OS has to take care synchronization.
But the example you have given is not accurate , on a real system with per process page table the entire address can accessed, in your case process p1 has 4 pages and p2 has different set of pages. In reality both process can access same virtual address , mapped to different physical frame.So each table in your must have had 8 entries each.
The page table has to be on one block (you get the pages as in an array).
You get 2 things from inverted table.
The dir table is getting smaller, for example, instead of 2^20 table size and offset of 2^12, you get, 2^10 dir table size.
Then instead of getting (2^20) * (2^2) Bytes memory for the page table, most of the pages would be mapped in the disk and you'll get it allocated only if a process needs them.
In your case, instead of all process will have a page table of the size of 2^20 * 2^2 Bytes, you'll have only 2^10 * 2^2 Bytes for the dir table and another one 2^10 * 2^2 Bytes for the page table. that is a big difference, instead of 2^22 Bytes, you have 2^13.
I hope it was clear.
The inverted page table is smaller because its size depends on the memory size instead of the virtual address space size. If the virtual address space is 2^48, you could have 2^36 page table entries per process.
With inverted page tables, the number of page table entries is only dependent on the size of memory. Say you have 4GB of memory, then your inverted page table would have 2^32 - 2^12 = 2^20 entries. This is for any amount of processes too.