Improving idle behavior in tickless systems

December 28, 2018, This article was contributed by Marta Rybczyńska

CPU处理器在实际执行代码的时候，很多时间其实是没有什么事情要做的，会在等待device和timer的中断。此时可以切换到idle mode，关掉内部大部分电路，停掉不再用的clock。进入这种低功耗状态，有助于减缓电池消耗。一般处理器都设计了多种idle mode，更深的idle mode，也就能消耗更少的功耗，不过也带来了一些缺点，就是进出更深的idle mode的时候耗费更多，例如会需要更多时间来进出idle mode，更深的idle mode也有可能会不得不把所有cache内容都清空抛弃掉。Linux kernel里面的cpuidle子系统就一直掌管这部分决策，选择进入哪个idle mode。最近Rafael Wysocki提议了一组新的governor来在tickless的系统上使用，预计会比当前的menu governor更加精确。

Cpuidle governors

人们很难预测下一个event什么时候发生，顶多能做的就是根据过去的历史记录来猜测一下。如果系统行为发生改变，这些猜测就很可能出错。有些设备会产生固定周期的中断，比较好预测。cpuidle governor通过测量这些周期间隔，从而预测下一次device中断会在什么时候。此外，系统调度模块以前一直有一个固定周期的时钟中断，曾经一直是按照100或者1000HZ的频率来上报中断给kernel。不过几年前开始tickless kernel大行其道，系统时钟中断通常会大大推后，系统也就有更长的时间没有中断，从而进入更深的idle state。

Linux目前已经提供了两种cpuidle governor，都在drivers/cpuidle/governors目录下，分别命名为"ladder"和"menu" governor。ladder governor会首先选择最浅层的idle mode，然后如果一段时间仍然没有事情要做，就再进入下一级的idle mode，逐步深入。在一些有固定时钟中断的系统(功耗问题不是特别重要的场景)上，这个方案很合适。不过缺点就是它的逐级深入特性会导致它花更长时间才能进入更深的idle mode。Menu governor就更加适合tickless系统了，它会直接选择最合适的idle mode，而不是从最浅层的开始逐级深入。用户可以读一下/sys/devices/system/cpu/cpuidle/current_governor_ro就能了解到自己在运行的是哪个governor了。

Menu gonvernor的缺点

Menu governor希望能直接进入最深的idle mode，当然这受限于一些客观条件。它首先猜测接下来系统会能idle多长时间(根据历史信息做这个猜测)，然后选择一个跟这个时长比较吻合的最深idle mode。menu governor还会采集各种其他信息来对照分析，包括系统的load，以及有多少个task正在等待I/O结束。这也很容易理解，毕竟马上I/O结束就有很多事情要做了，也就不要进入最深的idle mode了，否则进出相应的idle mode耗时过高，会拖慢响应速度。

Wysocki发现了一些问题，会导致menu governor不如设计的那么精准。首先，中断事件的历史信息不可靠，menu governor使用了所有的interrupts(包括timer)来预测下一个中断什么时候发生，可是它其实早已经知道下一次timer tick是什么时候，却不把两方面信息结合起来使用。因此，有时候governor明明一方面知道下一次timer会在很久以后，另一方面却还是根据中断的历史信息来 猜测 很快会有个timer中断，好像精神分裂双重人格一样。

其次，menu governor会依据在等待I/O的进程数量来做决策。这是为了在高负载系统上避免让idle mode的频繁进出来拖慢系统响应，不过Wysocki认为，具体有多少进程在等待I/O结束，并不应该影响idle mode的选择。

第三，他认为menu governor所采集用于做决策的信息，有一些太过久远的信息，其实不会影响眼下的idle选择，这些信息应该直接忽略掉，还可以节省资源。

Wysocki打算把menu governor重构一下来解决这些问题，不过因为menu governor在很多生产系统中都得到了应用，参数和行为在那些环境中也都仔细校准过，不太合适贸然改变menu governor的行为，因此他直接实现了一个新的governor，也方便用户测试对比这两个governor从而选择出来最适合用户所运行的workload的governor。

The timer events oriented governor

新的governor被命名为“timer events oriented” (TEO) governor。TEO governor采用的策略跟menu governor一样，都是预测接下来会有多长时间能待在idle状态，然后据此选择合适的idle mode。不过它跟menu governor考虑多方因素的策略是不同的。TEO的理念是，多数系统上CPU唤醒最频繁的唤醒源都是timer events，而不是设备中断(device interrupts)。Wysocki观察认为timer中断的数量要比其他中断高几个数量级。所以只要依据timer event就可以做好预测工作了。

他还观察到，只需要关注最近发生的几次唤醒时间点，就足够预测idle时长了。有些系统上其他唤醒源可能比timer影响更加大，那这种系统上，上述假设就不太靠谱了，不过Wysocki认为仍然只需要根据刚过去的几个idle-time周期情况就做出预测。其实，只有那些比下一次timer event还要短的唤醒周期需要考虑进来，毕竟那些更长间隔的事件，都可以被近似归结到相邻的timer事件上去。

总之，TEO的设计核心就是认为下一次唤醒就是我们已知的下一个timer event到期时间点。它会根据这个预测出的时长，来选择一个合适的最深idle mode，紧接着它会根据过去几次唤醒的规律来再检查一下自己这次的选择是否合理。如果选定的idle mode对上面两个条件都满足，就作为最终决策了，否则的话，TEO就会用浅一层的idle mode来再试。这个算法对于那些系统workload不断改变的场景也适用，它会检查一下最近几次的idle时长是不是比起当前选定的下一个idle mode来说太短了，是的话，TEO就会用过去几次的idle时长来预测下一次idle，也就是会选择更浅层的idle mode。

Current state and benchmark results

Patch在2018年底已经达到了第10个版本，很多内核开发者都开始测试这个新governor了。Giovanni Gherdovich贴出了一组benchmark的结果，看起来有一些test case里两个governor表现差不多，而有一些case里面TEO governor的performance略高一点。详细的benchmark结果都贴在patch review邮件里面了(https://beta.suse.com/private/ggherdovich/teo-eval/teo-v6-eval.html)，可以看出对带宽和I/O latency都有影响。Doug Smythies也贴出一组测试结果，显示TEO在功耗水平不变的情况下performance有提高。

TEO governor还在早期阶段(译者注：2019年5月份的Linux 5.1里面已经合入，此文原作者写于2018年底)，代码改动其实很小，只是要花很多工作来测试各种系统和体系结构上的benchmark，特别是对功耗的影响。Wysocki也在做其他一些功耗和idle mode的工作，他也在Kernel Recipes会议上做过介绍，初步结果看起来很不错。最终，他的目标“选择一个更合适的idle mode”，看起来达成了。