公司规划将一款游戏移植到某嵌入式平台，Sam做性能分析时发现此平台CPU是双核。于是思考如何利用双核来提高游戏效果。先从简单的基础知识说起：

1. 在Linux下，如何确认是多核或多CPU:

#cat /proc/cpuinfo

如果有多个类似以下的项目，则为多核或多CPU:

processor       : 0

......

processor       : 1

2. Linux下，如何看每个CPU的使用率：

#top -d 1

之后按下1. 则显示多个CPU

Cpu0  :  1.0%us,  3.0%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

3. 如何察看某个进程在哪个CPU上运行：

#top -d 1

之后按下f.进入top Current Fields设置页面：

选中：j: P          = Last used cpu (SMP)

则多了一项：P 显示此进程使用哪个CPU。

Sam经过试验发现：同一个进程，在不同时刻，会使用不同CPU Core.这应该是Linux Kernel SMP处理的。

4. 配置Linux Kernel使之支持多Core：

内核配置期间必须启用 CONFIG_SMP 选项，以使内核感知 SMP。

Processor type and features  ---> Symmetric multi-processing support

察看当前Linux Kernel是否支持（或者使用）SMP

#uname -a

5. Kernel 2.6的SMP负载平衡：

在 SMP 系统中创建任务时，这些任务都被放到一个给定的 CPU 运行队列中。通常来说，我们无法知道一个任务何时是短期存在的，何时需要长期运行。因此，最初任务到 CPU 的分配可能并不理想。

为了在 CPU 之间维护任务负载的均衡，任务可以重新进行分发：将任务从负载重的 CPU 上移动到负载轻的 CPU 上。Linux 2.6 版本的调度器使用负载均衡（load balancing） 提供了这种功能。每隔 200ms，处理器都会检查 CPU 的负载是否不均衡；如果不均衡，处理器就会在 CPU 之间进行一次任务均衡操作。

这个过程的一点负面影响是新 CPU 的缓存对于迁移过来的任务来说是冷的（需要将数据读入缓存中）。

记住 CPU 缓存是一个本地（片上）内存，提供了比系统内存更快的访问能力。如果一个任务是在某个 CPU 上执行的，与这个任务有关的数据都会被放到这个 CPU 的本地缓存中，这就称为热的。如果对于某个任务来说，CPU 的本地缓存中没有任何数据，那么这个缓存就称为冷的。

不幸的是，保持 CPU 繁忙会出现 CPU 缓存对于迁移过来的任务为冷的情况。

6. 应用程序如何利用多Core :

开发人员可将可并行的代码写入线程，而这些线程会被SMP操作系统安排并发运行。

另外，Sam设想，对于必须顺序执行的代码。可以将其分为多个节点，每个节点为一个thread.并在节点间放置channel.节点间形如流水线。这样也可以大大增强CPU利用率。

例如：

游戏可以分为3个节点。

1.接受外部信息，声称数据 （1ms）

2.利用数据，物理运算（3ms）

3.将物理运算的结果展示出来。(2ms)

如果线性编程，整个流程需要6ms.

但如果将每个节点作为一个thread。但thread间又同步执行。则整个流程只需要3ms.

附1：

多处理的历史

多处理起源于 20 世纪 50 年代中期的一些公司，这些公司中有些您可能知道，而另一些您可能就不记得了（IBM、Digital Equipment Corporation、Control Data Corporation）。20 世纪 60 年代早期，Burroughs Corporation 引入了一种对称 MIMD 多处理器，它带有四个 CPU 并通过交叉开关可连接最多十六个内存模块（第一种 SMP 架构）。1964 年引入了 CDC 6600，它的使用比较成功并得到流行，它提供了一个带有十个子处理器（外围处理单元）的 CPU。20 世纪 60 年代末，Honeywell 发布了它的第一个 Multics 系统，这是带八个 CPU 的另一种对称多处理系统。

在开发多处理系统的同时，各种技术的使用也提高了缩小处理器体积和运行更快的时钟频率的能力。20 世纪 80 年代，Cray Research 等公司引入了多处理器系统和类似 UNIX® 的操作系统（CX-OS），以便利用这些能力。

