面向计算功耗效率的超线程调度研究

林何磊,冯国富,冀续烨,陈明

上海海洋大学信息学院,农业部渔业信息重点实验室,上海201306

面向计算功耗效率的超线程调度研究

林何磊,冯国富*,冀续烨,陈明

上海海洋大学信息学院,农业部渔业信息重点实验室,上海201306

相对于传统计算侧重关注计算性能及并行可扩展性而忽视功耗因素，本文分析Hyper threading服务器的功耗特性，基于超线程计算单元拓扑感知，引入面向能量效率的超线程调度策略，利用线程亲和性改变线程计算单元分配顺序以提高系统计算与能量效率，克服操作系统默认线程调度策略单一、呆板的缺陷。实验结果表明，所提方案可在应用层、运行时支持层和操作系统层三层中灵活配置，以影响不同范围内的计算应用，在提高能量效率的同时，从计算单元利用角度提高计算资源利用率。

超线程;能量效率;计算单元调度;计算单元拓扑感知

SMT计算单元与传统处理器单元存在区别，但OS通常不能有效感知SMT计算单元与传统计算单元的不同，从而造成SMT的技术优势不能得以发挥。以上特点使得SMT技术虽从95年左右就已出现，但一直没有得到很好的推广。Intel早在2000年的P4 Netburst微架构就引入Hyper Threading，但在2006年Core微架构中又放弃该技术。当前低碳节能已成为全球最受关注的话题之一，并亦成为国内外IT领域的研究热点，计算结点的功耗不仅直接影响计算中心、数据中心的运营成本，还进一步间接影响用于散热方面的开销及对设备器件寿命的影响[1]。SMT技术由于在资源、功耗效率方面的优点，再次受到研究界的关注，Intel自2008年的Nehalem微架构又重新启用了Hyper Threading技术，但Hyper Threading不能被OS有效感知等问题仍然制约该技术的推广与普及。

1 Hyper Threading线程调度中存在的问题

1.1 基于Hyper Threading的计算系统

目前基于Hyper Threading的高性能服务器通常采用NUMA架构。如图1所示，在一个典型的双路Intel Xeon单结点服务器中，配置二路物理处理器，每路物理处理器中有4个处理核心Cx（x=0,1,2,3），每个核心含两个Hyper Threading线程单元Tx0,Tx1（x=0,1,2,3）。

虽然每个处理器核上的2个Hyper Threading线程单元是对等的，但第一个获得计算任务的线程单元可以独享处理器核心上全部执行资源直到另一线程单元上有任务执行。从OS线程调度角度而言，由于分配任务的先后顺序及对计算资源的独享与共享，其二者又是不完全对等的。

为表述方便，在不至引起混乱的前提下，本文将处理器核心上独占执行资源、第一个执行任务的Hyper Threading线程称为全资源线程单元，而其后在相同计算资源上启动，并与之前独占资源的线程共享执行资源的线程单元称为共享线程单元。此时先前的全资源线程单元因为要和后者共享计算资源，自动演化为共享线程单元，也即共享线程单元是成对出现的。当计算任务申请的计算单元为奇数时，至少存在一个全资源线程单元。在对计算效率和成本进行分析比较时，以全资源线程单元为单位更具有可比性。

图1 基于Hyper Threading的计算系统Fig.1 The computing system on Hyper Threading

传统OS（如Linux）在对Hyper Threading处理器线程单元进行管理时，通常是优先分配系统中的全资源线程单元，然后再分配共享线程单元。如本文实验表明，一台双路Intel Xeon L5520服务器基于Linux 3.6.11内核会按表1所示顺序来为计算任务分配计算资源。表1以“(Processor,Core,Thread)，alloc_seq”的形式来标识一次分配中计算单元所处的“物理处理器号，处理器核心号与线程单元号及Linux内核分配计算资源的顺序”；黑色实线箭头指示全资源线程单元的分配顺序，虚线箭头指示共享线程单元的分配顺序。

由表1可以看出Linux计算单元分配策略首先以全资源线程单元来满足计算需求，当全资源线程单元不能满足需求时，才分配共享线程单元，从而使计算请求得到很好、很快地响应。这种分配方案对于密集事务型操作会获得比较好的用户响应和系统吞吐量。但如表1所示，这种分配策略通过快速覆盖全资源线程单元的来提高性能，却忽视了对共享线程单元的利用，没有充分发挥SMT技术的特点。

