What Your Computer Does While You Wait

Posted 2020-06-25

转: CPU的等待有多久?

原文标题：What Your Computer Does While You Wait

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

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

   本文以一个现代的、实际的个人电脑为对象，分析其中CPU（Intel Core 2 Duo 3.0GHz）以及各类子系统的运行速度——延迟和数据吞吐量。通过粗略的估算PC各个组件的相对运行速度，希望能给大家留下一个比较直观的印象。本文中的数据来自实际应用，而非理论最大值。时间的单位是纳秒（ns，十亿分之一秒），毫秒（ms，千分之一秒），和秒（s）。吞吐量的单位是兆字节（MB）和千兆字节（GB）。让我们先从CPU和内存开始，下图是北桥部分：   

   第一个令人惊叹的事实是：CPU快得离谱。在Core 2 3.0GHz上，大部分简单指令的执行只需要一个时钟周期，也就是1/3纳秒。即使是真空中传播的光，在这段时间内也只能走10厘米（约4英寸）。把上述事实记在心中是有好处的。当你要对程序做优化的时候就会想到，执行指令的开销对于当今的CPU而言是多么的微不足道。   

当CPU运转起来以后，它便会通过L1 cache和L2 cache对系统中的主存进行读写访问。cache使用的是静态存储器(SRAM)。相对于系统主存中使用的动态存储器（DRAM），cache读写速度快得多、造价也高昂得多。cache一般被放置在CPU芯片的内部，加之使用昂贵高速的存储器，使其给CPU带来的延迟非常低。在指令层次上的优化（instruction-level optimization），其效果是与优化后代码的大小息息相关。由于使用了高速缓存技术（caching），那些能够整体放入L1/L2 cache中的代码，和那些在运行时需要不断调入/调出（marshall into/out of）cache的代码，在性能上会产生非常明显的差异。

   正常情况下，当CPU操作一块内存区域时，其中的信息要么已经保存在L1/L2 cache，要么就需要将之从系统主存中调入cache，然后再处理。如果是后一种情况，我们就碰到了第一个瓶颈，一个大约250个时钟周期的延迟。在此期间如果CPU没有其他事情要做，则往往是处在停机状态的（stall）。为了给大家一个直观的印象，我们把CPU的一个时钟周期看作一秒。那么，从L1 cache读取信息就好像是拿起桌上的一张草稿纸（3秒）；从L2 cache读取信息则是从身边的书架上取出一本书（14秒）；而从主存中读取信息则相当于走到办公楼下去买个零食（4分钟）。

   主存操作的准确延迟是不固定的，与具体的应用以及其他许多因素有关。比如，它依赖于列选通延迟(CAS)以及内存条的型号，它还依赖于CPU指令预取的成功率。指令预取可以根据当前执行的代码来猜测主存中哪些部分即将被使用，从而提前将这些信息载入cache。

   看看L1/L2 cache的性能，再对比主存，就会发现：配置更大的cache或者编写能更好的利用cache的应用程序，会使系统的性能得到多么显著的提高。如果想进一步了解有关内存的诸多信息，读者可以参阅Ulrich Drepper所写的一篇经典文章《What Every Programmer Should Know About Memory》。

   人们通常把CPU与内存之间的瓶颈叫做冯·诺依曼瓶颈（von Neumann bottleneck）。当今系统的前端总线带宽约为10GB/s，看起来很令人满意。在这个速度下，你可以在1秒内从内存中读取8GB的信息，或者10纳秒内读取100字 节。遗憾的是，这个吞吐量只是理论最大值（图中其他数据为实际值），而且是根本不可能达到的，因为主存控制电路会引入延迟。在做内存访问时，会遇到很多零 散的等待周期。比如电平协议要求，在选通一行、选通一列、取到可靠的数据之前，需要有一定的信号稳定时间。由于主存中使用电容来存储信息，为了防止因自然放电而导致的信息丢失，就需要周期性的刷新它所存储的内容，这也带来额外的等待时间。某些连续的内存访问方式可能会比较高效，但仍然具有延时。而那些随机 的内存访问则消耗更多时间。所以延迟是不可避免的。

 

  

图中下方的南桥连接了很多其他总线（如：PCI-E, USB）和外围设备：

  

  

令人沮丧的是，南桥管理了一些反应相当迟钝的设备，比如硬盘。就算是缓慢的系统主存，和硬盘相比也可谓速度如飞了。继续拿办公室做比喻，等待硬盘寻道的时间相当于离开办公大楼并开始长达一年零三个月的环球旅行。这就解释了为何电脑的大部分工作都受制于磁盘I/O，以及为何数据库的性能在内存缓冲区被耗尽后会陡然下降。同时也解释了为何充足的RAM（用于缓冲）和高速的磁盘驱动器对系统的整体性能如此重要。

  