20 世纪 80 年代末期，随着单处理器个人计算机系统（如 IBM PC）的流行，多处理系统的使用呈下降趋势。但是到了二十年后的现在，多处理利用对称多处理技术又回到了个人计算机系统中。

Amdahl 法则

Gene Amdahl 是一名计算机架构师、IBM 职员，在 IBM、Amdahl Corporation（以他的名字命名的企业）和其他一些公司从事计算机架构开发。但是最著名的是他的法则，该法则用于在改进系统的一部分后预测最大的预期系统改进。它主要用来计算使用多处理器后理论上的最大性能改进（参见图 1）。

图 1. 处理器并行化的 Amdahl 法则

使用图 1 所示的等式，可计算系统的最大性能改进，N 表示处理器的数目，而因数 F 指定不能并行化的系统部分（即本质上顺序的系统部分）。结果如图 2 所示。

图 2. 最多十个 CPU 的 Amdahl 法则

图 2 中最上面的一条线显示了处理器的数目。理想状态下，添加另外的处理器来解决问题时，希望看到这样的性能增长。不幸的是，并非所有的问题都可以并行化，而且还有管理处理器的开销，所以速度的提高并没有这么大。底部（紫色的线）是一个 90% 的处理属于顺序性的问题例子。在此图中，最佳的情况是棕色的线，它展示了一个 10% 顺序性（因此 90% 可并行化）的问题。即使在这种情况下，十个处理器的执行性能也只比五个稍好一点儿。

附2：

什么是调度器？

通常来说，操作系统是应用程序和可用资源之间的媒介。典型的资源有内存和物理设备。但是 CPU 也可以认为是一个资源，调度器可以临时分配一个任务在上面执行（单位是时间片）。调度器使得我们同时执行多个程序成为可能，因此可以与具有各种需求的用户共享 CPU。

调度器的一个重要目标是有效地分配 CPU 时间片，同时提供很好的用户体验。调度器还需要面对一些互相冲突的目标，例如既要为关键实时任务最小化响应时间，又要最大限度地提高 CPU 的总体利用率。下面我们来看一下 Linux 2.6 调度程序是如何实现这些目标的，并与以前的调度器进行比较。

回页首

早期 Linux 调度器的问题

O-notation 的重要性 O-notation 可以告诉我们一个算法会占用多少时间。一个 O(n) 算法所需要的时间依赖于输入的多少（与 n 是线性关系），而 O(n^2) 则是输入数量的平方。O(1) 与输入无关，可以在固定的时间内完成操作。

在 2.6 版本的内核之前，当很多任务都处于活动状态时，调度器有很明显的限制。这是由于调度器是使用一个复杂度为 O(n) 的算法实现的。在这种调度器中，调度任务所花费的时间是一个系统中任务个数的函数。换而言之，活动的任务越多，调度任务所花费的时间越长。在任务负载非常重时，处理器会因调度消耗掉大量的时间，用于任务本身的时间就非常少了。因此，这个算法缺乏可伸缩性。

在对称多处理系统（SMP）中，2.6 版本之前的调度器对所有的处理器都使用一个运行队列。这意味着一个任务可以在任何处理器上进行调度 —— 这对于负载均衡来说是好事，但是对于内存缓存来说却是个灾难。例如，假设一个任务正在 CPU-1 上执行，其数据在这个处理器的缓存中。如果这个任务被调度到 CPU-2 上执行，那么数据就需要先在 CPU-1 使其无效，并将其放到 CPU-2 的缓存中。

以前的调度器还使用了一个运行队列锁；因此在 SMP 系统中，选择一个任务执行就会阻碍其他处理器操作这个运行队列。结果是空闲处理器只能等待这个处理器释放出运行队列锁，这样会造成效率的降低。

最后，在早期的内核中，抢占是不可能的；这意味着如果有一个低优先级的任务在执行，高优先级的任务只能等待它完成。