Linux内注释第10章 对称多处理.docVIP

第10章 对称多处理（SMP） 在全书的讨论过程中，我一直在忽略SMP代码，而倾向于把注意力集中在只涉及一个处理器的相对简单的情况。现在已经到了重新访问读者已经熟悉的一些内容的时候了，不过要从一个新的角度来审视它：当内核必须支持多于一个CPU的机器时将发生什么？ 在一般情况下，使用多于一个CPU来完成工作被称为并行处理（parallel processing），它可以被想象成是一段频谱范围，分布式计算（distributed computing）在其中一端，而对称多处理（SMP—symmetric multiprocessing）在另一端。通常，当你沿着该频谱从分布式计算向SMP移动时，系统将变得更加紧密耦合——在CPU之间共享更多的资源——而且更加均匀。在一个典型的分布式系统中，每个CPU通常都至少拥有它自己的高速缓存和RAM。每个CPU还往往拥有自己的磁盘、图形子系统、声卡，监视器等等。 在极端的情形下，分布式系统经常不外乎就是一组普通的计算机，虽然它们可能具有完全不同的体系结构，但是都共同工作在某个网络之上——它们甚至不需要在同一个LAN里。读者可能知道的一些有趣的分布式系统包括：Beowulf，它是对相当传统而又极其强大的分布式系统的一个通用术语称谓；SETI@home，它通过利用上百万台计算机来协助搜寻地外生命的证据，以及distributed.net，它是类似想法的另一个实现，它主要关注于地球上产生的密码的破解。 SMP是并行处理的一个特殊情况，系统里所有CPU 都是相同的。举例来说，SMP就是你共同支配两块80486或两块Pentium（具有相同的时钟速率）处理器，而不是一块80486和一块Pentium，或者一块Pentium和一块PowerPC。在通常的用法中，SMP也意味着所有CPU都是“在相同处境下的”——那就是它们都在同一个计算机里，通过特殊用途的硬件进行彼此通信。 SMP系统通常是另一种平常的单一（single）计算机——只不过具有两个或更多的CPU。因此，SMP系统除了CPU以外每样东西只有一个——一块图形卡、一个声音卡，等等之类。诸如RAM和磁盘这样以及类似的资源都是为系统的CPU们所共享的。（尽管现在SMP系统中每个CPU都拥有自己的高存缓存的情况已经变得愈发普遍了。） 分布式配置需要很少的或者甚至不需要来自内核的特殊支持；节点之间的协同是依靠用户空间的应用程序或者诸如网络子系统之类未经修改的内核组件来处理的。但是SMP在计算机系统内创建了一个不同的硬件配置，并由此需要特殊用途的内核支持。比如，内核必须确保CPU在访问它们的共享资源时要相互合作——这是一个读者在UP世界中所不曾遇到的问题。 SMP的逐渐普及主要是因为通过SMP所获得的性能的提高要比购买几台独立的机器再把它们组合在一起更加便宜和简单，而且还因为它与等待下一代CPU面世相比要快的多。 非对称多CPU的配置没有受到广泛支持，这是因为对称配置情况所需的硬件和软件支持通常较为简单。不过，内核代码中平台无关的部分实际上并不特别关心是否CPU是相同的——即，是否配置是真正对称的——尽管它也没有进行任何特殊处理以支持非对称配置。例如，在非对称多处理系统中，调度程序应该更愿意在较快的而不是较慢的CPU上运行进程，但是Linux内核没有对此进行区别。 谚语说得好，“天下没有白吃的午餐”。对于SMP，为提高的性能所付出的代价就是内核复杂度的增加和协同开销的增加。CPU必须安排不互相干涉彼此的工作，但是它们又不能在这种协同上花费太多时间以至于它们显著地耗费额外的CPU能力。 代码的SMP特定部分由于UP机器存在的缘故而被单独编译，所以仅仅因为有了SMP寄存器是不会使UP寄存器慢下来的。这满足两条久经考验的原理：“为普遍情况进行优化”（UP机器远比SMP机器普遍的多）以及“不为用不着的东西花钱”。 并行程序设计概念及其原语 具有两个CPU的SMP配置可能是最简单的并行配置，但就算是这最简单的配置也揭开了未知问题的新领域——即使要两块相同的CPU在一起协调的工作，时常也都像赶着猫去放牧一样困难。幸运的是，至少30年前以来，就在这个项目上作了大量和非常熟悉的研究工作。（考虑到第一台电子数字计算机也只是在50年前建造的，那这就是一段令人惊讶的相当长的时间了。）在分析对SMP的支持是如何影响内核代码之前，对该支持所基于的若干理论性概念进行一番浏览将能够极大的简化这个问题。 注意：并非所有这些信息都是针对SMP内核的。一些要讨论的问题甚至是由UP内核上的并行程序设计所引起的，既要支持中断也要处理进程之间的交互。因此即使你对SMP问题没有特别的兴趣，这部分的讨论也值得一看。 原子操作 在一个并行的环境里，某些动作必须以一种基本的原子方式（atomically）执行