虽然磁盘的"连续"存取速度确实可以在实际使用中达到，但这并非故事的全部。真正令人头疼的瓶颈在于寻道操作，也就是在磁盘表面移动读写磁头到正确的磁道上，然后再等待磁盘旋转到正确的位置上，以便读取指定扇区内的信息。RPM（每分钟绕转次数）用来指示磁盘的旋转速度：RPM越大，耽误在寻道上的时间就越少，所以越高的RPM意味着越快的磁盘。这里有一篇由两个Stanford的研究生写的很酷的文章，其中讲述了寻道时间对系统性能的影响：《Anatomy of a Large-Scale Hypertextual Web Search Engine》

   当 磁盘驱动器读取一个大的、连续存储的文件时会达到更高的持续读取速度，因为省去了寻道的时间。文件系统的碎片整理器就是用来把文件信息重组在连续的数据块 中，通过尽可能减少寻道来提高数据吞吐量。然而，说到计算机实际使用时的感受，磁盘的连续存取速度就不那么重要了，反而应该关注驱动器在单位时间内可以完 成的寻道和随机I/O操作的次数。对此，固态硬盘可以成为一个很棒的选择。

   硬盘的cache也有助于改进性能。虽然16MB的cache只能覆盖整个磁盘容量的0.002%，可别看cache只有这么一点大，其效果十分明显。它可以把一组零散的写入操作合成一个，也就是使磁盘能够控制写入操作的顺序，从而减少寻道的次数。同样的，为了提高效率，一系列读取操作也可以被重组，而且操作系统和驱动器固件(firmware)都会参与到这类优化中来。

 

  

最后，图中还列出了网络和其他总线的实际数据吞吐量。火线(fireware)仅供参考，Intel X48芯片组并不直接支持火线。我们可以把Internet看作是计算机之间的总线。去访问那些速度很快的网站（比如google.com），延迟大约45毫秒，与硬盘驱动器带来的延迟相当。事实上，尽管硬盘比内存慢了5个数量级，它的速度与Internet是在同一数量级上的。目前，一般家用网络的带宽还是要落后于硬盘连续读取速度的，但"网络就是计算机"这句话可谓名符其实。如果将来Internet比硬盘还快了，那会是个什么景象呢？

  

我希望这些图片能对您有所帮助。当这些数字一起呈现在我面前时，真的很迷人，也让我看到了计算机技术发展到了哪一步。前文分开的两个图片只是为了叙述方便，我把包含南北桥的整张图片也贴出来，供您参考。

  

参考: http://blog.csdn.net/drshenlei/article/details/4240703

 

转: CPU如何操作内存

原文标题：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将处理器直接连接于内存，并以点对点的方式通信，取代之前的广播方式，从而减少总线竞争。

  

本 文讲述的都是有关物理内存请求的重要内容。当涉及到内存锁定、多线程、缓存一致性的问题时，总线这个角色又将浮出水面。当我第一次看到前端总线数据包的描 述时，会有种恍然大悟的感觉，所以我希望您也能从本文中获益。下一篇文章，我们将从底层爬回到上层去，研究一个抽象概念：虚拟内存。

 参考: http://blog.csdn.net/drshenlei/article/details/4243733

 

[转]: 主板芯片组与内存映射

原文标题：Motherboard Chipsets and the Memory Map

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

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

   我打算写一组讲述计算机内幕的文章，旨在揭示现代操作系统内核的工作原理。我希望这些文章能对电脑爱好者和程序员有所帮助，特别是对这类话题感兴趣但没有相关知识的人们。讨论的焦点是Linux，Windows，和Intel处理器。钻研系统内幕是我的一个爱好。我曾经编写过不少内核模式的代码，只是最近一段时间不再写了。这第一篇文章讲述了现代Intel主板的布局，CPU如何访问内存，以及系统的内存映射。

   作为开始，让我们看看当今的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手册写得很好很准确。这是一些资料：

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

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

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

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

 

参考: http://blog.csdn.net/drshenlei/article/details/4246441

 

转: 计算机的引导过程

原文标题：How Computers Boot Up

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

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

   前一篇文章介绍了Intel计算机的主板与内存映射，从而为本文设定了一个系统引导阶段的场景。引导（Booting）是一个复杂的，充满技巧的，涉及多个阶段，又十分有趣的过程。下图列出了此过程的概要：

 

  

引导过程概要

  

