我们知道32位win7一般只能使用4GB内存，原因是如果按照地址宽度是32bit(其实并不是)来算的话系统最多只能管理 232 字节的内存(通过补丁的方式可以使32位win7突破4GB的限制，关键词：ReadyFor4GB，后面我会讲下对其实现原理的猜测)。

那么照这么算，64位系统应该能使用 264 字节的内存，也就是16EB(1EB = 1024PB, 1PB = 1024TB)，这也太夸张了吧，谨慎的我还百度了下，结果发现说法不一，有说是192GB的，有说是128GB的，那么到底是多少，又为什么没有直接飙到16EB呢？

于是带着疑问我开始从文档和 Linux 源码中探索这个问题的答案，但本文不涉及内核源码，只是因为操作系统可能会在软件层面对内存做进一步的限制，所以会提到到其中的内存布局，而大部分信息是直接从文档中得出的。

我研究的是 x86_64 的CPU，文档是《64-ia-32-architectures-software-developer-manual-325462_NoRestriction》，可以从这里下载到。文档分3卷(volume)：

卷下面又分了章节，所以后面用 v3:4.1 表示卷3第4章第1节这样子。

Linux 源码看的是 Ubuntu 16.04 内核版本是 4.4.0-31，可以从这里获得Ubuntu Kernel(是从主线 Linux fork 出来并做了改动)的下载方法、编译方法。

文档(v3:4.1 Paging Modes and Control Bits)中讲到：x86_64 CPU(是指支持64位寻址的 x86 指令集的CPU，据说64位CPU从2005年下半年开始普及，所以除了古董级的CPU，否则都是支持64位的)可工作在4种内存寻址模式下(不考虑8086模式——只能寻址1MB内存)：

按照该章节的描述，后三种模式都必须启动分页管理，关闭分页就会回到第一种模式。

第一种模式是最简单的，程序中使用的32位的虚拟地址(有的地方也称之为逻辑地址或相对地址)+段的32位起始地址(x86 CPU总是分段管理内存的，分页是可选的)得出一个线性地址，这个线性地址直接当成物理地址来用。但是基本没有操作系统启动完毕后是这样使用内存的，因为分页管理的好处太多了，不开启简直就是犯罪啊：

32位分页模式相较于不分页的情况，多了个线性地址->物理地址的转换，一般情况下这个转换分两级：

文档(v3:4.3 32-Bit Paging)还给了一张非常形象的图来演示这个映射过程：

如果完全按上面这种方式映射的话，那么转换后还是32位的地址，那么最多也只能用4GB内存了。但是第一级页目录项还可以直接映射一个4MB的内存页——当页目录项中第7位为1的时候(为0就还有一级页表要转换，也就是上面的情况)。

这时页目录项的高10位(31:22 bit)作为物理地址的31:22 bit，低22位取线性地址的低22位作为页内偏移，然后相比于上面的映射，21:12 bit这里还有10个位空出来了，然后CPU就发扬了不用白不用的抠门精神，在其中8位(20:13 bit)多存储了物理地址的高8位(39:32 bit，实际上不同型号的CPU支持的位数可能不一样)，这样利用映射4MB页的机制我们能使用最大达到40bit的物理地址，也就是高达1TB的内存。下图演示了这种映射：

但是这种映射存在一些缺点：

而PAE分页模式解决了第2个缺点(因为页表项变成了8字节，最后一级页表项也能表示一个宽地址，最高可达52位，跟IA-32e一样)，但线性地址还是32位的，也就是单个进程还是最多使用4GB内存，但所有进程加起来理论上可以使用4PB内存(不过要1M个进程，太不现实)。

由此可见32位系统用超过4GB内存也是完全可能的，ReadyFor4GB有可能是通过4MB内存页映射实现的(如果系统原来是32位分页模式的话)，也可能是原来就是PAE分页模式只是系统限制了只使用4GB以下内存，也可能是从32位分页模式大改造成PAE分页模式(但这个的难度要高很多，4字节页表项改成8字节页表项，能兼容原来的内核代码？)。

32位线性地址限制了进程的地址空间，即使有超过4GB的内存，在一个进程中也用不了。那么就扩大地址宽度吧，之前我们从16位扩到20位(8088到8086)，然后从20位扩到32位(80386)，那就扩到48位吧(想想当年把1MB内存当成宝贝，现在一个内碎片都可能超过1MB了)。现在可以放这张全家福了：

IA-32e模式中线性地址是48位(256TB)，物理地址是52位(4PB，最高值，各CPU实际支持的最大宽度普遍低于这个值，后面部分有检测方法)。

48位是6字节，但实际上64位程序中的地址(指针)的大小是8字节，文档(v1:3.3.7.1 Canonical Addressing)规定64位线性地址必须遵循一个规则：如果第47位是0，那么63:48bit全部是0；否则全部是1。其实就是扩展了符号位的意思，如果分页转换前的线性地址不符合这个规则就会触发CPU异常，这个应该是督促系统程序员兼容以后的真64位CPU。于是只有以下地址才是合法的地址：

而CPU做线性地址到物理地址转换的时候只取其低48位。这个地址转换有4级，每级还是一个4KB的页表，其中每项8字节，那么就只有512个项，每级用线性地址中的9位做下标索引，4*9=36，刚好剩下12位填充4KB内存页的页内偏移：

让我们来算算各级页表项管理的地址空间的大小：

所以我们看出来了，不直接上64位貌似还挺有道理的，48位就已经很浪费了！第一级页表中一项竟然就映射了512GB的地址空间，我看了下Alienware Area-51才32GB的内存，所以以目前的内存大小来看，砍掉一级变成3级映射也是完全够用的。

在 IA-32e 模式中为了提高地址转换速度，同时为了减少页表数量(确实很有必要，内存越大，页表越多)，我们可以在 PDE 中直接映射2MB的内存页(普遍支持)，甚至可以在 PDPTE 中直接映射 1GB 的内存页(部分CPU支持，我的E3-1231 v3 刚好支持)。

某款CPU支持的最大物理地址宽度(maximum physical address bits)可以执行cpuid指令查询(v3:4.1.4 Enumeration of Paging Features by CPUID)，如果自己实现的话要自己写个内联汇编程序，但是ubuntu 上有个同名命令行程序可以直接帮我们查出来，如下：

这是我的组装机，CPU是 Intel Xeon E3-1231 v3，四核八线程，可以看出每个处理器支持的最大物理地址宽度是39，也就是512GB。而我2010年买的联想 G450，奔腾双核 T4400，经检查是36位，也就是64GB。

CPU在线性地址宽度上倒是没有打折扣，支持IA-32e的都有48位。但是操作系统的内存管理模型会对这个做进一步的限制，内核源码中有个txt介绍了Linux对x86_64的线性地址布局(Documentation/x86/x86_64/mm.txt)：

其中有3个区域我可以解释一下(其他的不是很了解)：

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm 这是进程的用户空间，而剩下的ffff80000000以上的空间是系统空间，所以线性地址空间是对半分的，应用程序可使用最大达128TB的地址空间。

ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory 这里占用了系统空间的一半，是对所有物理内存的线性映射，这个映射可以用个函数来表示： 假设线性地址X在这个地址空间中，那么 X的物理地址 = X - 0xffff8800 00000000 因为CPU开启分页后，所有指令中的内存地址都会自动经过分页地址映射转换成物理地址使用，即使是内核也不能直接使用物理地址，内核初始化阶段中会在这片空间中建立起对所有物理内存(