表1 Linux分配SMT计算单元的顺序Table 1 The allocation sequence of Linux kernel for SMT units

1.2 OS线程单元分配策略下的并行性能

由于受并行可扩展性的影响，并行计算中投入计算单元的数量通常有一个上限。超过该上限后，再投入新的计算资源，计算资源虽然增多，但性能的提高却不再明显。

依据Amdahl定律：令S为某一计算中难以并行化执行的部分，P为可并行的部分(S+P=1)，那么投入N个计算单元最大可能的加速比SN为：用代表计算的并行效率，以S=0.1为例，从并行效率考虑，当时，再投入新的计算单元加速已不明显（即：N＞1/S+1）。也即，在上述假设下N＞11后加速效果不再明显。目前随着制造工艺的发展，单个处理器的核心数越来越多，SMP服务器处理器路数也不断提高。如HP DK388P采用2路XeonE5-2667，每处理器6核心、12线程；浪潮正睿6540S2，采用四路Xeon E7-8850处理器，每处理器10核心，20线程。如果按照Linux默认的分配策略，随着计算结点内计算单元增多，受限于可扩展性，大量计算单元要么没有投入计算的机会，要么投入后对计算的贡献微乎其微。在Hyper Threading架构中，因为OS要分配将全资源线程单元分配完后再分配共享线程单元，而共享线程单元投放后，要和另一个单元共享计算资源，共享线程单元的计算能力只相当于全资源线程单元的σ倍（0＜σ＜1/2）（经典文献中认为Hyper Threading可以在典型环境下提高30%的计算性能），这使得Hyper Threading单元的贡献更不明显。

表2 Phoenix2.0下Word counter执行时间Table 2 Phoenix 2.0 parallel computing for Word counter(s)

表2为在HP DK388P，基于Linux 2.6.32-131.0.15.el6.x86_64内核运行共享存储模式Mapreduce实现Phoenix 2.0[2]中word counter案例的并行执行时间（数据集大小分别为3200 M、6400 M）。由于Linux是先分配全资源线程单元，而HP DK388P全资源线程单元只有12个。表2显示，当申请计算单元数达到全资源线程单元数上限12后（SN/N分别达到0.54和0.63），加速比不再明显上升。当12个全资源线程单元分配完后，Linux才会再投入共享线程单元，然而此时投入共享线程单元不仅会增大系统功耗，同时对于性能的提升作用不大，这也是多数高性能应用选择关闭SMT功能的原因(本文按参考文献[2,3]对实验案例进行了优化，不优化情况下并行执行效果会更差)。

综上所述，操作系统单一、僵化的Hyper Threading计算单元分配策略过晚地投放共享线程单元，使得Hyper Threading性能得不到有效发挥，造成计算资源、功耗与调度机会的浪费。另外对于OS而言，全资源线程单元与共享线程单元统一被视为独立的计算单元，忽视了全资源线程单元和共享线程单元二者计算能力不对等的特点，使基于SMT的共享存储并行计算易引入负载均衡问题。因此研究更灵活的Hyper Threading计算单元分配策略是绿色、高效计算的内丰需求，通过改变并行计算分配线程单元策略，让Hyper Threading共享线程单元在合适的时机“贡献”计算能力，能更好利用SMT机制的IPL、TPL双重并行性、充分挖掘SMT在功耗与成本上的优势，便于用户寻找性能与功耗的平衡点。

2 基于超线程拓扑感知的Hyper Threading线程调度策略

2.1 OS线程单元功耗/成本分析

OS僵化的线程单元分配策略不能充分发挥SMT ILP和TLP的技术特点。SMT的优势在于使用较少的附加资源（包括功耗）来挖掘执行单元的利用率。

设Hyper Threading计算结点有Np个物理处理器，每个物理处理器上有Nc个核，每核2个SMT线程单元。假设优先在已有负载的处理器上分配全资源线程单元。

设结点(Node)空载功率为Pn，每投入一个物理处理器（Socket）功率增加值为Ps，投入一个全资源线程单元(Core)功率增加值为Pc，投入一个物理

线程(Thread)单元功率增加值为Pt。

则若不启用Hyper Threading，单计算结点上启用线程数为T，计算结点功率为：

如果启用Hyper Threading，单计算结点启用线程数为T（为简单记，设T为偶数）计算功率为：