当 你按下计算机的电源键后（现在别按！），机器就开始运转了。一旦主板上电，它就会初始化自身的固件(firmware)——芯片组和其他零零碎碎的东西 ——并尝试启动CPU。如果此时出了什么问题（比如CPU坏了或根本没装），那么很可能出现的情况是电脑没有任何动静，除了风扇在转。一些主板会在CPU 故障或缺失时发出鸣音提示，但以我的经验，此时大多数机器都会处于僵死状态。一些USB或其他设备也可能导致机器启动时僵死。对于那些以前工作正常，突然 出现这种症状的电脑，一个可能的解决办法是拔除所有不必要的设备。你也可以一次只断开一个设备，从而发现哪个是罪魁祸首。

  

如果一切正常，CPU就开始运行了。在一个多处理器或多核处理器的系统中，会有一个CPU被动态的指派为引导处理器（bootstrap processor简写BSP），用于执行全部的BIOS和内核初始化代码。其余的处理器，此时被称为应用处理器（application processor简写AP），一直保持停机状态直到内核明确激活他们为止。虽然Intel CPU经历了很多年的发展，但他们一直保持着完全的向后兼容性，所以现代的CPU可以表现得跟原先1978年的Intel 8086完全一样。其实，当CPU上电后，它就是这么做的。在这个基本的上电过程中，处理器工作于实模式，分页功能是无效的。此时的系统环境，就像古老的MS-DOS一样，只有1MB内存可以寻址，任何代码都可以读写任何地址的内存，这里没有保护或特权级的概念。

  

CPU上电后，大部分寄存器的都具有定义良好的初始值，包括指令指针寄存器（EIP），它记录了下一条即将被CPU执行的指令所在的内存地址。尽管此时的Intel CPU还只能寻址1MB的内存，但凭借一个奇特的技巧，一个隐藏的基地址（其实就是个偏移量）会与EIP相加，其结果指向第一条将被执行的指令所处的地址0xFFFFFFF0（长16字节，在4GB内存空间的尾部，远高于1MB）。这个特殊的地址叫做复位向量(reset vector)，而且是现代Intel CPU的标准。

  

主板保证在复位向量处的指令是一个跳转，而且是跳转到BIOS执行入口点所在的内存映射地址。这个跳转会顺带清除那个隐藏的、上电时的基地址。感谢芯片组提供的内存映射功能，此时的内存地址存放着CPU初始化所需的真正内容。这些内容全部是从包含有BIOS的闪存映射过来的，而此时的RAM模块还只有随机的垃圾数据。下面的图例列出了相关的内存区域：

  

引导时的重要内存区域

  

随后，CPU开始执行BIOS的代码，初始化机器中的一些硬件。之后BIOS开始执行上电自检过程（POST），检测计算机中的各种组件。如果找不到一个可用的显卡，POST就会失败，导致BIOS进入停机状态并发出鸣音提示（因为此时无法在屏幕上输出提示信息）。如果显卡正常，那么电脑看起来就真的运转起来了：显示一个制造商定制的商标，开始内存自检，天使们大声的吹响号角。另有一些POST失败的情况，比如缺少键盘，会导致停机，屏幕上显示出错信息。其实POST即是检测又是初始化，还要枚举出所有PCI设备的资源——中断，内存范围，I/O端口。现代的BIOS会遵循高级配置与电源接口（ACPI）协议，创建一些用于描述设备的数据表，这些表格将来会被操作系统内核用到。

  

POST完毕后，BIOS就准备引导操作系统了，它必须存在于某个地方：硬盘，光驱，软盘等。BIOS搜索引导设备的实际顺序是用户可定制的。如果找不到合适的引导设备，BIOS会显示出错信息并停机，比如"Non-System Disk or Disk Error"没有系统盘或驱动器故障。一个坏了的硬盘可能导致此症状。幸运的是，在这篇文章中，BIOS成功的找到了一个可以正常引导的驱动器。

  

现在，BIOS会读取硬盘的第一个扇区（0扇区），内含512个字节。这些数据叫做主引导记录（Master Boot Record简称MBR）。一般说来，它包含两个极其重要的部分：一个是位于MBR开头的操作系统相关的引导程序，另一个是紧跟其后的磁盘分区表。BIOS 丝毫不关心这些事情：它只是简单的加载MBR的内容到内存地址0x7C00处，并跳转到此处开始执行，不管MBR里的代码是什么。

  

主引导记录

  

这段在MBR内的特殊代码可能是Windows 引导装载程序，Linux 引导装载程序（比如LILO或GRUB），甚至可能是病毒。与此不同，分区表则是标准化的：它是一个64字节的区块，包含4个16字节的记录项，描述磁盘是如何被分割的（所以你可以在一个磁盘上安装多个操作系统或拥有多个独立的卷）。传统上，Microsoft的MBR代码会查看分区表，找到一个（唯一的）标记为活动（active）的分区，加载那个分区的引导扇区（boot sector），并执行其中的代码。引导扇区是一个分区的第一个扇区，而不是整个磁盘的第一个扇区。如果此时出了什么问题，你可能会收到如下错误信息："Invalid Partition Table"无效分区表或"Missing Operating System"操作系统缺失。这条信息不是来自BIOS的，而是由从磁盘加载的MBR程序所给出的。因此这些信息依赖于MBR的内容。

  

