Following is a page table -
enter image description here
Assume that a page is of size 16000 bytes. How do I calculate the physical address for say the logical address 1000.
Here is what I have worked out yet.
Logical memory = 8 pages
Logical memory size = 8 x 16000 bytes
Physical memory = 8 frames
physical memory size = 8 x 16000 bytes
Now given a logical address of 1000 it will map to the first page which is in frame 3
so considering frame0, frame1, frame2 all of 16000 x 3 bytes.
1000 will be at location 16000 x 3 + 1000
so the physical address will be = 49000 byte
Is this a correct approach?
Is this a correct approach?
Yes. To clarify:
Given a logical address; split it into pieces like:
offset_in_page = logical_address % page_size;
page_table_index = logical_address / page_size;
Then get the physical address of the page from the page table:
physical_address_of_page = page_table[page_table_index].physical_address = page_table[page_table_index].frame * page_size;
Then add the offset within the page to get the final physical address:
physical_address = physical_address_of_page + offset_in_page;
Notes:
a CPU (or MMU) would do various checks using other information in the page table entry (e.g. check if the page is present, check if you're writing to a "read-only" page, etc). When doing the conversion manually you'd have to do these checks too (e.g. when converting a logical address into a physical address the correct answer can be "there is no physical address because the page isn't present").
modulo and division (and multiplication) are expensive. In real hardware the page size will always be a power of 2 so that the modulo and division can be replaced with masks and shifts. The page size will never be 16000 bytes (but may be 16384 bytes or 0x4000 bytes or "2 to the power of 14" bytes, so that the CPU can do offset_in_page = logical_address & 0x3FFF; and page_table_index = logical_address >> 14;). For similar reasons, page table entries are typically constructed by using OR to merge the physical address of a page with other flags (present/not preset, writable/read-only, ...) and AND will be used to extract the physical address from a page table entry (like physical_address_of_page = page_table[page_table_index] & 0xFFFFC000;) and there won't be any "frame number" involved in any calculations.
for real systems (and realistic theoretical examples) it's much easier to use hexadecimal for addresses (to make it easier to do the masks and shifts in your head = e.g. 0x1234567 & 0x03FFFF = 0x0034567 is easy). For this reason (and similar reasons, like determining location in caches, physical address routing and decoding in buses, etc) logical and physical addresses should never be use decimal.
for real systems, there's almost always multiple levels of page tables. In this case approach is mostly the same - you split the logical address into more pieces (e.g. maybe offset_in_page and page_table_index and page_directory_index) and do more table lookups (e.g. maybe page_table = page_directory[page_directory_index].physical_address; then physical_address_of_page = page_table[page_table_index].physical_address;).
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?
I am having hard time calculating the page size as from below link:
http://www.embedded-bits.co.uk/2011/mmucode/
As we know page table entries in this table are 4 bytes long and that there is a maximum of 4096 entries (one for each 1MB of the address space) we can calculate the size of the table as 16KB
Now total size of page table is 4096 entries * 4 bytes wide entry = 16384 bytes = 16kb
But as from above statement each of the 4096 entry corresponds to 1 Mb of address space, that means 1 entry = 1MB .
Since there are 4096 entries, space required to store it is 4096MB but we have page table size of 16kb only.
Also, how many virtual address this 1mb of section has, 250000?
EDIT:
Sorry, if its going to be more stupid from my end. I tried to understand it again. This 1 Mb of section is part of Physical memory not the virtual memory/page table(which I understood earlier).
Now each entry is 4 Bytes longs, does it means 4 virtual addresses are going to cover 1 Mb of Physical Memory section ?
Not quite sure what the question is asking but in a typical AArch32 MMU (barring the newer extensions), you would have first and second level translation tables in a typical configuration.
The first level translation table splits the entire address space into 1MB sections and typically contain pointers to level 2 tables which split those 1MB sections into granular pages (traditionally 4KB on most machines). 2nd level translation tables store physical addresses that correspond to those virtual addresses (each entry stores a physical address along with some flags). The virtual address is determined by its position within the L1 and L2 tables. To further clarify, all addresses stored in page tables (including addresses to L2 tables in the L1 table) are physical.
The first level translation table has a fixed size but depending on which architecture you're running you can change its size (this is used by a lot of ARM kernels to provide a user/kernel address space split). Each gigabyte of virtual memory space requires 4096 bytes in the L1 table at 4096 byte page size.
To even further clarify as far as I remember you can use L1 entries to map 1MB chunks directly without using L2 tables, the type of L1 entry is denoted by lower bits of it.
(Sorry if I got the unit suffixes wrong)
I found this example.
Consider a system with a 32-bit logical address space. If the page
size in such a system is 4 KB (2^12), then a page table may consist of
up to 1 million entries (2^32/2^12). Assuming that
each entry consists of 4 bytes, each process may need up to 4 MB of physical address space for the page table alone.
What is the meaning of each entry consists of 4 bytes and why each process may need up to 4 MB of physical address space for the page table?
A page table is a table of conversions from virtual to physical addresses that the OS uses to artificially increase the total amount of main memory available in a system.
Physical memory is the actual bits located at addresses in memory (DRAM), while virtual memory is where the OS "lies" to processes by telling them where it's at, in order to do things like allow for 2^64 bits of address space, despite the fact that 2^32 bits is the most RAM normally used. (2^32 bits is 4 gigabytes, so 2^64 is 16 gb.)
Most default page table sizes are 4096 kb for each process, but the number of page table entries can increase if the process needs more process space. Page table sizes can also initially be allocated smaller or larger amounts or memory, it's just that 4 kb is usually the best size for most processes.
Note that a page table is a table of page entries. Both can have different sizes, but page table sizes are most commonly 4096 kb or 4 mb and page table size is increased by adding more entries.
As for why a PTE(page table entry) is 4 bytes:
Several answers say it's because the address space is 32 bits and the PTE needs 32 bits to hold the address.
But a PTE doesn't contain the complete address of a byte, only the physical page number. The rest of the bits contain flags or are left unused. It need not be 4 bytes exactly.
1) Because 4 bytes (32 bits) is exactly the right amount of space to hold any address in a 32-bit address space.
2) Because 1 million entries of 4 bytes each makes 4MB.
Your first doubt is in the line, "Each entry in the Page Table Entry, also called PTE, consists of 4 bytes". To understand this, first let's discuss what does page table contain?", Answer will be PTEs. So,this 4 bytes is the size of each PTE which consist of virtual address, offset,( And maybe 1-2 other fields if are required/desired)
So, now you know what page table contains, you can easily calculate the memory space it will take, that is: Total no. of PTEs times the size of a PTE.
Which will be: 1m * 4 bytes= 4MB
Hope this clears your doubt. :)
The page table entry is the number number of bits required to get any frame number . for example if you have a physical memory with 2^32 frames , then you would need 32 bits to represent it. These 32 bits are stored in the page table in 4 bytes(32/8) .
Now, since the number of pages are 1 million i.e. so the total size of the page table =
page table entry*number of pages
=4b*1million
=4mb.
hence, 4mb would be required to store store the table in the main memory(physical memory).
So, the entry refers to page table entry (PTE). The data stored in each entry is the physical memory address (PFN). The underlying assumption here is the physical memory also uses a 32-bit address space. Therefore, PTE will be at least 4 bytes (4 * 8 = 32 bits).
In a 32-bit system with memory page size of 4KB (2^2 * 2^10 B), the maximum number of pages a process could have will be 2^(32-12) = 1M. Each process thinks it has access to all physical memory. In order to translate all 1M virtual memory addresses to physical memory addresses, a process may need to store 1 M PTEs, that is 4MB.
Honestly a bit new to this myself, but to keep things short it looks like 4MB comes from the fact that there are 1 million entries (each PTE stores a physical page number, assuming it exists); therefore, 1 million PTE's, which is 2^20 = 1MB. 1MB * 4 Bytes = 4MB, so each process will require that for their page tables.
size of a page table entry depends upon the number of frames in the physical memory, since this text is from "OPERATING SYSTEM CONCEPTS by GALVIN" it is assumed here that number of pages and frames are same, so assuming the same, we find the number of pages/frames which comes out to be 2^20, since page table only stores the frame number of the respective page, so each page table entry has to be of atleast 20 bits to map 2^20 frame numbers with pages, here 4 byte is taken i.e 32 bits, because they are using the upper limit, since page table not only stores the frame numbers, but it also stores additional bits for protection and security, for eg. valid and invalid bit is also stored in the page table, so to map pages with frames we need only 20 bits, the rest are extra bits to store protection and security information.
I'm looking over some exam papers for Operating Systems and I have come across a question which I simply cannot figure out. The memory management scheme is paging
Here is the question:
An operating system that runs on a CPU with a 16 bit address pointer employs a paging memory management scheme with a page size of 1024 bytes.
a) At most how many frames can physical memory contain?
b) Indicate which bits in an address pointer are used for page and offset.
c) A process image of size 3.5K resides in memory. You are given the page table of this process in Figure 1 below. What physical address will the hexadecimal logical address 0x0FCE result in? Show your calculations.
d) How much internal fragmentation does this process produce?
Page Frame
0 4
1 8
2 9
3 6
Figure 1 Process Page Table
Can anybody help me with this ?
A 16bit address bus allows to access 2^16 = 64kB of physical memory. Since on this system you have pages of size 1024B = 2^10, your memory falls into 2^16 / 2^10 = 2^6 physical frames.
Given the previous result, with pages of 1024 = 2^10 bytes, you need 10 bits for accessing any bytes of the page. Thus, the 6 high-order bits ares used for getting the page index from the page table (basically the figure 1 in your homework), and the 10 low-order bits are used for offsetting in that page.
The logical address 0xfce resides in the fourth page because the six high-order bits are 000011b = 3 = 4th page = 0x0c00-0x0fff. Given the page table and assuming the physical memory is sequential, the fourth page maps to the sixth physical frame which start at 1024 * 6 = 0x1800 = 0001100000000000b. The six high-order bits of the page are 000110b, where we add the 10 bits of offset resulting from the previous answer: 000110b << 10 | 0x3ce = 0x1bce.
Since the frame allocation is not sequential (4, 6, 8, 9), the hole between pages 4 and 6 (i.e. 1024B), and the hole between page 6 and 8(i.e. again 1024B), result in physical memory fragmentation.
Hope this help.
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.