作为虚拟地址到物理地址转换的一部分，对于每个过程，都会存储虚拟地址到物理地址之间的映射表。如果下一个进程被调度，则页表的内容将被加载到MMU中。
1）每个进程的页表存储在哪里？作为过程控制块的一部分？
2）页表是否包含未分配内存的条目，以便可以（更容易）检测到段错误？
3）一个进程是否可能具有多个页面框架大小（并在任何已知的相关OS中使用）？特别是如果问题2是正确的，将巨大的页表映射到不存在的内存以使页表尽可能小非常方便。仍然可以在将较小的帧映射到内存中时保持较高的精度，以保持外部（和内部）碎片尽可能小？当然，这需要一个额外的字段来存储每个条目的帧大小。请指出我的“想法”不存在的原因。
1）可能是，但是大多数OS都有一个进程附加到的地址空间的概念。地址空间通常包含对已建立的映射种类的描述，以及指向页面结构的指针。如果考虑exec（2）的操作，则在某种抽象级别上，它仅涉及创建一个新的地址空间，填充它，然后将进程附加到它。一旦知道该操作成功完成，就可以简单地丢弃旧的地址空间。
2）取决于计算机的mmu体系结构。在前向映射的安排中（x86，armv [78]），页表形成一种树结构，但是不是每个节点具有常规的2或3个项，而是有成百上千的项。 x86-classic具有2级结构，其中第一级的1024个条目中的每一个都指向一个覆盖2 ^ 20字节地址空间的页表。内部或叶级别的无效条目都可能表示未映射的空间。因此在x86-classic中，如果您的地址空间很小，则只需要一个根表和一个叶级表即可。
3）是，自2000年代初以来，大多数操作系统都支持多种页面大小。同样，在前向映射的树中，树的每个层都可以由单个大页面代替与该表层相同的地址空间。 x86-classic只有一个大小；更高版本支持更多。
3a）不需要使用大页面来执行此操作-仅具有无效的页面表就足够了。在x86-classic中，页表/描述符条目的最低有效位指示该条目的有效性。
您的想法存在。
1）每个进程的页表存储在哪里？作为过程控制块的一部分？
通常不是“页表”。对于某些CPU，只有TLB条目（翻译后备缓冲区条目-类似于翻译内容的缓存），软件必须通过将“ TLB缺失”加载到TLB本身中来处理“ TLB丢失”，并且操作系统可能不使用表根本（例如可以使用“任意长度区域列表”）。对于某些CPU，它是一个多级的层次结构（例如，对于现代64位80x86，有4级）；在这种情况下，某些级别可能位于物理内存中，而某些级别可能位于交换空间或其他地方，而某些级别可能根据需要从其他数据中生成（有点像“ TLB遗漏的软件处理” ”）。无论如何，如果每个进程都有自己的虚拟地址空间（例如，它不是某种“许多进程共享的单地址空间”方案），则进程控制块（直接或间接）可能包含对任何内容的引用OS使用（例如，单个“最高级别页表的物理地址”，但“任意长度区域列表”的虚拟地址，可能还有其他）。
2）页表是否包含未分配内存的条目，以便可以（更容易）检测到段错误？
如果存在页表，那么必须有一种方法来指示“页面不存在”，其中“页面不存在”可能意味着未分配内存，但也可能意味着已分配了（虚拟）内存，但是尚未设置它的条目（因为操作系统正在按需生成表，或者因为实际数据在交换空间中，或者...）。
3）一个进程是否可能具有多个页面框架大小（并在任何已知的相关OS中使用？）>
是。对于64位80x86，这种情况相对常见，其中有4个KiB页面，2个MiB（或4个MiB）“大页面”（也许还有1个GiB“大页面”）；并且可以减少TLB丢失的机会（同时还可以减少页表占用的内存）。请注意，这主要是具有多个级别的页表的产物-较高级别的表中的条目可以说“此条目是大页”，也可以说“此条目是可能包含较小页面的较低级别的页表” ”。请注意，在这种情况下，它不是“同一表中的多个页面大小”，而是“每个级别的固定页面大小”。
特别是如果问题2是正确的，将巨大的页表映射到不存在的内存以使页表尽可能小非常方便。仍然可以在将较小的帧映射到内存中时保持较高的精度，以保持外部（和内部）碎片尽可能小？当然，这需要一个额外的字段来存储每个条目的帧大小。请指出我的“想法”不存在的原因。
将虚拟地址转换为物理地址（或某种表示转换不存在的错误）需要非常快（因为它经常发生）。当您具有“每个级别的固定页面大小”时，这意味着您可以提取虚拟地址的某些位并将其用作表的索引；很快。
[当您在同一张表中有多个页面大小时，有2个选项。第一种选择是复制页表中的条目，以便您仍可以提取虚拟地址的某些位并将其用作表的索引； （除了在管理TLB的方式上存在细微的差异-例如自动检测相邻翻译与手动告知外）实际上是相同的，根本不会打扰；但是有一些CPU（我认为是ARM）可以做到这一点。
另一种选择是在页表中搜索多个条目以找到正确的条目，搜索成本降低了性能。我不知道有哪个CPU支持此功能-性能太重要了。