随着时间的推移，引导装载过程已经发展得越来越复杂，越来越灵活。Linux的引导装载程序Lilo和GRUB可以处理很多种类的操作系统，文件系统，以及引导配置信息。他们的MBR代码不再需要效仿上述"从活动分区来引导"的方法。但是从功能上讲，这个过程大致如下：

  

1、  MBR本身包含有第一阶段的引导装载程序。GRUB称之为阶段一。

2、  由于MBR很小，其中的代码仅仅用于从磁盘加载另一个含有额外的引导代码的扇区。此扇区可能是某个分区的引导扇区，但也可能是一个被硬编码到MBR中的扇区位置。

3、  MBR配合第2步所加载的代码去读取一个文件，其中包含了下一阶段所需的引导程序。这在GRUB中是"阶段二"引导程序，在Windows Server中是C:/NTLDR。如果第2步失败了，在Windows中你会收到错误信息，比如"NTLDR is missing"NTLDR缺失。阶段二的代码进一步读取一个引导配置文件（比如在GRUB中是grub.conf，在Windows中是boot.ini）。之后要么给用户显示一些引导选项，要么直接去引导系统。

4、  此时，引导装载程序需要启动操作系统核心。它必须拥有足够的关于文件系统的信息，以便从引导分区中读取内核。在Linux中，这意味着读取一个名字类似"vmlinuz-2.6.22-14-server"的含有内核镜像的文件，将之加载到内存并跳转去执行内核引导代码。在Windows Server 2003中，一部份内核启动代码是与内核镜像本身分离的，事实上是嵌入到了NTLDR当中。在完成一些初始化工作以后，NTDLR从"c:/Windows/System32/ntoskrnl.exe"文件加载内核镜像，就像GRUB所做的那样，跳转到内核的入口点去执行。

  

这里还有一个复杂的地方值得一提（这也是我说引导富于技巧性的原因）。当前Linux内核的镜像就算被压缩了，在实模式下，也没法塞进640KB的可用RAM里。我的vanilla Ubuntu内核压缩后有1.7MB。然而，引导装载程序必须运行于实模式，以便调用BIOS代码去读取磁盘，所以此时内核肯定是没法用的。解决之道是使用一种倍受推崇的"虚模式"。它并非一个真正的处理器运行模式（希望Intel的工程师允许我以此作乐），而是一个特殊技巧。程序不断的在实模式和保护模式之间切换，以便访问高于1MB的内存同时还能使用BIOS。如果你阅读了GRUB的源代码，你就会发现这些切换到处都是（看看stage2/目录下的程序，对real_to_prot 和 prot_to_real函数的调用）。在这个棘手的过程结束时，装载程序终于千方百计的把整个内核都塞到内存里了，但在这后，处理器仍保持在实模式运行。

  

  

至此，我们来到了从"引导装载"跳转到"早期的内核初始化"的时刻，就像第一张图中所指示的那样。在系统做完热身运动后，内核会展开并让系统开始运转。下一篇文章将带大家一步步深入Linux内核的初始化过程，读者还可以参考Linux Cross reference的资源。我没办法对Windows也这么做，但我会把要点指出来。

参考:

http://blog.csdn.net/drshenlei/article/details/4250306

 

 

 

转: 内核引导过程

原文标题：The Kernel Boot Process

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

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

   上一篇文章解释了计算机的引导过程，正好讲到引导装载程序把系统内核镜像塞进内存，准备跳转到内核入口点去执行的时刻。作为引导启动系列文章的最后一篇，就让我们深入内核，去看看操作系统是怎么启动的吧。由于我习惯以事实为依据讨论问题，所以文中会出现大量的链接引用Linux 内核2.6.25.6版的源代码（源自Linux Cross Reference）。如果你熟悉C的 语法，这些代码就会非常容易读懂；即使你忽略一些细节，仍能大致明白程序都干了些什么。最主要的障碍在于对一些代码的理解需要相关的背景知识，比如机器的 底层特性或什么时候、为什么它会运行。我希望能尽量给读者提供一些背景知识。为了保持简洁，许多有趣的东西，比如中断和内存，文中只能点到为止了。在本文 的最后列出了Windows的引导过程的要点。

   当Intel x86的引导程序运行到此刻时，处理器处于实模式（可以寻址1MB的内存），（针对现代的Linux系统）RAM的内容大致如下：

 

