I have the following page table of process1 :
Assuming that the paging system works with 16bit addresses and page size is 4k
And I want to convert the logical address 16000 to a physical address .
I'm a little bit new in this topic so go easy on me :
Partial solution : The address 16000 fits cell number 3 in the page table , so I guess
that I need to work with that cell and its stored frame - 2 .
How can I find the offset and the physical address now ?
Thanks
In your case process 1 currently can access upto 4 * 4k bytes of virtual memory.
Generally a process can access upto 4gb of virtual memory(depending on the implementation).
Now the table you have given maps virtual memory to the actual physical address(on RAM).With each entry of page table mapping 4k of memory from virtual to physical space.
So the physical address where the address 16000 corresponds to the 3rd entry of page table which is mapped to the physical address starting from 8192(3*4096) till 12288 (8192+4096).
16000 mod 4096 = 3712(offset).
At an offset of 3172 bytes in the virtual page 2 i.e at an offset of 3172 in physical page 3 ( at address 8192) you find the data corresponding to address 16000.
All these mappings are done by the MMU(memory management unit) for every address access a process makes.
Good link to understand this concept is here.
Cheers :)
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.
Say you were given a Page Size of 6 KB (6144 bytes) and a Virtual Address value of 2309 using the formula: Page = Virtual Address / Page size, which is 0,376 or just 0 is this possible in a real-world situation, thanks in advance?
Pages are integer entities, so there are consecutive page addresses from 0 to maximum number of pages, identical to virtual addresses that exists from 0 to maximum memory size (ignoring canonicality) - Virtual address 2309 is the byte number 2309 in page number 0.
Having said that, virtual page doesn't have to be present and doesn't have to be mapped to physical address, so it is not necessary possible to access any random address in the virtual address range.
Wanted to know how should i be processing the information of converting the virtual address
(0x10002400)
which contains the value floor(n/2^10)
to physical address
Details given are 32 bit address bus
512 KB physical memory and
page size of 32 KB
Contents of a memory location does not impact the virtual to physical address translation.
Your virtual address got 8 hex values, which indicates this is a 32 bit virtual address.
Your physical memory size is 512KB, which means there are 2^19 bytes (512 * 1024 Bytes).
In this case, virtual to physical mapping involves mapping a 32 bit address to a 19 bit address.
In your example, the page size is 32KB, which means there are 16 physical pages (512/32). We need 4 bits to index 16 physical pages.
From the 32 bit virtual address, we use the last 4 bits to index into a physical page. We can use the remainder 28 bits to do the comparison.
There is an structure called "page table" which holds this information.
This is basically a mapping of leading 28 bits (32-4) of the virtual address to the leading 15 bits (19-4) physical address.
In the given example, the virtual address is 0x10002400.
Last 4 bits are represented by hex 0. Therefore the index is 0. So we take the 0th entry from the page table. Then we check if the virtual tag in the page table matches with our virtual tag which is 1000240 (Note: The last hex value is dropped). If the virtual tag in the entry matches 1000240, then we use the physical tag from the 0th entry and construct our physical address by appending the same index, which is zero.
I was reading the dinosaur book on Operating System about memory management. I assume this is one of the best books but there's something about paging written in the book which I don't get.
The book says, "A 32-bit CPU uses 32-bit addresses, meaning that a given process space can only be 2^32 bytes (4 TB ). Therefore, paging lets us use physical memory that is larger than what can be addressed by the CPU’s address pointer length."
I don't quite get this part because if the CPU can only refer to 2^32 different physical addresses, if there were 2^32+1 physical addresses, the last address won't be able to be reached by the CPU. So how can paging help with this?
Also, earlier the book says "Frequently, on a 32-bit CPU , each page-table entry is 4 bytes long, but that size can vary as well. A 32-bit entry can point to one of 2^32 physical page frames. If frame size is 4 KB (2^12 ), then a system with 4-byte entries can address 2^44 bytes (or 16 TB ) of physical memory."
I don't see how that is even possible in ideal/theoretical situations, cuz as I understand it, part of the virtual address will refer to an entry of the page table while the other part of the virtual address will refer to the off-set of that particular type in that page. So in the above-mentioned situation put forward by the book, even if the CPU could point to 2^32 different page entries, it won't be able to read any particular byte within that page cuz it doesn't specify the office.
Maybe I've misunderstood the book or there is some part that I missed out. I much appreciate your help! Thanks a lot!
It sounds like you need to burn your book. It's useless.
"[P]aging lets us use physical memory that is larger than what can be addressed by the CPU’s address pointer length" is complete nonsense (unless the book is assigning two different meanings to the term "paging," in which it is still useless).
Let's start with logical addressing. A logical address is composed of a page selector and and offset into the page. Some number (P) of bits will be assigned to the page selector and the remained will be assigned to the offset. If pages are 2^9 bits, there are 23 bits in the page selector and 9 bits for the byte offset within the page.
Note that the 9/23 pick are arbitrary on my part. Most systems these days use larger pages but these are values have been used in the past.
The 23 bits in the page selector are indices into the process page table.
The size of entries in the page table are going to be a power of 2 (and I have never seen one less than 4). For our purposes let's say that each entry is 8-bytes long.
The bits in the page table entry are divided between those that index physical page frames and control bits. let's make the arbitrary choice that 32 bits index page frames and 32 bits are used for control.
That means the system can theoretically MANAGE 2^32 pages that are 2^9 bytes large or a total of 2^41 bytes. If we were to increase the page size from 2^9 to 2^20, the system could theoretically MANAGE 2^52 (32+20) bytes of memory.
Note that each process can still only ACCESS 2^32 bytes. But in my 9-bit page system, 2^9 processes could each access 2^32 pages simultaneously on a system with 2^41 physical bytes of memory (ignoring the need for a shared system address space in this gross oversimplification).
Note that if I change my page table to 32-bits and assign 9 of those bits to control and and 23 to page frame selection, the system can only MANAGE 2^32 bytes of memory (and that was more common than managing greater than 2^32 bytes).
You quote: "Frequently, on a 32-bit CPU , each page-table entry is 4 bytes long, but that size can vary as well. A 32-bit entry can point to one of 2^32 physical page frames. If frame size is 4 KB (2^12 ), then a system with 4-byte entries can address 2^44 bytes (or 16 TB ) of physical memory."
This is theoretical BS. A system that used all 32 bites of the page table entry as an index to page frames could not function. There would have to be some control bits in the page table.
The quotes you are taking from this book are highly misleading. Few (any?) 32-bit processors could even access 2^32 bytes of memory due to address line limitations.
While it is possible that the use of logical pages could allow a processor to manage more memory that the logical address size suggests, that was not the purpose of managing memory in pages.
The purpose of paging—which in its normal and customary usage refers to the movement of virtual memory pages between physical page frames and secondary storage—is to allow processes to access more virtual memory than there was physical memory on the system.
There is an additional system of memory management that is (thankfully) dying out: segments. Segments also provided a means for systems to manage more physical memory than the logical address space would allow.
Question is here:
Consider a logical-address space of 32 pages with page size 512 words,
mapped onto a physical memory of 128 frames.
I want to know if my attempting calculation below is correct:
so far I have come the:
**
32 pages = 2^5 bits
512 words = 2^9 bits
128 frames = 2^7 bits
**
How to calculate the logical address and physical address if i do not know the word size?
Word size depends on the computer architecture. Generally for a 32 bit CPU the word size is 32 bits(4 bytes) and for 64 bit CPU, it is 64 bits(8 bytes).
* Logical address will be generated by the CPU for a particular proceess, you don't need to calculate anything. As the CPU generates the logical address it will be mapped to physical address by Page Map Table or a fast Cache in Memory management unit(MMU).
* With respect to the details given above, your CPU generates the logical address of 14 bits, so it can address (2^14 words in memory). Assuming your processor is 32 bit, then it can access 2^16 bytes.
* Given the logical address of 14 bits, it looks in the page map table by using the first 9 bits for page. Then it finds the address where the page is actually located in the physical memory and it adds the offset to the physical address to find memory location in the Main memory.