Linux内核的内存限制

Question

我有一个令人困惑的问题。我有一个使用sg执行自定义 CDB的库。有几个系统通常会在sg 中出现内存分配问题。通常，sg驱动程序有大约 4mb 的硬限制，但我们在这些具有 ~2.3mb 请求的少数系统上看到它。也就是说，CDB 正准备分配 2.3mb 的传输。这里不应该有任何问题：2.3 < 4.0。

现在，机器的配置文件。它是一个 64 位 CPU，但运行 CentOS 6.0 32 位（我没有构建它们，也与这个决定没有任何关系）。这个 CentOS 发行版的内核版本是 2.6.32。他们有 16GB 的内存。

以下是系统上的内存使用情况（不过，因为此错误发生在自动化测试期间，我尚未验证这是否反映了从sg返回此 errno 时的状态）。

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k total,        0k used,  4194296k free,  8497424k cached

我从Linux Journal 上找到了这篇关于在内核中分配内存的文章。这篇文章已经过时，但似乎与 2.6 相关（关于作者的一些评论位于头部）。文章提到内核被限制为大约 1gb 的内存（尽管从文本中不完全清楚是物理和虚拟各 1gb 还是总共 1gb）。我想知道这是否是 2.6.32 的准确陈述。最后，我想知道这些系统是否达到了这个限制。

虽然这并不是我问题的真正答案，但我想知道 2.6.32 声明的真实性。那么，内核的实际内存限制是多少？这可能需要作为故障排除的考虑因素。欢迎任何其他建议。使这如此令人困惑的是，这些系统与许多其他系统相同，但没有出现同样的问题。

Answer 1

32 位系统中 Linux 内核内存的 1 GiB 限制是 32 位寻址的结果，这是一个非常严格的限制。改变并非不可能，但它存在是有充分理由的；改变它有后果。

让我们回到 1990 年代早期，那时 Linux 被创建。在那些日子里，我们会争论 Linux 是否可以在 2 MiB 的 RAM 中运行，或者它是否真的需要4 个完整的 MiB 内存。当然，高端势利小人都在嘲笑我们，他们的 16 MiB 怪物服务器。

那个有趣的小插图有什么关系？在那个世界中，很容易决定如何划分从简单的 32 位寻址中获得的 4 GiB 地址空间。一些操作系统只是将它分成两半，将地址的最高位视为“内核标志”：地址 0 到 2 ³¹ -1 清除了最高位，用于用户空间代码，地址 2 ³¹到 2 ³² - 1 设置了最高位，用于内核。您可以查看地址并告诉： 0x80000000 及以上，它是内核空间，否则是用户空间。

随着 PC 内存大小膨胀到 4 GiB 内存限制，这种简单的 2/2 拆分开始成为问题。用户空间和内核空间都对大量 RAM 有很好的要求，但是由于我们拥有计算机的目的通常是运行用户程序，而不是运行内核，因此操作系统开始玩弄用户/内​​核划分。3/1 拆分是一种常见的折衷方案。

至于您关于物理与虚拟的问题，实际上并不重要。从技术上讲，这是一个虚拟内存限制，但这只是因为 Linux 是基于 VM 的操作系统。安装 32 GiB 的物理 RAM 不会改变任何东西，也不会有助于swapon32 GiB 交换分区。无论您做什么，32 位 Linux 内核永远无法同时处理超过 4 GiB 的地址。

（是的，我知道PAE。现在 64 位操作系统终于接管了，我希望我们可以开始忘记那个讨厌的黑客。无论如何我不相信它在这种情况下可以帮助你。）

最重要的是，如果您遇到 1 GiB 内核 VM 限制，您可以使用 2/2 拆分来重建内核，但这会直接影响用户空间程序。

64 位确实是正确的答案。