问题描述
我有一个疑问，当每个进程都有它自己的独立的页表那么为什么会出现š需要全系统的页表？此外，如果页面表是这样的，它的虚拟地址映射到物理地址，然后我认为两种工艺可映射到相同的物理地址，因为所有处理具有相同的虚拟地址空间。系统范围内的页表的很好的链接也将解决我的问题？
每个进程都有自己独立的虚拟地址空间 - 两个过程可以有virtpage 1映射到不同的physpages。进程可以参与共享存储器，在这种情况下，它们各自具有一些virtpage映射到同一physpage。
一个进程的虚拟地址空间可用于virtpages映射到physpages，存储器映射文件，装置等Virtpages不必被连接到RAM中。一个进程可以内存映射整个1GB的文件 - 在这种情况下，它的物理内存使用率可能只是一对夫妇兆，但它的虚拟地址空间使用率会1GB或以上。许多过程可能做到这一点，在这种情况下，虚拟地址空间使用的所有进程的总和可能是，比方说，40 GB，而总的物理内存的使用可能是唯一的，比方说，100兆;这是很容易在32位系统上做的。
由于大量进程加载相同的库，操作系统通常使在一组只读可执行页面的库，然后加载在virtpage空间映射为每个进程以指向一组网页，以保存在物理内存中。
进程可能有virtpage映射如果进程的内存的一部分，得到了写入页面文件不指向任何东西，例如 - 该过程将尝试访问该页面时，CPU会触发一个页面错误，操作系统会看到页面故障，并通过暂停过程中，阅读页面回从页面文件RAM，然后恢复的过程中处理它。
有典型的3种类型的页面错误。第一种类型是，当CPU不具有在TLB的虚拟 - 物理映射 - 所述处理器调用OS中的页缺失软件中断时，OS把映射到所述处理器以用于此过程中，则在proc重新运行违规说明。这些发生数千次。
第二种类型是时OS没有映射，因为，比方说，该进程的存储器已被交换到磁盘，如上所述。这些轻载机上很少发生，但内存pressure更经常发生增加，可达数百至1000次每秒，甚至更多。
第三类是当操作系统没有映射，因为映射不存在 - 进程正试图访问一个不属于它的内存。这产生一个段错误，通常，该进程被终止。这些都是不应该经常发生，而仅仅依赖于软件如何写得很好，是在机器上，并且没有任何与计划或机器负载。
即使你已经知道了，我想我扔在了社区。
I have a doubt when each process has it's own separate page table then why is there s system wide page table required ? Also if Page table is such that it maps virtual address to a physical address then I think two process may map to same physical address because all process have same virtual address space . Any good link on system wide page table will also solve my problem?
Each process has its own independent virtual address space - two processes can have virtpage 1 map to different physpages. Processes can participate in shared memory, in which case they each have some virtpage mapping to the same physpage.
The virtual address space of a process can be used to map virtpages to physpages, to memory mapped files, devices, etc. Virtpages don't have to be wired to RAM. A process could memory-map an entire 1GB file - in which case, its physical memory usage might only be a couple megs, but its virtual address space usage would be 1GB or more. Many processes could could do this, in which case the sum of virtual address space usage across all processes might be, say, 40 GB, while the total physical memory usage might be only, say, 100 megs; this is very easy to do on 32-bit systems.
Since lots of processes load the same libraries, the OS typically puts the libs in one set of read-only executable pages, and then loads mappings in the virtpage space for each process to point to that one set of pages, to save on physical memory.
Processes may have virtpage mappings that don't point to anything, for instance if part of the process's memory got written to the page file - the process will try to access that page, the CPU will trigger a page fault, the OS will see the page fault and handle it by suspending the process, reading the pages back into ram from the page file and then resuming the process.
There are typically 3 types of page faults. The first type is when the CPU does not have the virtual-physical mapping in the TLB - the processor invokes the pagefault software interrupt in the OS, the OS puts the mapping into the processor for that process, then the proc re-runs the offending instructions. These happen thousands of times a second.
The second type is when the OS has no mapping because, say, the memory for the process has been swapped to disk, as explained above. These happen infrequently on a lightly loaded machine, but happen more often as memory pressure is increased, up to 100s to 1000s of times per second, maybe even more.
The third type is when the OS has no mapping because the mapping does not exist - the process is trying to access memory that does not belong to it. This generates a segfault, and typically, the process is killed. These aren't supposed to happen often, and solely depend on how well written the software is on the machine, and does not have anything to do with scheduling or machine load.
Even if you already knew that, I figured I throw that in for the community.
这篇关于虚拟地址到物理地址的映射的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！