Note that there are some explanatory texts on larger screens.

plurals
  1. PODoes Virtual Memory area struct only comes into picture when there is a page fault?
    text
    copied!<p>Virtual Memory is a quite complex topic for me. I am trying to understand it. Here is my understanding for a 32-bit system. Example RAM is just 2GB. I have tried reading many links, and I am not confident at the moment. I would like you people to help me in clearing up my concepts. Please acknowledge my points, and also please answer for what you feel is wrong. I have also a confused section in my points. So, here starts the summary.</p> <ol> <li><p>Every process thinks it is only running. It can access the 4GB of memory - virtual address space.</p></li> <li><p>When a process access a virtual address it is translated to physical address via MMU. This MMU is a part of a CPU - a hardware. </p></li> <li><p>When the MMU cannot translate the address to a physical one, it raises a page fault. </p></li> <li><p>On page fault, the kernel is notified. The kernel check the VM area struct. If it can find it - may be on disk. It will do some page-in /page-out. And get this memory on the RAM.</p></li> <li><p>Now MMU will again try and will succeed this time. </p></li> <li><p>In case the kernel cannot find the address, it will raise a signal. For example, invalid access will raise a SIGSEGV.</p></li> </ol> <p>Confused points.</p> <ol> <li><p>Does Page table is maintained in Kernel? This VM area struct has a page table ?</p></li> <li><p>How MMU cannot find the address in physical RAM. Let's say it translates to some wrong address in RAM. Still the code will execute, but it will be a bad address. How MMU ensures that it is reading a right data? Does it consult Kernel VM area everytime?</p></li> <li><p>Is the Mapping table - virtual to physical is inside a MMU. I have read it that is maintained by an individual process. If it is inside a process, why I can't see it. Or if it is MMU, how MMU generates the address - is it that Segment + 12-bit shift -> Page frame number, and then the addition of offset (bits -1 to 10) -> gives a physical address. Does it mean that for a 32-bit architecture, with this calculation in my mind. I can determine the physical address from a virtual address. </p></li> <li><p>cat /proc/pid_value/maps. This shows me the current mapping of the vmarea. Basically, it reads the Vmarea struct and prints it. That means that this is important. I am not able to fit this piece in the complete picture. When the program is executed does the vmarea struct is generated. Is VMAREA comes only into the picture when the MMU cannnot translate the address i.e. Page fault? When I print the vmarea it displays the address range , permission and mapped to file descriptor, and offset. I am sure this file descriptor is the one in the hard-disk and the offset is for that file. </p></li> <li><p>The high-mem concept is that kernel cannot directly access the Memory region greater than 1 GB(approx). Thus, it needs a page table to indirectly map it. Thus, it will temporarily load some page table to map the address. Does HIGH MEM will come into the picture everytime. Because Userspace can directly translate the address via MMU. On what scenario, does kernel really want to access the High MEM. I believe the kernel drivers will mostly be using kmalloc. This is a direct memory + offset address. In this case no mapping is really required. So, the question is on what scenario a kernel needs to access the High Mem. </p></li> <li><p>Does the processor specifically comes with the MMU support. Those who doesn't have MMU support cannot run LInux?</p></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload