“不服跑个分？” 是噱头还是实力？

一、背景：性能之战

“不服跑个分”已经沦为手机行业的调侃用语，但是实话实说，在操作系统领域“跑分”确实是最重要的评价方式之一。比如 Linux 内核社区常常以跑分软件得分，来评价一个优化补丁的价值。甚至还有 phoronix 这样专注于 Linux 跑分的媒体。而且今天我还想说一点，让软件跑分高，这是实力的体现，是建立在对内核的深刻理解基础上的。本文的故事就源于一次日常的性能优化分析。我们在评估自动化性能调优软件 tuned 的时候，发现它在服务器场景，对 Linux 内核调度器相关的参数做了一些微小的修改，但是这些修改却很大程度改善了 hackbench 这款跑分软件的性能。是不是很有意思？让我们一起来一探究竟。

本文将从几个方面展开，并重点介绍黑体字部分：

• 相关知识简介
  
• hackbench 工作模式简介
  
• hackbench 性能受损之源
  
• 双参数优化
  
• 思考与拓展
  

二、相关知识简介

2.1 CFS调度器

Linux 中大部分（可以粗略认为是实时任务之外的所有）线程/进程，都由一个叫 CFS（完全公平调度器）的调度器进行调度，它是 Linux 最核心的组件之一。（在Linux中，线程和进程只有细微差别，下文统一用进程表述）

CFS 的核心是红黑树，用于管理系统中进程的运行时间，作为选择下一个将要运行的进程的依据。此外，它还支持优先级、组调度（基于我们熟知的 cgroup 实现）、限流等功能，满足各种高级需求。CFS 的详细介绍。

2.2 hackbench

hackbench 是一个针对 Linux 内核调度器的压力测试工具，它的主要工作是创建指定数量的调度实体对（线程/进程），并让它们通过 sockets/pipe 进行数据传输，最后统计整个运行过程的时间开销。

2.3 CFS 调度器参数

本文重点关注以下两个参数，这两个参数也是影响 hackbench 跑分性能的重要因素。系统管理员可以使用 sysctl 命令来进行设置。

• 最小粒度时间：kernel.sched_min_granularity_ns    
  
  

通过修改 kernel.sched_min_granularity_ns，可以影响 CFS 调度周期（sched period）的时间长短。例如：设置kernel.sched_min_granularity_ns = m，当系统中存在大量可运行进程时，m 越大，CFS 调度周期就越长。

如图 1 所示，每个进程都能够在 CPU 上运行且时间各有长短，sched_min_granularity_ns 保证了每个进程的最小运行时间（优先级相同的情况下），sched_min_granularity_ns 越大每个进程单次可运行的时间就越长。

图 1：sched_min_granularity_ns 示意图

• 唤醒抢占粒度：kernel.sched_wakeup_granularity_ns

kernel.sched_wakeup_granularity_ns 保证了重新唤醒的进程不会频繁抢占正在运行的进程，kernel.sched_wakeup_granularity_ns 越大，唤醒进程进行抢占的频率就越小。

如图 2 所示，有 process-{1,2,3} 三个进程被唤醒，因为 process-3 的运行时间大于 curr（正在 CPU 上运行的进程）无法抢占运行，而 process-2 运行时间小于 curr 但其差值小于 sched_wakeup_granularity_ns 也无法抢占运行，只有 process-1 能够抢占 curr 运行，因此 sched_wakeup_granularity_ns 越小，进程被唤醒后的响应时间就越快（等待运行时间越短）。

图 2：sched_wakeup_granularity_ns 示意图

三、hackbench 工作模式简介

hackbench 工作模式分为 process mode 和 thread mode，主要区别就是以创建 process 还是 thread 为基础来进行测试，下面以 thread 来进行介绍。

1. hackbench 会创建若干线程（偶数），均分为两类线程：sender 和 receiver
   
2. 并将其划分为 n 个 group，每个 group 包含 m  对 sender 和 receiver。
   
3. 每个 sender 的任务就是给其所在 group 的所有 receiver 轮流发送 loop 次大小为 datasize 的数据包
   
4. receiver 则只负责接收数据包即可。
   
5. 同一个 group 中的sender 和 receiver 有两种方式进行通信：pipe 和 local socket（一次测试中只能都是 pipe 或者 socket），不同 group 之间的线程没有交互关系。

通过上面 hackbench 模型分析，可以得知同一个 group 中的 thread/process 主要是 I/O 密集型，不同 group 之间的 thread/process 主要是 CPU 密集型。

图 3: hackbench 工作模式

主动上下文切换：

• 对于 receiver，当 buffer 中没有数据时，receiver 会被阻塞并主动让出 CPU 进入睡眠。
  
• 对于 sender，如果 buffer 中没有足够空间写入数据时， sender 也会被阻塞且主动让出 CPU。

因此，系统中"主动上下文切换"是很多的，但同时也存在“被动上下文切换”。后者会受到接下来我们将要介绍的参数影响。

四、hackbench性能影响之源

在hackbench-socket 测试中，tuned修改了 CFS 的 sched_min_granularity_ns 和 sched_wakeup_granularity_ns 两个参数，导致了性能的显著区别。具体如下：

接下来我们调整这两个调度参数来进行进一步的深入分析。

五、双参数优化

