Memory 反向页面表如何处理访问同一帧的多个进程

我看过其他文章，但没有一篇文章有相同的问题，因此据我所知，反转页表的条目取决于进程id和虚拟页码，在实际页表中，如果进程id和虚拟页码的信息都匹配，那么索引就是物理页码/帧编号。我的问题是当超过1个进程需要该帧/物理内存时会发生什么情况。您不能将id或vpn存储在同一个索引中

有趣的问题！我的猜测是，这是倒页表不太流行的原因之一

一种解决方案是在每个条目中附加一个“共享”位，并为每个pid创建一个哈希表。当遇到具有“共享”位集的页面帧时，MMU应触发一个故障，该故障将导致操作系统使用请求进程的pid和虚拟地址索引到哈希表中。此时，其行为与全局哈希表相同，其中哈希条目包含对

这样做的好处是，我们仍然可以在页面表条目中使用pid字段，因此会命中1个共享pid

一些缺点是每个pid的哈希表可能与全局哈希表的大小相同，因此我们有效地将全局哈希表的大小增加了2^16（或者无论支持多少个pid）！当然，每个pid的哈希表可能不会太大，因此我们可以根据使用的条目数量动态更改大小。但是，这也有其自身的副作用，我们可能需要在需要增加页面大小时逐出其他页面

---

我相信还有更好的解决方案，我很想听听。

另一种可能的解决方案：

向页表条目添加“重新映射”位。如果页表条目设置了此“重新映射”位，则给定的物理地址不是实际的物理地址，而是重新映射表的索引。重映射表是一种软件控制的数据结构，包含从索引到物理地址的映射。它由所有进程共享，因为页表条目已经具有pid。重映射表的大小是动态的；重映射表可以驻留在由重映射表基址寄存器指向的连续内存中的任何位置。重映射表尾部寄存器跟踪重映射表的顶部，该顶部可以增加或减少

创建全新的共享页表条目时，应将其创建为带有pid、物理地址和虚拟地址的标准页表条目。当其他进程为这个共享物理地址请求一个页面时，它们应该创建一个页面表条目，其中设置了“remap”位，并且物理地址指向它们的remap表条目。软件可以通过从底部到尾部搜索任何可用条目来确定重新映射表条目。如果没有找到，软件应该增加尾部指针，如有必要，收回驻留在那里的页面。此重新映射表条目应包含共享页的物理地址

删除共享页表时，软件应删除重新映射表项。如果要删除的重映射表项位于重映射表的顶部，软件应减少指向最高有效项的重映射表指针。

最简单的解决方案：

---

只需为共享同一页表的所有进程创建另一个页框条目。它们应该具有特定于该进程的pid和虚拟地址，以及与共享页面相同的物理页面帧号。此页表条目应该有一个“共享”位，指示它可以/正在与其他进程共享，并且在退出时应该写回磁盘。这样，当删除每个进程的页表条目时，它们都会将共享页的内容写回磁盘。这将导致n-1（n是共享页面的进程数）“浪费”回写，但它避免了试图跟踪共享页面的所有进程的开销。

一个简单的解决方案是只将一个虚拟地址映射到页面表中的共享物理地址，因此，映射到相同共享物理地址的其他虚拟地址引用将导致页面错误