LWN: OSPM会议讨论如何重写CFS负载均衡算法

点击上方蓝色字关注我们~

Reworking CFS load balancing

July 11, 2019

---

OSPM

译者注：OSPM是刚刚结束的第三届Operating-System-Directed Power-Management summit会议。近期LWN发布了一部分会议议题的讨论。本文正是其中一篇。

Linux内核scheduler（调度器）支持多种调度类型，包括Completely Fair Scheduler (CFS，公平调度)，realtime (RT，实时调度)，以及新近加入的deadline scheduler（限期调度）。CFS是缺省配置，绝大多数情况都是用CFS，目的是把CPU的工作时间针对各个task的优先级来进行分配。2007年引入后，它经过了多次重大改动，其中一次就是支持了per-entity load tracking (PELT，跟踪每个计算单位的工作负载），这样就能给出每个task占用各个CPU的计算力细节。

scheduler的负载均衡算法有责任让各个task运行在最合适的CPU上，从而减少系统的整体计算消耗。它需要定期监测系统状况，针对各个task决定是否应该迁移到其他CPU，从而保证计算能力分布均衡，并且充分利用计算资源。不过scheduler还没改过来，尚未完全利用这些新的指标，仍然仅仅用了load作为迁移task的指标，哪怕在某些情况下系统并不是load不平衡，而是例如多个CPU的计算能力有差异导致的。

为了能判断系统有多么不平衡，负载均衡算法使用了一些虚拟的甚至某些意义上来说是无用的一些指标，例如每个task的平均load，通常在load不合适代表系统的平衡性的时候会用这个指标，不过按理来说应该是够用了。其他还有一些场景，甚至有可能让统计结果产生一些偏见倾向，在某些CPU不太忙的时候看起来过于繁忙，所以导致task在几个计算组之间发生迁移。这些其实还不够，仍有一些场景里面可以看到task在各个CPU上的分配有不太合理的地方。

举经典的非对称的两组CPU场景下的例子来说吧。两组CPU不完全一致，有可能是因为CPU不同的微架构，或者被其他调度类别（例如实时进程）偷走的时间多少不一样，或者因为温度过热后的温控措施临时降低了某个CPU的最大计算能力。我们可以具体用big.LITTLE平台来介绍这个问题，假设它拥有4个小核和4个大核。如果系统上仅有8个进程运行，scheduler应该会把每个进程分配到一个单独的CPU上去运行，但是实测结果可能是它在大核所在的cluster上放了5个task。

如果仅仅比较load的话，这个决策很合理，因为大核的cluster还有很多计算资源空闲，每个task的平均load也很平衡。不过这个决策导致了一个小核CPU空闲的同时有两个进程在争抢同一个大核CPU。这就是一个典型的例子证明仅仅比较load是不够的，应该还要根据当前空闲的CPU数量来做决策。演讲现场还介绍了一些其他应用场景，这些场景都是缺少一些信息导致没法做出最优决策。

所有这些例子都证明，应该需要清理一下负载均衡的算法了，使用一些新的指标，移除那些随着时间不断加入的一些不再使用的判断条件，去掉一些古老时代加入的、不再有意义的假设条件。

如果scheduler能够拿到合适的那些指标，CPU就可以被更准确的分组，然后能大大改善不平衡的问题。所以，第一步需要在采集下来数据之后把CPU分成几组，归入下面这些类别：

• 仍有空闲计算能力、可以接受其他task加入自己的CPU group。

• 全忙、所有CPU都完全被占用满了的CPU group。

• 已经过载、各个task需要互相抢占执行实现的CPU group

除了这些常见状态之外，还需要明确下面这些特殊情况：

• 需要移动至少一个task出去，来解除当前task分配场景下特有的不平衡问题。

• 最少移走一部分的占用率。

• 移走一个特定的task

当明确了当前的状况之后，负载均衡算法就能很轻松的选择出可以把多出来的task安排到哪个group去，或者哪些task需要被迁移走：

• 是不是因为要在多个tasks之间做公平的时间分配导致的load迁移，从而导致CPU过载？

• 是不是需要把一些task调到其他group里的空闲CPU上？

• 是不是只是某个特定task不能在当前运行的CPU上继续执行了？

这些就是负载平衡算法需要解决的问题了。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～