上一节我们讨论了linux 2.6和4.18两个版本内核对CPU效能的管理方式，但要弄清为何在节能模式下两者性能相差甚远的问题，还需要我们通过复现4.18内核的场景来做进一步分析。

复现4.18内核的场景

使用节能模式下的执行情况和睡眠状态：

使用性能模式下的执行情况和睡眠状态：

通过上面的输出，我们可以看到：

• 在性能模式下，大部分CPU进入到了C1状态，这比较符合预期；

• 在节能模式下没有任何CPU进入睡眠状态；从 i7z 的输出中明显可以看到，所有CPU都在C0状态，这明显不正常。

这里就出现了两个问题，一是为什么4.18内核在开启节能状态后CPU一直处于C0状态？二是为什么两种模式下执行命令的CPU频率差不多，但所用时间相差近一倍呢？

第一个问题的答案和系统的延迟请求设置有关，罪魁祸首是tuned服务，它使用了 latency-performance 模式，在这个模式中，tuned服务会将系统的请求延迟设置为 1us。然后我们再看一下各C-states状态等级的唤醒延迟：

我们可以看到C1状态的的唤醒延迟为2us，所以系统只能选用POLL这个唤醒延迟为0us的poll_idle状态，这种方式会用不断运行nop指令让CPU一直处于空转的运行状态，所以CPU始终处于运行状态。

那处于poll_idle这种0延迟的状态不好吗？就目前表现来看，确实是不太好，而且就是因为它，让问题二中CPU运行频率相差无几的情况下，性能下降了近一倍。

细说起来就要好好看一个大家都耳熟能详的名字：超线程（HT, Hyper-Threading）。

我们都知道现代CPU基本都支持超线程技术，它能让CPU的一个物理核变为两个逻辑核，从而提高CPU的效能。这项技术的工作原理是什么呢？

简单来讲就是多引入一个生产者，来减少消费者的空闲时间，从而提高CPU的整体利用率，而达到提高CPU效能的目的。

从上图我们可以看出，超线程的两个逻辑核心都有自己的寄存器，但共用一个ALU(算术逻辑单元)这个指令执行组件。

我们知道存在共享的地方，肯定会有竞争，所以我们可以设想，当两个逻辑核心都处理于100%的运行状态的时候，将导致每个逻辑核心的运行时间加倍，但由于是并行执行，所以整体运行时长应该和顺序执行相差无几。

但如果其中有一个逻辑核心进入了上面我们说的poll_idle空转状态呢？很显然，这就像在庄稼地里种了一半杂草——对于开了超线程的CPU，我们应该避免让其进入poll_idle状态，它会直接让系统性能下降50%。

那为什么系统中要开启tuned服务让其进入poll_idle状态呢？

据说是因为有一个业务在开启这个服务后，性能提升了很多，所以后面就在装机模板中默认开启了此服务，但很不幸在我们这个场景中，反而起到了负作用。下面我们来简单看下tuned服务在latency-performance模式下的一些设置。

tuned服务

目前的装机模板中，会默认在CentOS 7上安装tuned服务，并将其设置为latency-performance模式。在这个模式中主要有以下几项配置：

其中关于CPU：

• force_latency：系统请求延迟，对应上面提到的 /sys/kernel/debug/pm_qos/cpu_dma_latency 文件

• governor：P-states策略，对应上面提到的 /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor 文件，可以通过cpupower idle-set命令来设置。

• energy_perf_bias：使用 x86_energy_perf_policy 命令来设置 cpu 的效能策略，它不是直接设置P-states或C-states，而是调整CPU的节能倾向，比如性能模式下会在turbo超频时用更高的电压，更积极的进入低状态等级的C-state。

• min_perf_pct：P-states的最低频率限制，对应 /sys/devices/system/cpu/intel_pstate/min_perf_pct 文件，可以通过cpupower frequency-set命令来设置。

关于sysctrl我们可以看到对调度和内存的使用做了优化，在此我们不做展开，但此处我们要注意一点：tuned服务可能会覆盖我们对sysctrl的一些原有优化配置。

总体建议配置

在讨论总体建议配置之前，我们先分析一下CPU对系统运行时间的影响。从前面的讨论我们可以归纳出三点：唤醒延迟、变频延迟和运行频率。

这里为了简单，我们只看 Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz 型号下 唤醒延迟和运行频率 的一组理论上比较粗略的数据：

我们可以看出唤醒延迟和运行频率之间，就像鱼与熊掌一样，不可兼得。同理变频延迟也一样，因为最高运行频率都是需要其他CPU节约出电力来达到的。

同时程序的实际运行时间长也可以粗略的理解为：CPU唤醒延迟+CPU处理时长，而后者受CPU的运行频率的影响。

所以在总体建议配置上，我们简单分两类场景来讨论：

场景1：低响应延迟、高并发和稳定性

低响应延迟的业务：一般实际处理时长很短，所以CPU频率所带来收益很低，降低唤醒延迟将提高性能；

高并发的业务：由于所有CPU都很忙，所能节约出来的电力有限，CPU的运行频率与正常工作频率相差不大，反而由于唤醒延迟降低了性能；

需要稳定性的业务：由于变频、超频和唤醒延迟功能的存在，将导致业务可能时快时慢，表现出非常不稳定的现象。

对于以上三种场景，建议的BIOS配置为使用最大性能模式，具体为：关闭P-states、C-states和 MONITOR/MWAIT指令 等相关的功能。

场景2：大运算量、低并发且对响应延迟和稳定性要求不高

大运算量的业务：由于处理时间长，CPU频率的提高能带明显的性能提升，唤醒延迟的影响可以忽略不计，如果对稳定性要求不高且并发很低，非常建议开启节能模式，当然更推荐使用核心数较少，但主频更高的CPU。

一般在非场景1要求的情况下，建议的BIOS配置为使用节能模式，具体为：开启P-states、C-states和 MONITOR/MWAIT指令 ，且同时开启 Turbo Boost功能。

在使用节能模式的情况下，还要留意tuned服务所带来的影响，如果要使用latency-performance模式，那代表业务属于场景1的类型，建议直接关闭BIOS里的节能配置，否则可能会让整体性能大幅度下降。如果有特殊需要，则可能需要修改对应模式下的具体配置。

结语

在整个问题分析的过程中，最让人头痛的问题是：目前我们使用4.18这个内核版本的配套组件及其不完善，没有可用的debuginfo包，这将导致一些问题（比如内核crash）可能没有办法分析，所以首先是想建议部分想尝试新内核的同学，最好再忍耐忍耐。

其次，我们在开发或运维过程中，会总结出一些“最佳实践”，这些“最佳实践”可能会对80%的场景有效，但总有一些场景不适合用，或者因其本身的普适性造成在某些场景下有较大的调优空间。就像上面提到的tuned服务，我们使用的是latency-performance模式，其实还有network-latency、throughput-performance等模式，分别对网络和硬盘性能有专门的优化，所以针对特定的场景，可能还有很多可以调优的潜力待我们去挖掘。

最后，希望本文能对需要做调优的同学有所帮助，也希望在提高效率、降低成本的大环境下，能与更多的同学一起交流学习调优方面的技术和心得。

（全文完）

欢迎大家关注“58架构师”微信公众号，定期分享云计算、AI、区块链、大数据、搜索、推荐、存储、中间件、移动、前端、运维等方面的前沿技术和实践经验。