operating-system - 存储散列页表的位置

Question

我的理解是我们不能保证大量（大于页面大小）的连续内存。如果页表本身的大小足够大以至于不能存储在 1 页中，那就是一个问题。所以我们再次在页表上进行分页，这就是所谓的多级页表。但是如果地址大于 32 位，多级页表不是一个好的选择，因为更多的平衡会花费大部分计算。

为避免使用此散列页表。

据我了解，散列页表 [indexable] 大小应低于页面大小。因此，对于大地址大小，将会有很多冲突。如果页面大小是 12 位页表，包含 2^52 个条目，哈希表大小将变为 2^12（大约不知道确切的计算），然后每个索引 2^40 大小的链表。那么这将如何可行。所以我的假设是哈希表将使用其他方法或其他地方存储。操作系统概念书对它和其他网站进行了很多解释。

我已阅读操作系统概念第九版第 380 页。

标签： operating-systempaging

Answer 1

我的理解是我们不能保证大量（大于页面大小）的连续内存。

为什么？通常，物理内存管理器必须能够为（某些）设备驱动程序分配物理上连续的缓冲区。

所以我们再次在页表上进行分页，这就是所谓的多级页表。但是如果地址大于 32 位，多级页表不是一个好的选择，因为更多的平衡会花费大部分计算。

为什么？大多数 CPU 使用多级页表；然后有一个 TLB（“翻译后备缓冲区”）以避免在页表中查找内容的成本。现代 80x86 更进一步，并且还具有更高级别的分页结构缓存（除了 TLB）。

据我了解，散列页表 [indexable] 大小应低于页面大小。因此，对于大地址大小，将会有很多冲突。如果页面大小是 12 位页表，包含 2^52 个条目，哈希表大小将变为 2^12（大约不知道确切的计算），然后每个索引 2^40 大小的链表。那么这将如何可行。

事情是; 如果翻译不在哈希表中（例如，由于哈希表大小有限），通常 CPU 会生成一个错误来请求操作系统的帮助，操作系统会计算出翻译并将其推送到哈希表中（在驱逐某些东西之后）否则从哈希表中腾出空间）。当然，操作系统可能会使用自己的多级页表来计算翻译（推入哈希表）；所以整个“哈希表”最终会变成一整层烦人的额外膨胀（与本身支持多级页表的 CPU 相比）。