表3 超线程单元功率（单位：W）Table 3 The powers of hyper threading units(W)

表3列出了在Dell C6100单结点服务器（Linux 3.6.11）上测得的不同个数计算单元满负荷情况下计算结点功率的变化情况。测量方法：使用Linux默认分配计算单元策略，当系统负荷与功率稳定后对系统功率值连续采样8 s，每秒采样1次，去掉最大值与最小值，再求平均值。

从表3得出Dell C6100单结点服务器：

①Pn=76.11；

②当因负载需求使第一个物理CPU中第一个计算单元满载时（启动第一个物理CPU），系统功率增加35.61 W;

③使第二个物理CPU中第一个计算单元满载时（启动第二个物理CPU，第5个核心投入计算时），系统功率增加约14.77 W，为简化计算我们将Ps取②③的平均值25.19 W;

④在物理CPU上启动1个全资源线程单元功率平均增加Pc=9.68 W；

⑤而使一个共享线程单元满载功率平均增加Pt=2.61 W。

①Pn=106.41；

②当因负载需求使第一个物理CPU中第一个计算单元满载时（启动第一个物理CPU），系统功率增加43.90 W;

③使第二个物理CPU中第一个计算单元满载时（启动第二个物理CPU），系统功率增加约35.58 W，为简化计算我们将Ps取②③的平均值39.74 W;

④在物理CPU上启动1个全资源线程单元功率平均增加Pc=11.13 W；

⑤而使一个共享线程单元满载功率平均增加Pt=2.83 W。

在超声辅助提取多糖的单因素试验基础上，对影响枸杞多糖提取率的主要因素(料液比、超声时间、超声温度、超声次数)进行正交试验，各组提取液过滤定容，按照苯酚—硫酸法在波长490nm下测定吸光值，计算多糖含量，选出最优的工艺参数。

因此可得出，基于表1的OS线程单元分配策略虽然性能提升很快，但功耗与成本增长也较快。

2.2 不同需求下的计算单元分配

表4 计算单元分配要素Table 4 The key elements of computing units allocation

为便于描述，选择结构相对简单的Dell C6100服务器为例进行分析。表4列出了该结点下的计算单元计算能力、功率及执行单元数，表4中用一个三元组（⊿计算能力，⊿功率，⊿物理计算核心数）描述每个计算单元的引入功效与成本。该三元组表示，如果要为计算分配该计算单元所能获得的计算能力、增加的功率及占用的物理计算单元数(共享线程单元的计算能力，按照综合经验值取0.3，不需要增加物理计算单元)。这里假定每个物理处理器上总是从Core0开始分配全资源线程单元。

调度策略1：加速比最大化需求

对于性能要求高或串行部分S比值较大的计算任务，由于受并行可扩展性的限制，应优先投入性能强的计算单元，从而可以使用较少数量的计算单元取得好的性能。

调度策略2：“性能/功率/物理计算单元数”最大化需求

当用户对性能要求不高，而将节约计算中心的运维成本作为首要追求目标时，“功耗=运行总时间*运行功率”成为评价作业运行的重要指标。由于计算结点的基础功率Pn通常远大于物理计算单元的功率Pc及线程单元功率Pt，通常在小规模计算中，同时投入的计算能力越多、越强，则计算的“性能/功率”比率越高，时间越短、总功耗也越少。虽然研究界与工业界多通过降低主频来降低功耗，但Intel的Turbo Boost就采用这种类似思想通过提升处理器主频来降低计算的功耗。

鉴于SMT的特点，本文在“性能/功率”比率的基础上引入SPN=“加速比/功率/物理计算单元数”来描述单位计算单元的计算能力与功耗效率，并用以指导计算单元的分配：

其中SN为加速比，P为功率，C为物理计算单元数，1000为常系数。在分配计算单元时，以SPN最大化作为调度目标，从而提高单位功率、单位成本的计算效率。

2.3 投入计算单元数量上限

一个应用投入计算单元的数量一般由用户在提交作业时确定。在一定范围内投入的计算单元越多则计算时间越短。由于功耗W=P*t，设初始计算方案功率为P0，任务执行时间为t0。而拟再投入一个计算单元，其功率为⊿P，缩短计算时间⊿t，功耗变化为⊿W。若仅从功耗角度考虑，是否在现有计算资源的基础上再投入新的计算资源，取决于：(P0+⊿P)*(t0-⊿t)＜P0*t0是否成立。

