好吧，这里有个问题。
所有应该使用的物理地址都Map到虚拟地址0x80000000及以上。
因此，如果您向上移动KERNBASE，操作系统可以使用更少的物理内存。

我也一直在思考这个问题。以下是我的结论--虽然我不能保证，这主要是演绎。
第一件事是你提出的解释在技术上是错误的。xv 6 * 可以 * 处理更高 * 和更低 * 的KERNBASE值。你可以通过将KERNBASE更改为0x90000000，然后更改kernel.ld（将内容放入预期地址的链接器脚本）中的相关值来测试这一点。
据我所知，这里真实的的问题是xv 6不对磁盘执行任何分页。（KERNBASE）及以上线性Map到0x00000000..0xffffffff。这意味着您在整个系统中分配的任何内存字节都Map到32位空间中的2个不同物理地址。由于xv 6不对磁盘进行分页，这意味着如果它为用户进程分配内存（使用sbrk()系统调用，在用户空间中malloc()使用），那么它会一直把它保存在内存中.所以，再一次，因为我们有两个“副本”，或者更准确地说，两个Map到同一个地址，我们实际上永远不能使用超过32位地址空间中一半的可用内存.
现在，回想一下KERNBASE被定义为0x80000000，它就是：一半的可用内存，所以不行，在这种情况下提高KERNBASE不能给予我们更多的用户空间内存。

这里的Necrobumping，但我会张贴我的答案，由于我最近的斗争与这个主题：D
IMO技术上的答案是否定的，如果你像这里所说的那样提高KERNBASE，内核Map给进程和它们的分配的内存会更少。如果你降低KERNBASE，你会缩小进程地址空间，所以一半的地址空间在xv 6的情况下是一个甜蜜点。
话虽如此，我自己也在纠结这个问题，因为如果没有上下文，这个答案就像是在说“就是这样”，对于一个试图把自己的头缠在操作系统内部工作原理上的人来说。
该设计源自以下事实：

• xv 6是一个32位系统，因此地址空间（重要的是地址空间，而不是内存）高达4GB
• 处理器不能使用物理地址，如果你要求它加载一些内存的内容到寄存器，你给的地址将被MMU（硬件）转换，它只是这样构建的
• 内核被Map到每个进程地址空间，以避免在进程执行系统调用（切换到内核模式）时更改页表（从而使TLB缓存无效）。还有其他原因，但这一个似乎是最相关的
• 正如yam-marcovic所说，xv 6中没有内存到磁盘的交换，因此在某种意义上，xv 6使用分页，但没有虚拟内存。也就是说，32位Linux使用3/1分割，因为它可以为进程留下更多的地址空间-内核可以将内存交换到磁盘，因此它不必将所有内容保留在物理内存中

从理论上讲，如果物理内存量等于或大于64位地址空间所能解决的问题，那么在64位系统中也会遇到同样的问题。实际上，没有人会在意，因为与32位相比，它是巨大的。
我在这里想说的是，这种设计及其局限性来自于硬件如何工作之上的软件设计的结合。
我仍然不能回答自己，如果Map内核到更高的虚拟地址，这只是为了方便某种类型或如果有任何硬技术原因。