为什么Windows为其系统地址空间预留1Gb(或2 Gb)？

两个不同的用户进程具有不同的虚拟地址空间。因为虚拟的物理地址映射是不同的，所以当将上下文从一个用户进程切换到另一个用户进程时， TLB高速缓存无效。这是非常昂贵的，因为没有在TLB中缓存的地址，任何内存访问将导致 PTE的故障和散步。

Syscalls涉及两个上下文切换：用户→内核，然后是内核→用户。为了加快速度，通常保留最高的1GB或2GB虚拟地址空间供内核使用。因为虚拟地址空间在这些上下文切换中不会改变，所以不需要TLB刷新。这是由每个PTE中的用户/管理员位启用的，这确保内核存储器仅在内核空间中可访问;即使页表相同，用户空间也无法访问。

如果有两个单独的TLB的硬件支持，一个专门用于内核使用，那么这个优化将不再有用。但是，如果您有足够的空间来投入使用，那么制作一个更大的TLB可能更有价值。

Linux on x86曾经支持一种称为“4G / 4G分割”的模式。在这种模式下，用户空间可以完全访问整个4GB的虚拟地址空间，内核还具有完整的4GB虚拟地址空间。如上所述，成本是每个系统调用需要一个TLB刷新，以及更复杂的例程以在用户和内核内存之间复制数据。这一点已经被测量到达30％的性能损失。

时间已经改变，因为这个问题最初被提出和回答：64位操作系统现在更加普遍。在x86-64上的当前操作系统中，用户程序允许从0到247-1(0-128TB)的虚拟地址，而内核永久驻留在从247×(217-1)到264-1(或从 – 247到-1，如果将地址视为有符号整数)。

如果您在64位Windows上运行32位可执行文件，会发生什么？您会认为所有虚拟地址从0到232(0-4GB)将很容易可用，但是为了避免在现有程序中显示错误，32位可执行文件仍然限制在0-2GB，除非它们重新编译为/ LARGEADDRESSAWARE 。对于那些，他们可以访问0-4GB。 (这不是一个新的标志;同样适用于运行/ 3GB开关的32位Windows内核，它将默认的2G / 2G用户/内核分裂更改为3G / 1G，尽管3-4GB仍然会出现的范围。)

可能有什么种类的错误？例如，假设您正在实现快速排序，并且有两个指针，a和b指向数组的开头和结尾。如果用(ab)/ 2选择中间作为枢轴，只要这两个地址都低于2GB，它就可以工作，但是如果它们都在上面，那么加法将会遇到整数溢出，结果将在阵列。 (正确的表达式是a(b-a)/ 2))

除此之外，32位Linux与其默认的3G / 1G用户/内核拆分，历来是运行程序，其堆栈位于2-3GB范围内，因此任何此类编程错误都可能会被快速刷新。 64位Linux提供32位程序访问0-4GB。