CPU如何操作内存？

laoyu

原文标题：Getting Physical With Memory

原文地址：http://duartes.org/gustavo/blog/

[注：本人水平有限，只好挑一些国外高手的精彩文章翻译一下。一来自己复习，二来与大家分享。]

在你试图理解一个复杂的系统时，如果能揭去表面的抽象并专注于最低级别的概念，往往会有不小的收获。在这个精神的指导下，让我们看看对于内存和I/O端口操作来说最简单、最基础的概念，即CPU与总线之间的接口。其中的细节是很多上层概念的基础，比如线程同步。当然了，既然我是个程序员，就暂且忽略那些只有电子工程师才会去关注的东西吧。下图是我们的老朋友，Core 2：

Core 2 处理器有775个管脚，其中约半数仅仅用于供电而不参与数据传输。当你把这些管脚按照功能分类后，就会发现这个处理器的物理接口惊人的简单。本图展示了参与内存和I/O端口操作的重要管脚：地址线，数据线，请求线。这些操作均发生在前端总线的事务上下文结构(the context of a transaction)中。前端总线事务的执行包含五个阶段：仲裁，请求，侦听，响应，数据操作。在执行事务的过程中，前端总线上的各个部件扮演着不同的角色。这些部件称之为agent。通常，agent就是全部的处理器外加北桥。

本文只分析请求阶段。在此阶段中，发出请求的agent往往是一个处理器，它输出两个数据包。下图列出了第一个数据包中最为重要的位，这些数据位通过处理器的地址线和请求线输出：

   地址线输出指定了事务发生的物理内存起始地址。我们有33条地址线，他们指定了数据包的第35至第3位，第2至第0位为0。因此，实际上这33条地址线构成了一个36位的、以8字节对齐的地址，正好覆盖64GB的物理内存。这种设定从奔腾Pro就开始了。请求线指定了事务的类型。当事务类型为I/O请求时，地址线指出的是I/O端口地址而不是内存地址。当第一个数据包被发送以后，同样由这组管脚，在下一个总线时钟周期发送第二个数据包：

属性信号（attribute signal A[31:24]）很有趣，它反映了Intel处理器所支持的5种内存缓冲功能。把这些信息发布到前端总线后，发出请求的agent就可以让其他处理器知道如何根据当前事务处理他们自己的cache，以及让内存控制器（也就是北桥）知道该如何应对。一块指定内存区域的缓存类型由处理器通过查询页表（page table）来决定，页表由OS内核维护。

典型的情况是，内核把全部内存都视为“回写”类型（write-back），从而获得最好的性能。在回写模式下，内存的最小访问单元为一个缓存线（cache line），在Core 2中是64字节。当程序想读取内存中的一个字节时，处理器会从L1/L2 cache读取包含此字节的整条缓存线的内容。当程序做写入内存操作时，处理器只是修改cache中的对应缓存线，而不会更新主存中的信息。之后，当真的需要更新主存时，处理器会把那个被修改了的缓存线整体放到总线上，一次性写入内存。所以大部分的请求事务，其数据长度字段都是11（REQ[1:0]），对应64 字节。下图展示了当cache中没有对应数据时，内存读取访问的过程：

在Intel计算机上，有些物理内存范围被映射为设备地址而不是实际的RAM存储器地址，比如硬盘和网卡。这使得驱动程序可以像读写内存那样，方便的与设备通信。内核会在页表中标记出这类内存映射区域为不可缓存的（uncacheable）。对不可缓存的内存区域的访问操作会被总线原封不动的按顺序执行，其操作与应用程序或驱动程序所发出的请求完全一致。因此，这时程序可以精确控制读写单个字节、字、或其它长度的信息。这都是通过设置第二个数据包中的字节使能掩码（byte enable mask A[15:8]）来完成的。

前面讨论的这些基本知识还包含很多关联的内容。比如：

1、 如果应用程序想要尽可能高的运行速度，就应该把会被一起访问的数据尽量组织在同一条缓存线中。一旦这条缓存线被载入，之后的读取操作就会加快很多，不再需要额外的内存访问了。

2、 对于回写式内存访问，作用于一条缓存线的任何内存操作都一定是原子的（atomic）。这种能力是由处理器的L1 cache提供的，所有数据被同时读写，中途不会被其他处理器或线程打断。特别的，32位和64位的内存操作，只要不跨越缓存线的边界，就都是原子操作。

3、 前端总线是被所有的agent所共享的。这些agent在开启一个事务之前，必须先进行总线使用权的仲裁。而且，每一个agent都需要侦听总线上所有的事务，以便维持cache的一致性。因此，随着部署更多的、多核的处理器到Intel计算机，总线竞争问题会变得越来越严重。为解决这个问题，Core i7将处理器直接连接于内存，并以点对点的方式通信，取代之前的广播方式，从而减少总线竞争。

本文讲述的都是有关物理内存请求的重要内容。当涉及到内存锁定、多线程、缓存一致性的问题时，总线这个角色又将浮出水面。当我第一次看到前端总线数据包的描述时，会有种恍然大悟的感觉。

让我们看看当今的Intel计算机是如何连接各个组件的吧。下图展示了主板上的主要组件：