即：(t0-⊿t)/t0＜P0/(P0+⊿P)是否成立。设计算任务在单计算单元执行时间为1，则多核并行的执行时间为：，可推出。

如果通过实验取得了一个加速比的值，那么从（公式-1）也可推算出一个计算中的S：S=(N-SN)/SN(N-1)因此可依此对计算任务投入计算核心数的上限进行推算。

2.4 线程单元拓扑识别

在OS中可通过计算单元拓扑信息对线程单元间的关系进行识别，如Linux以Core id，Physical id等来提供处理器拓扑的相关信息：

1.拥有相同Physical id的所有逻辑处理器共享同一个物理Socket。每个Physical id代表一个唯一的物理封装。

2.每个Core id代表一个唯一处理器核。

3.如果有两个或两个以上的逻辑计算单元拥有相同Physical id，且Core id不同，则说明这是一个多核处理器。

4.如果有一个以上逻辑计算单元拥有相同的Core id和Physical id，则说明系统支持Hyper Threading，且这些逻辑计算单元在共享对应（Physical id，Core id）所指示物理计算核心的计算资源。

通过以上原则系统可以方便地探测系统处理器拓扑结构。如针对图1所示的Hyper Threading计算系统，Linux kernel 3.6.11为其提供了如表5所示的处理器信息。表5第一行处理器编号即为OS对线程单元的编号，通常OS在空闲状态下会按此编号顺序依次向计算任务提供计算资源。

表5 操作系统提供的处理器信息Table 5 The processor information in operating system

2.5 基于HT拓扑感知与线程亲和性的SMT调度机制

上述分配策略的具体实施可在应用层、运行时支持层或操作系统层上实现。

（1）在应用层实现仅影响该应用的计算单元分配策略，但此方案会增加应用程序员的编程负担；

（2）在运行时支持层实现则仅影响相关计算平台的使用[4,5]。

（3）在操作系统层实现，则计算单元分配策略会对全部应用产生影响。

由于线程的亲和性设定一般发生在计算的开始，因此以上三种方法在性能上差异不大，三种方法主要表现在对调度的影响范围不同。论文采用后两种方案来验证所提方法：在操作系统层，论文验证时通过动态修改Linux的进程亲和性系统调用[6]来修改操作系统的调度序列。在运行时支持层以斯坦福大学一研究小组基于共享存储mapreduce实现的Phoenix 2.0[2]及Phoenix++1.0[7]为案例进行验证。其中Phoenix 2.0在src/processor.c中设置线程亲和性，Phoenix++1.0在include/processor.h中设置亲和性，这二个模块均与用户逻辑无关。

3 测试与验证

分别在Dell C6100（双路Xeon L5520，24 G内存，Linux kernel 3.6.11）及HP DK388P（双路XeonE5-2667，80 G内存，Linux 2.6.32）上运行共享存储模式Phoenix的word counter案例并记录论文所提方案的执行情况。其中Dell结点运行Phoenix 2.0 word counter 1600M案例（原始程序未做优化），HP结点由于性能显著优于Dell C6100，因此运行Phoenix++1.0 word counter 51200 M案例。在Dell C6100服务器上的实验结果如表6所示。

实验数据显示两类调度策略依据调度的目标不同，在性能和效率方面表现出较大的差异，适合不同需求的用户根据需要进行选择，克服了传统OS单一调度策略的不足。尤其在“性能/功率/物理计算单元数”这项指标上，“调度策略2”充分利用了Hyper Threading的架构特点，使得每物理计算单元的效率得以充分发挥，在功耗方面取得不错的表现。

本文实验中，在功率与“调度策略1”相当的情况下，基于“调度策略2”中的每个物理核心（表6中偶数个线程单元）相对于“调度策略1”中一个物理核心的计算性能最高提高了33%左右（如表6中“调度策略2”的6个共享线程单元与“调度策略1”的3个全资源线程单元），平均提高21%，当全部计算单元投入后，计算性能/功率/效率相当。

表6 实验结果Table 6 The result from experiment

