Results 1 to 10 of 19
During runtime when a program asks for a memory block (say, by malloc()), its provided with a block of virtual addresses, say 0x10000000 to 0x1000A00 (for 32 bit). During the ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 06-16-2010 #1
- Join Date
- May 2010
[SOLVED] When page's retrieved from swap, how does its application know new virtual a
During runtime when a program asks for a memory block (say, by malloc()), its provided with a block of virtual addresses, say 0x10000000 to 0x1000A00 (for 32 bit). During the execution, other processes are incorporated into the main memory and pages 0x10000000-0x100000A0 are paged out. After some time, the program requests the page 0x10000000. Its incorporated back into the main memory (at the cost of some other page) but its assigned a new virtual address, but the program is oblivious of the new virtual address assigned to it and references the it using 0x10000000. How is this problem resolved ? Does it proceed in any other way ?
- 06-16-2010 #2
To my understanding, the virtual addresses stay the same for a given process.
The kernel will map them to real ram or swap.
These real addresses can change and the kernel keeps track, where a give virtual address for each process is at any given time.You must always face the curtain with a bow.
- 06-16-2010 #3
- Join Date
- May 2010
But that would imply that if all of 2^32 addresses in the virtual memory page table fill up, and none of the process has ended, no more processes can be accomodated in the RAM (as there are no more virtual addresses to assign the new process and each page, whether its in the memory or in the swap space, is still assigned a unique virtual address)
Also, if a process allocated 20 pages (say 0-19) finishes, and a new process comes requiring 70 pages. The virtual page table has to assign these 20 pages (0-19) to it and then leave a lot of pages in between and then assign pages (say, 2000-2049) to it. Thus, the virtual addresses allocated to the process will not remain consecutive. This will be a problem, I think. Does it happen so that if the kernel can't find all 70 pages contiguously, it denies allocating the process any pages and hence a place in the main memory.
- 06-16-2010 #4
Let's imagine a process. It has some set of memory divided into pages. Let's look at page 0. This page holds some amount of memory, we'll imagine that it contains the first 256 bytes, so it holds memory addresses 0x0 - 0xFF.
However, this is a lie! The process thinks that it is accessing address page 0, but it is not: it might be asking for physical page 8. The MMU, when asked for a particular byte, uses a set of data called page tables to map a "virtual" byte into the actual physical address, which could be anything at all (we'll pretend it's on page 8).
Now, eventually, this page might get swapped out. At this point, the mapping is erased from the page table. The next time that the process requests its page 0, the MMU will see that it has no mapping, so it will page fault and the CPU will get the data from swap. However, it might write this data to ANY page. Earlier, it was on page 8, but the CPU decides to put it on page 3 this time (because page 3 is available). So in the page table, a new mapping is created: the process's page 0 now maps to physical page 3.
Although virtual pages appear to be contiguous, the physical pages do not need to be so. So virtual pages 0 and 1 are accessed as though they are next to each other, but the physical pages that they are mapped to might be 13 and 2, or anything. No guarantees can be made. In fact, it is almost guaranteed that your virtual memory will be split up among separate physical pages.
Also recall that every process has its own set of page tables. So every process has its own set of 2^32 addresses that have independent mappings. When the CPU switches from one process to another, the page tables are wiped, and all pages need to be re-mapped, which makes changing from one process to another very expensive.
- 06-17-2010 #5
- Join Date
- May 2010
Thanks a ton! I have one doubt though.
Suppose the contents of page 0 are swapped out and are replaced by some other data, when the process references page 0 by the virtual address 0x00000000, it'll not be knowing that the original contents of page 0 have been swapped out. Since it uses virtual addresses (since virtual addresses don't disappear, how can the process know that its a page fault), how can it know that the value at that virtual address is the original one or has been replaced.
- 06-17-2010 #6
Memory management unit - Wikipedia, the free encyclopedia), this means that the translation happens pretty transparently for the software. When a page is found to be swapped out, the hardware notifies the kernel, which then brings the page in.
Please note that, in the ideal situation, no one can replace the value at a virtual address belonging to the memory space of a certain process, because only the kernel and the process itself have access to this (virtual) memory space.
- 06-17-2010 #7
- Join Date
- May 2010
Isn't virtual memory infinite (all processes can be assigned 2GiB)
Thanks. All this time, by page I was understanding the pages in the virtual memory table, though the pages in the memory were meant.
So, I get these things :
1. Any process larger than 2GiB can't be accommodated since each process is given only 2GiB virtual addresses.
2. If the swap space as well as the main memory gets filled up, the kernel gives an error saying "Virtual memory is low" (Actually, shouldn't it say that "swap is too small" as virtual memory is infinite)
3. The reason swap space is maintained is that if a page fault occurs, the page is first located in the swap space as compared to searching the entire hard disk. If its not found there, then the remaining hard disk is checked. This checking, though occurs just for the first time when the process is being loaded, because otherwise, the only reason for the page to be not present in either the swap or the main memory is that it has ended or the process has been killed.
4. Even when a process swaps out of the memory, the page table for that process does keep some info about where that page is in the swap
5. I take it that "increasing virtual memory" is actually a misnomer because virtual memory is infinite. What is meant is increasing the swap space.
Am I right?
- 06-17-2010 #8
As for the OS not finding a page in the swap, I cannot imagine a situation when this may happen, except for attempts to read or write using virtual addresses in ranges not specifically allocated before. In this case, you get something like a segfault and the OS does not "search the entire disk".
When a process exits or is killed, the OS deallocates all pages that were allocated for it.
Thus the swap space is a cheap but slow extension of the main memory. The principal purpose of the swap is to (temporarily) store memory pages which don't fit within the main memory.
Not sure whether this makes you feel your statement is confirmed.
- 06-17-2010 #9
- Join Date
- Feb 2005
How it really works
This is really pretty simple. When a process is running, each fetch from virtual memory goes through a translation table loaded into the physical CPU hardware registers. This is called a Translation table (TLB for Intel and AMD hw). This table is part of the processes' context and is stored in a data structure within the kernel. So when User A gets to run it's translation table is either loaded into the Translation table HW in the CPU fully or dynamically. So when an address is translated and there is NO valid entry in the Translation Table the OS takes a fault. If the entry is in a data structure in the kernel then it's loaded into the Translation Table, if not it becomes a page fault. Then the Page Fault goes out to disk to fetch the page into memory. When that happens the users (Process) translation table in Kernel is updated. When that user gets swapped back in then the translation happens and the process continues.
You are also confusing Virtual Memory with Swap space. Virtual memory is a scheme created by the HW manufacturer. OS's conform to that structure. Usually Swap space contains data only. Because the executables are non writable and don't need to be saved there is no need to fetch them from Swap.
- 06-17-2010 #10