引导装载完成后的RAM内容

   引导装载程序通过BIOS的磁盘I/O服务，已经把内核镜像加载到内存当中。这个镜像只是硬盘中内核文件（比如/boot/vmlinuz-2.6.22-14-server）的一份完全相同的拷贝。镜像分为两个部分：一个较小的部分，包含实模式的内核代码，被加载到640KB内存边界以下；另一部分是一大块内核，运行在保护模式，被加载到低端1MB内存地址以上。

   如上图所示，之后的事情发生在实模式内核的头部（kernel header）。这段内存区域用于实现引导装载程序与内核之间的Linux引导协议。 此处的一些数据会被引导装载程序读取。这些数据包括一些令人愉快的信息，比如包含内核版本号的可读字符串，也包括一些关键信息，比如实模式内核代码的大 小。引导装载程序还会向这个区域写入数据，比如用户选中的引导菜单项对应的命令行参数所在的内存地址。之后就到了跳转到内核入口点的时刻。下图显示了内核 初始化代码的执行顺序，包括源代码的目录、文件和行号：

 

与体系结构相关的Linux内核初始化过程

  

对于Intel体系结构，内核启动前期会执行arch/x86/boot/header.S文件中的程序。它是用汇编语言书写的。一般说来汇编代码在内核中很少出现，但常见于引导代码。这个文件的开头实际上包含了引导扇区代码。早期的Linux不需要引导装载程序就可以工作，这段代码是从那个时候留传下来的。现今，如果这个引导扇区被执行，它仅仅给用户输出一个"bugger_off_msg"之后就会重启系统。现代的引导装载程序会忽略这段遗留代码。在引导扇区代码之后，我们会看到实模式内核头部（kernel header）最开始的15字节；这两部分合起来是512字节，正好是Intel硬件平台上一个典型的磁盘扇区的大小。

   在这512字节之后，偏移量0x200处，我们会发现Linux内核的第一条指令，也就是实模式内核的入口点。具体的说，它在header.S:110，是一个2字节的跳转指令，直接写成了机器码的形式0x3AEB。你可以通过对内核镜像运行hexdump，并查看偏移量0x200处的内容来验证这一点——这仅仅是一个对神志清醒程度的检查，以确保这一切并不是在做梦。引导装载程序运行完毕时就会跳转执行这个位置的指令，进而跳转到header.S:229执行一个普通的用汇编写成的子程序，叫做start_of_setup。这个短小的子程序初始化栈空间（stack），把实模式内核的bss段清零（这个区域包含静态变量，所以用0来初始化它们），之后跳转执行一段又老又好的C语言程序：arch/x86/boot/main.c:122。

   main()会处理一些登记工作（比如检测内存布局），设置显示模式等。然后它会调用go_to_protected_mode()。然而，在把CPU置于保护模式之前，还有一些工作必须完成。有两个主要问题：中断和内存。在实模式中，处理器的中断向量表总是从内存的0地址开始的，然而在保护模式中，这个中断向量表的位置是保存在一个叫IDTR的CPU寄存器当中的。与此同时，从逻辑内存地址（在程序中使用）到线性内存地址（一个从0连续编号到内存顶端的数值）的翻译方法在实模式和保护模式中是不同的。保护模式需要一个叫做GDTR的寄存器来存放内存全局描述符表的地址。所以go_to_protected_mode()调用了setup_idt() 和 setup_gdt()，用于装载临时的中断描述符表和全局描述符表。

 

  

现在我们可以转入保护模式啦，这是由另一段汇编子程序protected_mode_jump来完成的。这个子程序通过设定CPU的CR0寄存器的PE位来使能保护模式。此时，分页功能还处于关闭状态；分页是处理器的一个可选的功能，即使运行于保护模式也并非必要。真正重要的是，我们不再受制于640K的内存边界，现在可以寻址高达4GB的RAM了。这个子程序进而调用压缩状态内核的32位内核入口点startup_32。startup32会做一些简单的寄存器初始化工作，并调用一个C语言编写的函数decompress_kernel()，用于实际的解压缩工作。

   decompress_kernel()会打印一条大家熟悉的信息"Decompressing Linux…"（正在解压缩Linux）。解压缩过程是原地进行的，一旦完成内核镜像的解压缩，第一张图中所示的压缩内核镜像就会被覆盖掉。因此解压后的内核也是从1MB位置开始的。之后，decompress_kernel()会显示"done"（完成）和令人振奋的"Booting the kernel"（正在引导内核）。这里"Booting"的意思是跳转到整个故事的最后一个入口点，也是保护模式内核的入口点，位于RAM的第二个1MB开始处（偏移量0x100000，此值是由芬兰Halti山巅之上的神灵授意给Linus的）。在这个神圣的位置含有一个子程序调用，名叫…呃…startup_32。但你会发现这一位是在另一个目录中的。

 

  