在功耗方面，当“调度策略2”使用4个共享线程单元功率时为130.13 W，与“调度策略1”的3个全资源线程单元功率相当，但执行速度要快于“调度策略1”；“调度策略2”使用10个线程单元执行时间为171.18 s，与“调度策略1”的7个线程单元时间相当，但功率却比“调度策略1”降低了3 W。同样“调度策略2”使用12个线程单元执行时间与“调度策略1”的9个线程单元时间相当，但功率却比“调度策略1”降低了7.82 W。表7以8个物理核心为单位对表6中的数据进行了对比。图2、3、4分别为HP DK388P服务器上时间、“性能/功率/物理计算单元数”、功率三项指标，在“调度策略1”与“调度策略2”两种策略下的比较图示。限于篇幅数据表格不再列出。

表7 实验结果分析Table 7 The analysis on experimental results

图2 HPDK388P服务器计算执行时间对比Fig.2 Comparison of execution time on server HPDK388P

图3 HPDK388P服务器计算性能/功率/物理计算单元对比Fig.3 Comparison of performance,power and physics computing elements on server HPDK388P

图4 HPDK388P服务器计算功率对比Fig.4 Comparison of powers on server HPDK388P

图2～4显示HP DK388P服务器在性能、功率及"加速比/功率/物理计算单元数"具有与DELL C6100基本相似的特性。

综上所述，论文提出的面向“性能/功率/物理计算单元数”的调度策略充分挖掘了Hyper Threading架构的特点，有效提高了计算系统的计算效率。

4 结束语

本文分析了现有计算操作系统对Hyper Threading技术支持的不足之处，提出了利用线程亲和性调整线程单元的分配顺序的调度策略，有效挖掘SMT技术的ILP与TLP；所提方法可以在应用层、在运行时支持与操作系统层灵活部署，用以满足不同用户计算任务的需求，从而有效地提高了系统计算资源利用率，并使得并行计算任务可以用更低的功耗获得更高的性能。

[1]林闯,田源,姚敏.绿色网络和绿色评价:节能机制、模型和评价[J].计算机学报,2011,34(4):593-612

[2]Richard M.Yoo,RomanoA,Kozyrakis C.Phoenix rebirth:Scalable Mapreduce on a large-scale shared-memory system[C].USA:IEEE International Symposium on Workload Characterization,2009:198-207

[3]冯国富,王明,李亮,等.共享存储MapReduce云计算性能测试方法[J].计算机工程,2012,38(6):50-52

[4]冯国富,董小社,胡冰,等.一种支持多种访存技术的CBEA片上多核MPI并行编程模型[J].计算机学报,2008(11):1965-1974

[5]董小社,冯国富,王旭昊,等.基于Cell多核处理器的层次化运行时支持技术[J].计算机研究与发展,2010(4):561-570

[6]冯国富,魏恒义,储鹰,等.支持多种Linux版本的动态内核性能测试技术[J].西安交通大学学报,2008(6):674-678

[7]Talbot J,Yoo RM,Kozyrakis C.Phoenix++:Modular MapReduce for Shared-Memory Systems[C].San Jose,CA:the Second International Workshop on Mapreduce and itsApplications,2011:9-16

Study on Hyper Threading Scheduling towards Power Efficiency of Computing

LIN He-lei,FENG Guo-fu*,JI Xu-ye,CHEN Ming
College of Information Technology,Key Laboratory of Fisheries Information Ministry of Agriculture/Shanghai Ocean University, Shanghai201306,China

As traditional computing focuses on performance and parallel scalability while ignoring the power consumption factor,based on Computing unit topology awareness of Hyper Threading,this paper analyzes the power consumption of Hyper threading server,and introduces a Hyper Threading Scheduling Strategy for energy efficiency.By setting thread's processor affinity to change the allocation order of computing units,the proposed method improves the system computing and energy efficiency,and overcomes the shortage of traditional OS whose schedule strategy is too monotonous for Hyper Threading.The experimental result shows that the proposed scheme can be deployed flexibly in three layers:application layer,runtime library layer and operating system kernel layer to affect computing applications in different scope.While improving energy efficiency,the utilization of computing resources are improved too.

Hyper threading;energy efficiency;computing unit scheduling;computing unit topology awareness

TP332

:A

:1000-2324(2017)01-0093-07

2016-11-03

:2016-12-18

上海市科技创新行动计划项目:小龙虾生态智能化设施养殖关键技术研究与应用(16391902902);江苏省国家长江珍稀鱼类工程技术研究中心培育点(BM2013012)

林何磊(1992-),男,硕士,主研方向:高性能计算机系统结构.E-mail:heleilin@hotmail.com

*通讯作者:Author for correspondence.E-mail:jt_f@163.com