Linux 3/1 虚拟地址拆分答案

【问题标题】：Linux 3/1 virtual address splitLinux 3/1 虚拟地址拆分
【发布时间】：2010-12-12 03:21:09
【问题描述】：

在理解 highmem 需要处理超过 1GB 的 RAM 时，我遗漏了一些东西。有人可以指出我哪里出错了吗？谢谢！

我知道的：

为内核操作保留 1 GB 进程的虚拟内存（高内存区域）。用户空间可以使用剩余的 3 GB。这是 3/1 拆分。
VM 的虚拟内存功能将（连续的）虚拟内存页面映射到物理页面 (RAM)。

我不知道的：

哪些操作使用内核虚拟内存？我想内核空间中的 kmalloc(...) 之类的东西会使用内核虚拟内存。
我认为在这种方案下可以使用 4GB 的 RAM。我不明白为什么内核 1 GB 虚拟空间是寻址物理空间时的限制因素。这就是我的理解崩溃的地方。请指教。

我一直在阅读这篇文章 (http://kerneltrap.org/node/2450)，这很棒。但它并没有完全按照我的喜好解决我的问题。

【问题讨论】：

"使用 32 位，可以寻址 4 GB 的内存。直到最近，32 位系统上的 Linux 一直被限制为比这要少得多的内存，但是，因为它的方式设置虚拟地址空间。” -来自LDD，第13章我想我的问题是，为什么它限制在显着减少内存。

标签： linux linux-kernel virtual-memory

【解决方案1】：

内核虚拟空间是可用物理内存的限制因素的原因是因为内核需要访问所有物理内存，并且它访问物理内存的方式是通过内核虚拟地址。内核不使用允许直接访问物理内存位置的特殊指令——它必须为它想要与之通信的任何物理范围设置页表条目。

在“旧式”方案中，内核进行了设置，以便每个进程的页表将虚拟地址从0xC0000000 直接映射到0xFFFFFFFF 到物理地址从0x00000000 到0x3FFFFFFF（这些页被标记为以便它们只能在环 0 - 内核模式下访问）。这些是“内核虚拟地址”。在这种方案下，内核可以直接读写任何物理内存位置，而无需摆弄 MMU 来更改映射。

在 HIGHMEM 方案下，从内核虚拟地址到物理地址的映射不是固定的——当内核需要访问该内存时，部分物理内存被映射进出内核虚拟地址空间。这允许使用更多的物理内存，但代价是必须不断更改虚拟到物理的映射，这是一项相当昂贵的操作。

【讨论】：

那么在“旧方案”下，内核模式下的任何进程都可以寻址所有物理内存（包括与该特定进程无关的内存）？
是的，绝对可以（而且他们仍然可以——他们有时只需要跳过铁环）。这是必需的 - 例如，在中断发生时正在运行的任何进程的上下文中为中断提供服务。内核有点像一个大的共享库，除了它的代码在提升的特权级别上运行（你不能只是调用它 - 你需要通过一个特殊的入口点来提升特权级别）。跨度>
所以在“旧方案”下，当我执行 kmalloc(...) 时，它会分配内核虚拟内存，这实际上会转化为物理内存——它永远不会被换出磁盘？
@DavidHinkes：是的，事实上在任何一种方案下kmalloc() 内存必须始终映射到虚拟地址。只有像用户空间内存这样的东西才能最终进入 HIGHMEM。

【解决方案2】：

在每个进程中将 1 GB 映射到内核允许进程切换到内核模式，而无需执行上下文切换。然后可以在调用进程的地址空间中适当地处理对read()、mmap() 等系统调用的响应。

如果每个进程没有为内核保留空间，在执行用户空间代码之间切换到“内核模式”会更昂贵，并且无法通过硬件 MMU（内存管理单元）使用虚拟地址映射正在服务的系统调用。

运行具有超过 1GB 物理内存的 32 位内核的系统能够在 ZONE_HIGHMEM 中分配物理内存位置（大约高于 1GB 标记），这可能需要内核跳过某些操作以与之交互他们。 PAE（物理地址扩展）的添加通过允许高达 64GB 的物理内存扩展了这个问题，降低了 1GB 物理地址内存中的内存与ZONE_HIGHMEM 中分配的区域的比率。

【讨论】：

是的，拥有内核虚拟内存的原因很清楚。但是在前 HIGHMEM 时代，为什么内核虚拟内存空间是物理内存寻址的限制因素？

【解决方案3】：

例如系统调用使用内核空间。
您可以拥有 64GB 的物理内存，但在 32 位平台上，由于 32 位虚拟寻址，处理器只能访问 4GB。实际上，您可以拥有 1GB 的 RAM 和 3GB 的交换空间，而虚拟寻址会让您看起来像拥有 4GB。在 64 位平台上，虚拟寻址实际上是无限的。

【讨论】：

1GB 内存和 3GB 交换空间？这没有任何意义......在 32 位机器上，根本不需要交换来达到架构的寻址限制。