当你看图时，请牢记一个至关重要的事实：CPU一点也不知道它连接了什么东西。CPU仅仅通过一组针脚与外界交互，它并不关心外界到底有什么。可能是一个电脑主板，但也可能是烤面包机，网络路由器，植入脑内的设备，或CPU测试工作台。CPU主要通过3种方式与外界交互：内存地址空间，I/O地址空间，还有中断。

眼下，我们只关心主板和内存。安装在主板上的CPU与外界沟通的门户是前端总线（front-side bus），前端总线把CPU与北桥连接起来。每当CPU需要读写内存时，都会使用这条总线。CPU通过一部分管脚来传输想要读写的物理内存地址，同时另一些管脚用于发送将被写入或接收被读出的数据。一个Intel Core 2 QX6600有33个针脚用于传输物理内存地址（可以表示233个地址位置），64个针脚用于接收/发送数据（所以数据在64位通道中传输，也就是8字节的数据块）。这使得CPU可以控制64GB的物理内存（233个地址乘以8字节），尽管大多数的芯片组只能支持8GB的RAM。

现在到了最难理解的部分。我们可能曾经认为内存指的就是RAM，被各式各样的程序读写着。的确，大部分CPU发出的内存请求都被北桥转送给了RAM管理器，但并非全部如此。物理内存地址还可能被用于主板上各种设备间的通信，这种通信方式叫做内存映射I/O。这类设备包括显卡，大多数的PCI卡（比如扫描仪或SCSI卡），以及BIOS中的flash存储器等。

当北桥接收到一个物理内存访问请求时，它需要决定把这个请求转发到哪里：是发给RAM？抑或是显卡？具体发给谁是由内存地址映射表来决定的。映射表知道每一个物理内存地址区域所对应的设备。绝大部分的地址被映射到了RAM，其余地址由映射表来通知芯片组该由哪个设备来响应此地址的访问请求。这些被映射为设备的内存地址形成了一个经典的空洞，位于PC内存的640KB到1MB之间。当内存地址被保留用于显卡和PCI设备时，就会形成更大的空洞。这就是为什么32位的操作系统无法使用全部的4GB RAM。Linux中，/proc/iomem这个文件简明的列举了这些空洞的地址范围。下图展示了Intel PC低端4GB物理内存地址形成的一个典型的内存映射：

Intel系统中，低端4GB内存地址空间的布局。

实际的地址和范围依赖于特定的主板和电脑中接入的设备，但是对于大多数Core 2系统，情形都跟上图非常接近。所有棕色的区域都被设备地址映射走了。记住，这些在主板总线上使用的都是物理地址。在CPU内部（比如我们正在编写和运行的程序），使用的是逻辑地址，必须先由CPU翻译成物理地址以后，才能发布到总线上去访问内存。

这个把逻辑地址翻译成物理地址的规则比较复杂，而且还依赖于当时CPU的运行模式（实模式，32位保护模式，64位保护模式）。不管采用哪种翻译机制，CPU的运行模式决定了有多少物理内存可以被访问。比如，当CPU工作于32位保护模式时，它只可以寻址4GB物理地址空间（当然，也有个例外叫做物理地址扩展，但暂且忽略这个技术吧）。由于顶部的大约1GB物理地址被映射到了主板上的设备，CPU实际能够使用的也就只有大约3GB的RAM（有时甚至更少，我曾用过一台安装了Vista的电脑，它只有2.4GB可用）。如果CPU工作于实模式，那么它将只能寻址1MB的物理地址空间（这是早期的Intel处理器所支持的唯一模式）。如果CPU工作于64位保护模式，则可以寻址64GB的地址空间（虽然很少有芯片组支持这么大的RAM）。处于64位保护模式时，CPU就有可能访问到RAM空间中被主板上的设备映射走了的区域了（即访问空洞下的RAM）。要达到这种效果，就需要使用比系统中所装载的RAM地址区域更高的地址。这种技术叫做回收(reclaiming)，而且还需要芯片组的配合。

这些关于内存的知识将为下一篇文章做好铺垫。下次我们会探讨机器的启动过程：从上电开始，直到boot loader准备跳转执行操作系统内核为止。如果你想更深入的学习这些东西，我强烈推荐Intel手册。虽然我列出的都是第一手资料，但Intel手册写得很好很准确。这是一些资料：

l 《Datasheet for Intel G35 Chipset》描述了一个支持Core 2处理器的有代表性的芯片组。这也是本文的主要信息来源。

l 《Datasheet for Intel Core 2 Quad-Core Q6000 Sequence》是一个处理器数据手册。它记载了处理器上每一个管脚的作用（当你把管脚按功能分组后，其实并不算多）。很棒的资料，虽然对有些位的描述比较含糊。

l 《Intel Software Developer’s Manuals》是杰出的文档。它优美的解释了体系结构的各个部分，一点也不会让人感到含糊不清。第一卷和第三卷A部很值得一读（别被“卷”字吓倒，每卷都不长，而且您可以选择性的阅读）。

l Pádraig Brady建议我链接到Ulrich Drepper的一篇关于内存的优秀文章。确实是个好东西。我本打算把这个链接放到讨论存储器的文章中的，但此处列出的越多越好啦。