这位startup_32的第二个化身也是一个汇编子程序，但它包含了32位模式的初始化过程：

1、  它清理了保护模式内核的bss段。（这回是真正的内核了，它会一直运行，直到机器重启或关机。）

2、  为内存建立最终的全局描述符表。

3、  建立页表以便可以开启分页功能。

4、  使能分页功能。

5、  初始化栈空间。

6、  创建最终的中断描述符表。

7、  最后，跳转执行一个体系结构无关的内核启动函数：start_kernel()。

下图显示了引导最后一步的代码执行流程：

 

与体系结构无关的Linux内核初始化过程

   start_kernel()看起来更像典型的内核代码，几乎全用C语言编写而且与特定机器无关。这个函数调用了一长串的函数，用来初始化各个内核子系统和数据结构，包括调度器（scheduler），内存分区（memory zones），计时器（time keeping）等等。之后，start_kernel()调用rest_init()，此时几乎所有的东西都可以工作了。rest_init()会创建一个内核线程，并以另一个函数kernel_init()作为此线程的入口点。之后，rest_init()会调用schedule()来激活任务调度功能，然后调用cpu_idle()使自己进入睡眠（sleep）状态，成为Linux内核中的一个空闲线程（idle thread）。cpu_idle()会在0号进程（process zero）中永远的运行下去。一旦有什么事情可做，比如有了一个活动就绪的进程（runnable process），0号进程就会激活CPU去执行这个任务，直到没有活动就绪的进程后才返回。

   但是，还有一个小麻烦需要处理。我们跟随引导过程一路走下来，这个漫长的线程以一个空闲循环（idle loop）作为结尾。处理器上电执行第一条跳转指令以后，一路运行，最终会到达此处。从复位向量（reset vector）->BIOS->MBR->引导装载程序->实模式内核->保护模式内核，跳转跳转再跳转，经过所有这些杂七杂八的步骤，最后来到引导处理器（boot processor）中的空闲循环cpu_idle()。看起来真的很酷。然而，这并非故事的全部，否则计算机就不会工作。

   在这个时候，前面启动的那个内核线程已经准备就绪，可以取代0号进程和它的空闲线程了。事实也是如此，就发生在kernel_init()开始运行的时刻（此函数之前被作为线程的入口点）。kernel_init()的职责是初始化系统中其余的CPU，这些CPU从引导过程开始到现在，还一直处于停机状态。之前我们看过的所有代码都是在一个单独的CPU上运行的，它叫做引导处理器（boot processor）。当其他CPU——称作应用处理器（application processor）——启动以后，它们是处于实模式的，必须通过一些初始化步骤才能进入保护模式。大部分的代码过程都是相同的，你可以参考startup_32，但对于应用处理器，还是有些细微的不同。最终，kernel_init()会调用init_post()，后者会尝试启动一个用户模式（user-mode）的进程，尝试的顺序为：/sbin/init，/etc/init，/bin/init，/bin/sh。如果都不行，内核就会报错。幸运的是init经常就在这些地方的，于是1号进程（PID 1）就开始运行了。它会根据对应的配置文件来决定启动哪些进程，这可能包括X11 Windows，控制台登陆程序，网络后台程序等。从而结束了引导进程，同时另一个Linux程序开始在某处运行。至此，让我祝福您的电脑可以一直正常运行下去，不出毛病。

   在同样的体系结构下，Windows的启动过程与Linux有很多相似之处。它也面临同样的问题，也必须完成类似的初始化过程。当引导过程开始后，一个最大的不同是，Windows把全部的实模式内核代码以及一部分初始的保护模式代码都打包到了引导加载程序（C：/NTLDR）当中。因此，Windows使用的二进制镜像文件就不一样了，内核镜像中没有包含两个部分的代码。另外，Linux把引导装载程序与内核完全分离，在某种程度上自动的形成不同的开源项目。下图显示了Windows内核主要的启动过程：

 

Windows内核初始化过程

   自然而然的，Windows用户模式的启动就非常不同了。没有/sbin/init程序，而是运行Csrss.exe和Winlogon.exe。Winlogon会启动Services.exe（它会启动所有的Windows服务程序）、Lsass.exe和本地安全认证子系统。经典的Windows登陆对话框就是运行在Winlogon的上下文中的。

   本文是引导启动系列话题的最后一篇。感谢每一位读者，感谢你们的反馈。我很抱歉，有些内容只能点到为止；我打算把它们留在其他文章中深入讨论，并尽量保持文章的长度适合blog的风格。下次我打算定期的撰写关于"Software Illustrated"的文章，就像本系列一样。最后，给大家一些参考资料：

?         最好也最重要的资料是实际的内核代码，Linux或BSD的都成。

