- Is the page table stored in the kernel? Does this VM structure structure have a page table?
Yes. Not exactly: each process has mm_struct, which contains a list of vm_area_struct (representing abstract processor-independent memory areas, as well as mappings) and a field called pgd , which is a pointer to a page specific to the table processor (which contains the current state of each page: valid, readable, writable, dirty, ...).
The page table does not have to be complete; the OS can generate every part of it from VMA.
- How the MMU cannot find the address in physical memory. Say this translates to the wrong address in RAM. Nevertheless, the code will be executed, but it will be a bad address. How does the MMU ensure that it reads the correct data? Is it carried out each time in the "Core area" field?
Translation is not performed, for example. because the page was marked as invalid, or a write attempt was made against a read-only page.
- Is the mapping table - virtual for the physical - inside the MMU. I read it, which is supported by a separate process. If it is inside the process, why I do not see it. Or, if it is an MMU, then how the MMU generates an address is that the segment + 12-bit offset โ page frame number, and then adding the offset (bits from -1 to 10) โ gives the physical address. Does this mean that for 32-bit architecture, given this calculation in my opinion. I can determine the physical address from the virtual address.
There are two types of MMU in common use. One of them has only TLB (Buffer Lookuside Buffer), which is the page table cache. When the TLB does not have a translation for an access attempt, a TLB miss is generated, the OS executes the page table and places the translation in the TLB.
Another type of MMU maintains a page table in hardware.
In any case, the OS maintains a page table for each process; it maps virtual page numbers to physical frame numbers. This display can change at any time when the page is unloaded, the physical frame that it displays depends on the availability of free memory.
- cat / proc / pid_value / maps. This shows me the current vmarea display. Basically, he reads the Vmarea structure and prints it. This means that it is important. I canโt fit this piece into the big picture. When the program is executed, a vmarea structure is created. Is VMAREA only in the picture when the MMU cannnot translate an address, such as a page error? When I print vmarea, it displays the address range, resolution, and maps to file descriptor and offset. I am sure that this file descriptor is the one on the hard drive and the offset for this file.
In a first approximation, yes. In addition, there are many reasons why the kernel may decide to play in the process memory, for example: if there is pressure in the memory, it may decide to publish some rarely used pages from some random process. User space can also manipulate mappings through mmap() , execve() and other system calls.
- The concept of high-mem is that the kernel cannot directly access memory areas larger than 1 GB (approximate). Thus, for an indirect map, he needs a page table. Thus, it will temporarily load some page table for address mapping. Will HIGH MEM enter the image every time. Because Userpace can directly translate the address through the MMU. In what scenario does the kernel really want to access High MEM. I believe that kernel drivers will mainly use kmalloc. This is a direct memory address + offset. In this case, matching is really not required. So, the question is, in which scenario should the kernel access High Mem.
Not fully related to other issues. Thus, high memory is a hack that allows you to access a large amount of memory on a limited computer with address space.
Basically, the kernel has a limited address space reserved for it (on x86, the typical user / kernel separation is 3Gb / 1Gb [processes can run in user space or in kernel space). The process runs in kernel space when syscall is called. To avoid having to switch the page table to each context switch, on x86 the address space is usually split between user space and kernel space]). Thus, the kernel can directly access ~ 1 GB of memory. In order to gain access to more physical memory, there is some indirect orientation, which is what makes large memory.
- Is the processor specifically supported with MMU support? Those who do not have MMU support cannot run Linux?
Notebook / desktop processors come with an MMU. x86 supports paging with 386.
Linux, especially an option called ฮผCLinux, supports processors without MMU (! MMU). Many embedded systems (ADSL routers, ...) use processors without MMUs. There are some important limitations, among which are:
- Some system calls do not work at all: for example,
fork() . - Some system calls work with restrictions and non-POSIX-compliant behavior: for example,
mmap() - The format of the executable is different: for example, bFLT or ELF-FDPIC instead of ELF.
- The stack cannot grow, and its size must be set during the connection.
When the program loads first, will the kernel install the VM-Area kernel for this process? This area of โโthe kernel VM actually contains the place where the program sections are located in the memory / HDD. Then the whole history of updating the CR3 register and passing a page or TLB gets into the picture correctly? So, whenever there is a file_file - the kernel updates the page table by looking at the kernel virtual memory area, right? But they say that the Kernel core area continues to be updated. How is this possible since cat / proc / pid_value / map will continue to be updated. The card will not be constant from start to finish. SO, is real information available in the structure of the kernel VM area? This is actual information, where is the program section, can it be a hard disk or physical memory - RAM? So, it fills up at boot time, is this the first job? The kernel displays the page on page on the error page and updates the kernel VM area, right? So, he also needs to know the entire location of the program on the hard drive to enter the page / page to the right? Please correct me here. This is a continuation of my first question about a previous comment.
When the kernel loads the program, it will install several VMAs (mappings) according to the segments of the executable file (which can be seen in the ELF files using readelf --segments ), which will be a text / code segment, data segment, etc. During the life of the program, additional mappings can be created by dynamic / runtime linkers, using the memory allocator ( malloc() , which can also expand the data segment via brk() ), or directly through the program via mmap() , shm_open() , etc. .d.
VMAs contain the necessary information to create a page table, for example. they report whether this memory is supported by file or by exchange (anonymous memory). So, yes, the kernel will update the page table by looking at VMA. The kernel will be displayed in memory in response to page errors and will remove the memory from memory in response to memory pressure.
Using x86 no PAE as an example:
On x86 without PAE, the linear address can be divided into 3 parts: the upper 10 bits indicate the entry in the page directory, the middle 10 bits indicate the entry in the page table, which indicates the above page in the directory entry. The entry in the page table may contain a valid physical frame number: the upper 22 bits of the physical address. The bottom 12 bits of the virtual address are the offset on the page, which does not translate into a physical address.
Each time the kernel schedules another process, the CR3 register is written with a pointer to the page directory for the current process. Then, every time a memory access occurs, the MMU tries to search for a translation cached in the TLB, if it does not find it, it searches when you make page table transitions starting with CR3. If it still does not find it, a GPF error occurs, the CPU switches to Ring 0 (kernel mode), and the kernel tries to find it in VMA.
In addition, I believe that this is a reading from CR, page directory-> page-table-> Page frame number-memory address this is all done by MMU. Am I right?
On x86, yes, the MMU maintains a page table. In other systems (for example, MIPS), the MMU is a bit more than TLB, and with the exception of TLB moments, the kernel executes the page table using software.