基于NUMA架构的高性能服务器技术(2)

　　三、NUMA调度器
　　NUMA系统中，由于局部内存的访存延迟低于远地内存访存延迟，因此将进程分配到局部内存附近的处理器上可极大优化应用程序的性能。Linux 2.4内核中的调度器由于只设计了一个运行队列，可扩展性较差，在SMP平台表现一直不理想。当运行的任务数较多时，多个CPU增加了系统资源的竞争，限制了负载的吞吐率。在2.5内核开发时，Ingo Molnar写了一个多队列调度器，称为O(1)，从2.5.2开始O(1)调度器已集成到2.5内核版本中。O(1)是多队列调度器，每个处理器都有一条自己的运行队列，但由于O(1)调度器不能较好地感知NUMA系统中结点这层结构，从而不能保证在调度后该进程仍运行在同一个结点上，为此，Eirch Focht开发了结点亲和的NUMA调度器，它是建立在Ingo Molnar的O(1)调度器基础上的，Eirch将该调度器向后移植到2.4.X内核中，该调度器最初是为基于IA64的NUMA机器的2.4内核开发的，后来Matt Dobson将它移植到基于X86的NUMA-Q硬件上。
　　
　　3.1 初始负载平衡
　　
　　在每个任务创建时都会赋予一个HOME结点（所谓HOME结点，就是该任务获得最初内存分配的结点），它是当时创建该任务时全系统负载最轻的结点，由于目前Linux中不支持任务的内存从一个结点迁移到另一个结点，因此在该任务的生命期内HOME结点保持不变。一个任务最初的负载平衡工作（也就是选该任务的HOME结点）缺省情况下是由exec()系统调用完成的，也可以由fork()系统调用完成。在任务结构中的node_policy域决定了最初的负载平衡选择方式。
　　　javascript:window.open(this.src);" style="CURSOR: pointer" onload="return imgzoom(this,550)">
　　3.2" 动态负载平衡
　　
　　在结点内，该NUMA调度器如同O(1)调度器一样。在一个空闲处理器上的动态负载平衡是由每隔1ms的时钟中断触发的，它试图寻找一个高负载的处理器，并将该处理器上的任务迁移到空闲处理器上。在一个负载较重的结点，则每隔200ms触发一次。调度器只搜索本结点内的处理器，只有还没有运行的任务可以从Cache池中移动到其它空闲的处理器。
　　
　　如果本结点的负载均衡已经非常好，则计算其它结点的负载情况。如果某个结点的负载超过本结点的25％，则选择该结点进行负载均衡。如果本地结点具有平均的负载，则延迟该结点的任务迁移；如果负载非常差，则延迟的时间非常短，延迟时间长短依赖于系统的拓扑结构。
　　
　　四、CpuMemSets
　　SGI的Origin 3000 clearcase/" target="_blank" >ccNUMA系统在许多领域得到了广泛应用，是个非常成功的系统，为了优化Origin 3000的性能，SGI的IRIX操作系统在其上实现了CpuMemSets，通过将应用与CPU和内存的绑定，充分发挥NUMA系统本地访存的优势。Linux在NUMA项目中也实现了CpuMemSets，并且在SGI的Altix 3000的服务器中得到实际应用。
　　
　　CpuMemSets为Linux提供了系统服务和应用在指定CPU上调度和在指定结点上分配内存的机制。CpuMemSets是在已有的Linux调度和资源分配代码基础上增加了cpumemmap和cpumemset两层结构，底层的cpumemmap层提供一个简单的映射对，主要功能是：将系统的CPU号映射到应用的CPU号、将系统的内存块号映射到应用的内存块号；上层的cpumemset层主要功能是：指定一个进程在哪些应用CPU上调度任务、指定内核或虚拟存储区可分配哪些应用内存块。
　　
　　4.1 cpumemmap
　　
　　内核任务调度和内存分配代码使用系统号，系统中的CPU和内存块都有对应的系统号。应用程序使用的CPU号和内存块号是应用号，它用于指定在cpumemmap中CPU和内存的亲和关系。每个进程、每个虚拟内存区和Linux内核都有cpumemmap，这些映射是在fork()、exec()调用或创建虚拟内存区时继承下来的，具有root权限的进程可以扩展cpumemmap，包括增加系统CPU和内存块。映射的修改将导致内核调度代码开始运用新的系统CPU，存储分配代码使用新的内存块分配内存页，而已在旧块上分配的内存则不能迁移。Cpumemmap中不允许有空洞，例如，假设cpumemmap的大小为n，则映射的应用号必须从0到n-1。Cpumemmap中系统号和应用号并不是一对一的映射，多个应用号可以映射到同一个系统号。
　　
　　4.2 cpumemset
　　
　　系统启动时，Linux内核创建一个缺省的cpumemmap和cpumemset，在初始的cpumemmap映射和cpumemset中包含系统目前所有的CPU和内存块信息。
　　
　　Linux内核只在该任务cpumemset的CPU上调度该任务，并只从该区域的内存列表中选择内存区分配给用户虚拟内存区，内核则只从附加到正在执行分配请求CPU的cpumemset内存列表中分配内存。
　　
　　一个新创建的虚拟内存区是从任务创建的当前cpumemset获得的，如果附加到一个已存在的虚拟内存区时，情况会复杂些，如内存映射对象和Unix System V的共享内存区可附加到多个进程，也可以多次附加到同一个进程的不同地方。如果被附加到一个已存在的内存区，缺省情况下新的虚拟内存区继承当前附加进程的cpumemset，如果此时标志位为CMS_SHARE，则新的虚拟内存区链接到同一个cpumemset。
　　
　　当分配页时，如果该任务运行的CPU在cpumemset中有对应的存储区，则内核从该CPU的内存列表中选择，否则从缺省的CPU对应的cpumemset选择内存列表。
　　
　　4.3硬分区和CpuMemSets
　　
　　在一个大的NUMA系统中，用户往往希望控制一部分CPU和内存给某些特殊的应用。目前主要有两种技术途径：硬分区和软分区技术，CpuMemSets是属于软分区技术。将一个大NUMA系统的硬分区技术与大NUMA系统具有的单系统映像优势是矛盾的，而CpuMemSets允许用户更加灵活的控制，它可以重叠、划分系统的CPU和内存，允许多个进程将系统看成一个单系统映像，并且不需要重启系统，保障某些CPU和内存资源在不同的时间分配给指定的应用。
　　
　　SGI的CpuMemSets软分区技术有效解决硬分区中的不足，一个单系统的SGI ProPack Linux服务器可以分成多个不同的系统，每个系统可以有自己的控制台、根文件系统和IP网络地址。每个软件定义的CPU组可以看成一个分区，每个分区可以重启、安装软件、关机和更新软件。分区间通过SGI NUMAlink连接进行通讯，分区间的全局共享内存由XPC和XPMEM内核模块支持，它允许一个分区的进程访问另一个分区的物理内存。
　　
　　五、测试
　　为了有效验证Linux NUMA系统的性能和效率，我们在SGI公司上海办事处测试了NUMA架构对SGI Altix 350性能。
　　
　　该系统的配置如下：
　　CPU：8个1.5 GHz Itanium2
　　内存：8GB
　　互连结构：如图3所示
　　　
　　图3" SGI Altix350 4个计算模块的Ring拓扑
　　测试用例：
　　
　　1、Presta MPI测试包（来自ASCI Purple的Benchmark）
　　从互连拓扑结构可以看出，计算模块内部的访存延迟不需要通过互连，延迟最逗，剩下的需要通过1步或2步互连到达计算模块，我们通过Presta MPI测试包，重点测试每步互连对系统的影响，具体结果如下：
　　　
　　2、NASA的NPB测试
　　"
　　上述测试表明，SGI" Altix 350系统具有较高的访存和计算性能，Linux NUMA技术已进入实用阶段。

原文转自：http://www.ltesting.net