?         Intel出版的杰出的软件开发人员手册，你可以免费下载到。

 

?         《理解Linux内核》是本好书，其中讨论了大量的Linux内核代码。这书也许有点过时有点枯燥，但我还是将它推荐给那些想要与内核心意相通的人们。《Linux设备驱动程序》读起来会有趣得多，讲的也不错，但是涉及的内容有些局限性。最后，网友Patrick Moroney推荐Robert Love所写的《Linux内核开发》，我曾听过一些对此书的正面评价，所以还是值得列出来的。

?         对于Windows，目前最好的参考书是《Windows Internals》，作者是David Solomon和Mark Russinovich，后者是Sysinternals的知名专家。这是本特棒的书，写的很好而且讲解全面。主要的缺点是缺少源代码的支持。

参考:

http://blog.csdn.net/drshenlei/article/details/4253179

 

 

转: 内存地址转换与分段

原文标题：Memory Translation and Segmentation

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

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

   本文是Intel兼容计算机（x86）的内存与保护系列文章的第一篇，延续了启动引导系列文章的主题，进一步分析操作系统内核的工作流程。与以前一样，我将引用Linux内核的源代码，但对Windows只给出示例（抱歉，我忽略了BSD，Mac等系统，但大部分的讨论对它们一样适用）。文中如果有错误，请不吝赐教。

 

  

在支持Intel的主板芯片组上，CPU对内存的访问是通过连接着CPU和北桥芯片的前端总线来完成的。在前端总线上传输的内存地址都是物理内存地址，编号从0开始一直到可用物理内存的最高端。这些数字被北桥映射到实际的内存条上。物理地址是明确的、最终用在总线上的编号，不必转换，不必分页，也没有特权级检查。然而，在CPU内部，程序所使用的是逻辑内存地址，它必须被转换成物理地址后，才能用于实际内存访问。从概念上讲，地址转换的过程如下图所示：

 

x86 CPU开启分页功能后的内存地址转换过程

  

此图并未指出详实的转换方式，它仅仅描述了在CPU的分页功能开启的情况下内存地址的转换过程。如果CPU关闭了分页功能，或运行于16位实模式，那么从分段单元（segmentation unit）输出的就是最终的物理地址了。当CPU要执行一条引用了内存地址的指令时，转换过程就开始了。第一步是把逻辑地址转换成线性地址。但是，为什么不跳过这一步，而让软件直接使用线性地址（或物理地址呢？）其理由与："人类为何要长有阑尾？它的主要作用仅仅是被感染发炎而已"大致相同。这是进化过程中产生的奇特构造。要真正理解x86分段功能的设计，我们就必须回溯到1978年。

  

最初的8086处理器的寄存器是16位的，其指令集大多使用8位或16位的操作数。这使得代码可以控制216个字节（或64KB）的内存。然而Intel的工程师们想要让CPU可以使用更多的内存，而又不用扩展寄存器和指令的位宽。于是他们引入了段寄存器（segment register），用来告诉CPU一条程序指令将操作哪一个64K的内存区块。一个合理的解决方案是：你先加载段寄存器，相当于说"这儿！我打算操作开始于X处的内存区块"；之后，再用16位的内存地址来表示相对于那个内存区块（或段）的偏移量。总共有4个段寄存器：一个用于栈（ss），一个用于程序代码（cs），两个用于数据（ds，es）。在那个年代，大部分程序的栈、代码、数据都可以塞进对应的段中，每段64KB长，所以分段功能经常是透明的。

   现今，分段功能依然存在，一直被x86处理器所使用着。每一条会访问内存的指令都隐式的使用了段寄存器。比如，一条跳转指令会用到代码段寄存器（cs），一条压栈指令（stack push instruction）会使用到堆栈段寄存器（ss）。在大部分情况下你可以使用指令明确的改写段寄存器的值。段寄存器存储了一个16位的段选择符（segment selector）；它们可以经由机器指令（比如MOV）被直接加载。唯一的例外是代码段寄存器（cs），它只能被影响程序执行顺序的指令所改变，比如CALL或JMP指令。虽然分段功能一直是开启的，但其在实模式与保护模式下的运作方式并不相同的。

   在实模式下，比如在引导启动的初期，段选择符是一个16位的数值，指示出一个段的开始处的物理内存地址。这个数值必须被以某种方式放大，否则它也会受限于64K当中，分段就没有意义了。比如，CPU可能会把这个段选择符当作物理内存地址的高16位（只需将之左移16位，也就是乘以216）。这个简单的规则使得：可以按64K的段为单位，一块块的将4GB的内存都寻址到。遗憾的是，Intel做了一个很诡异的设计，让段选择符仅仅乘以24（或16），一举将寻址范围限制在了1MB，还引入了过度复杂的转换过程。下述图例显示了一条跳转指令，cs的值是0x1000：

 

 