注：为了简介表达下面会以 m 表示 kernel.sched_min_granularity_ns，w 表示 kernel.sched_wakeup_granularity_ns

为了探索双参数对于调度器的影响，我们选择每次固定一个参数，研究另一个参数变化对于性能的影响，并使用系统知识来解释这种现象背后的原理。

5.1 固定 sched_wakeup_granularity_ns

图 4: 固定 w，调整m

在上图中我们固定了参数 w 并根据参数 m 变化趋势其划分为三个部分：区域A（1ms～4ms），区域B（4ms～17ms），区域C（17ms～30ms）。在区域A中四条曲线均呈现一个极速下降的趋势，而在区域B中四条曲线都处于一种震荡状态，波动较大，最后在区域C中四条曲线都趋于稳定。

在第二节相关知识中可以知道 m 影响着进程的运行时间，同时也意味着它影响着进程的“被动上下文切换”。

• 对于区域A而言，抢占过于频繁，而大部分抢占都是无意义的，因为对端无数据可写/无缓冲区可用，导致大量冗余的“主动上下文切换“。此时较大的 w 能让 sender/receiver 有更多的时间来写入数据/消耗数据来减少对端进程无意义的“主动上下文切换“。
  
• 对于区域B而言，随着 m 的增加渐渐满足 sender/receiver 执行任务的时间需求能够在缓冲区写入/读出足够的数据，因此需要较小的 w 来增加唤醒进程的抢占几率，让对端进程能够更快的响应处理数据，减少下一轮调度时的“主动上下文切换”。
  
• 对于区域C而言，m已经足够大，已经几乎不会有“被动上下文切换”发生，进程会在执行完任务之后进行“主动上下文切换”等待对端进程进行处理，此时 m 对性能的影响就很小了。
  

5.2 固定 sched_min_granularity_ns

图 5: 固定 m，调整w

在上图中我们固定了参数 m，同样划分了三个区域：

• 在区域A中，同样存在图 4 中的现象，较大 m 受 w 的影响较小，而较小的 m 随着 w 的增大性能会越来越好。
  
• 在区域B中，中等大小的 m（8ms/12ms）进程还是存在较多“被动上下文切换”，并且其中的进程已经处理了相当一部分数据期望对端进程能够尽快的响应处理，因此较大 w 会严重影响中等大小 m 的性能。
  
• 在区域C中图5和图4表现一致都是趋于稳定，因为 w 过大时几乎不会发生唤醒抢占，因此这时单纯 w 值的变化对性能的影响并不大，但是过大的 w 对于中等大小的 m 则会造成性能问题（原因同上条）。

5.3 性能趋势总览

下面是一个实验数据的热力总览图，来直观展示 m 和 w 之间的制约关系，以供需要的同学参考分析。三个区域和图 4、图 5 的区域会略有不同。

图 6：总览图

5.4 最优双参数（对于 hackbench ）

1. 从上面两节的分析可知对于 hackbench 这样带有“主动上下文切换”的场景可以选择较大的 m（例如：15~20ms）。
2. 在pipe/socket 双向通信的场景中，对端的响应时间会对影响进程的下一次处理，为了让对端进程能够及时响应可以选择一个中等大小的 w（例如：6～8ms）来获取较高的性能。

六、思考与扩展

1. 在桌面场景中，应用更偏向于交互型，应用的服务质量也更多的体现在应用对于用户操作的响应时间，因此可以选择较小的 sched_wakeup_granularity_ns 来提高应用的交互性。
   
2. 在服务器场景中，应用更偏向于计算处理，应用需要更多的运行时间来进行密集计算，因此可以选择较大的 sched_min_granularity_ns，但是为了防止单个进程独占 CPU 过久同时也为了能够及时处理客户端请求响应，应该选择一个中等大小的 sched_wakeup_granularity_ns。
   
3. 在 Linux 原生内核中 m 和 w 的默认参数被设置为适配桌面场景，Anolis OS的用户，需要根据自己部署的应用的场景，属于桌面型还是服务器型，来选择内核参数，或者使用tuned的推荐配置。而 hackbench 作为一个介于桌面和服务器间的应用，也可以作为配置的参考。

参考资料

• phoronix：
  https://www.phoronix.com/
  
• 自动化性能调优软件tuned：
  https://developer.aliyun.com/article/86750
  
• CFS 的详细介绍：
   http://www.wowotech.net/process_management/451.html
  
• 在 Linux 原生内核中 m 和 w 的默认参数被设置为适配桌面场景：
  https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt

关于作者

何惟禹（百奎），阿里云操作系统团队实习生，北京邮电大学在读研究生。

吴一昊（丁缓），17 年加入阿里云操作系统团队，主要经历有资源隔离、热升级、调度器SLI等。

—— 完 ——

加入龙蜥社群

加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；加入钉钉群：可扫码或搜钉钉群号（33311793）。欢迎开发者/用户加入龙蜥OpenAnolis社区交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！

               

龙蜥社区_小龙                                            钉钉群二维码

关于龙蜥社区

龙蜥社区是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于2020年9月，旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。

短期目标是开发Anolis OS作为CentOS替代版，重新构建一个兼容国际Linux主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。

加入我们，一起打造面向未来的开源操作系统！

Https：//openanolis.cn