背景：性能之战

• 相关知识简介

• hackbench 工作模式简介

• hackbench 性能受损之源

• 双参数优化

• 思考与拓展

相关知识简介

CFS调度器

CFS 调度器参数

• 最小粒度时间：kernel.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 越小，进程被唤醒后的响应时间就越快（等待运行时间越短） 。

hackbench 工作模式简介

hackbench 工作模式分为  process mode 和  thread mod e，主要区别就是以创建 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 两个参数，导致了性能的显著区别。具体如下：

• 开关/参数和性能	sched_min_granularity_ns	sched_wakeup_granularity_ns	性能
  关 tuned	2.25ms	3ms	差
  开 tuned	10ms	15ms	好

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

双参数优化

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

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

固定 sched_wakeup_granularity_ns

图 4: 固定 w，调整m

• 对于区域A而言，抢占过于频繁，而大部分抢占都是无意义的，因为对端无数据可写/无缓冲区可用，导致大量冗余“主动上下文切换“。此时较大的 w 能让 sender/receiver 有更多的时间来写入数据/消耗数据来减少对端进程无意义的“主动上下文切换“。

• 对于区域B而言，随着 m 的增加渐渐满足 sender/receiver 执行任务的时间需求能够在缓冲区写入/读出足够的数据，因此需要较小的 w 来增加唤醒进程的抢占几率，让对端进程能够更快的响应处理数据，减少下一轮调度时的“主动上下文切换”。

• 对于区域C而言，m已经足够大，已经几乎不会有“被动上下文切换”发生，进程会在执行完任务之后进行“主动上下文切换”等待对端进程进行处理，此时 m 对性能的影响就很小了。

固定 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 则会造成性能问题（原因同上条）。

性能趋势总览

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

图 6：总览图

最优双参数（对于 hackbench ）

2、在pipe/socket 双向通信的场景中，对端的响应时间会对影响进程的下一次处理，为了让对端进程能够及时响应可以选择一个中等大小的 w（例如：6～8ms）来获取较高的性能。

思考与扩展

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

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

关于龙蜥社区