实模式分段功能

  

实模式的段地址以16个字节为步长，从0开始编号一直到0xFFFF0（即1MB）。你可以将一个从0到0xFFFF的16位偏移量（逻辑地址）加在段地址上。在这个规则下，对于同一个内存地址，会有多个段地址/偏移量的组合与之对应，而且物理地址可以超过1MB的边界，只要你的段地址足够高（参见臭名昭著的A20线）。同样的，在实模式的C语言代码中，一个远指针（far pointer）既包含了段选择符又包含了逻辑地址，用于寻址1MB的内存范围。真够"远"的啊。随着程序变得越来越大，超出了64K的段，分段功能以及它古怪的处理方式，使得x86平台的软件开发变得非常复杂。这种设定可能听起来有些诡异，但它却把当时的程序员推进了令人崩溃的深渊。

  

在32位保护模式下，段选择符不再是一个单纯的数值，取而代之的是一个索引编号，用于引用段描述符表中的表项。这个表为一个简单的数组，元素长度为8字节，每个元素描述一个段。看起来如下：

 

段描述符

  

有三种类型的段：代码，数据，系统。为了简洁明了，只有描述符的共有特征被绘制出来。基地址（base address）是一个32位的线性地址，指向段的开始；段界限（limit）指出这个段有多大。将基地址加到逻辑地址上就形成了线性地址。DPL是描述符的特权级（privilege level），其值从0（最高特权，内核模式）到3（最低特权，用户模式），用于控制对段的访问。

  

这些段描述符被保存在两个表中：全局描述符表（GDT）和局部描述符表（LDT）。电脑中的每一个CPU（或一个处理核心）都含有一个叫做gdtr的寄存器，用于保存GDT的首个字节所在的线性内存地址。为了选出一个段，你必须向段寄存器加载符合以下格式的段选择符：

 

段选择符

  

对GDT，TI位为0；对LDT，TI位为1；index指出想要表中哪一个段描述符（译注：原文是段选择符，应该是笔误）。对于RPL，请求特权级（Requested Privilege Level），以后我们还会详细讨论。现在，需要好好想想了。当CPU运行于32位模式时，不管怎样，寄存器和指令都可以寻址整个线性地址空间，所以根本就不需要再去使用基地址或其他什么鬼东西。那为什么不干脆将基地址设成0，好让逻辑地址与线性地址一致呢？Intel的文档将之称为"扁平模型"（flat model），而且在现代的x86系统内核中就是这么做的（特别指出，它们使用的是基本扁平模型）。基本扁平模型（basic flat model）等价于在转换地址时关闭了分段功能。如此一来多么美好啊。就让我们来看看32位保护模式下执行一个跳转指令的例子，其中的数值来自一个实际的Linux用户模式应用程序：

 

保护模式的分段

  

段描述符的内容一旦被访问，就会被cache（缓存），所以在随后的访问中，就不再需要去实际读取GDT了，否则会有损性能。每个段寄存器都有一个隐藏部分用于缓存段选择符所对应的那个段描述符。如果你想了解更多细节，包括关于LDT的更多信息，请参阅《Intel System Programming Guide》3A卷的第三章。2A和2B卷讲述了每一个x86指令，同时也指明了x86寻址时所使用的各种类型的操作数：16位，16位加段描述符（可被用于实现远指针），32位，等等。

  

在Linux上，只有3个段描述符在引导启动过程被使用。他们使用GDT_ENTRY宏来定义并存储在boot_gdt数组中。其中两个段是扁平的，可对整个32位空间寻址：一个是代码段，加载到cs中，一个是数据段，加载到其他段寄存器中。第三个段是系统段，称为任务状态段（Task State Segment）。在完成引导启动以后，每一个CPU都拥有一份属于自己的GDT。其中大部分内容是相同的，只有少数表项依赖于正在运行的进程。你可以从segment.h看到Linux GDT的布局以及其实际的样子。这里有4个主要的GDT表项：2个是扁平的，用于内核模式的代码和数据，另两个用于用户模式。在看这个Linux GDT时，请留意那些用于确保数据与CPU缓存线对齐的填充字节——目的是克服冯·诺依曼瓶颈。最后要说说，那个经典的Unix错误信息"Segmentation fault"（分段错误）并不是由x86风格的段所引起的，而是由于分页单元检测到了非法的内存地址。唉呀，下次再讨论这个话题吧。

  

Intel巧妙的绕过了他们原先设计的那个拼拼凑凑的分段方法，而是提供了一种富于弹性的方式来让我们选择是使用段还是使用扁平模型。由于很容易将逻辑地址与线性地址合二为一，于是这成为了标准，比如