提升无tick系统的空闲行为

    大多数processors都会有大量的空闲时间，等待设备和时钟中断。 在这些情况下，他们可以切换到空闲状态，切断部分内部电路，特别是关闭某些时钟。这些都会降低耗电量，防止设备电池耗光。一般都会有多种可用的空闲模式可用，越深入的空闲模式下，processors就会越省电。需要平衡的是，更深入的模式切换会需要更多的时间，并且一些cache的内容也会丢失。在linux内核，cpu空闲子系统需要预测最合适的空闲模式。最近，Rafael Wysocki 提出一种启用tickless操作的新cpuidle管家，比已有cpuidle管家更精准。

cpuidle管家
     预测下一事件的发生时间并不总是一件容易的事；现在的预测方法是基于系统最近的历史实现。而这种预测方法在系统行为改变的时候会产生错误的结果。依赖于正在运行的程序，设备在大概可预测的间隔触发中断；一个cpuidle管家可以测算这些间隔，来预测下一此中断发生时间。另一相关要素是系统的常规调度tick；直到近些年来，内核一般都有每秒100-1000下的时钟中断作为tick。这一情况在无tick内核出现了变化；无中断的周期可以更长(tick关闭)，并且processor可以进入更深的idle状态。
     
     当前linux提供两种cpuidle管家(drivers/cpuidle/governors)：ladder和menu。这两个cpuidle管家的基础设计思想和接口要追溯到2010年。ladder管家最先选择最浅的空闲模式，然后在等待时间足够长后就会开始进入更深的idle状态。在能耗不是非常重要考虑因素，在带有常规时钟中断的系统中，这是不错的选择。问题在于ladder管家需要很长的时间进入深度idle状态。而到目前为止，menu管家在无tick系统中则是更优的选择。menu管家会尝试进入最合适的idle状态，而不必是最浅的。用户可以通过/sys/devices/system/cpu/cpuidle/current_governor_ro来查看其使用的idle管家。
     
对menu管家的批判
    menu管家总是试图找到其可以进入的最深的idle状态。它会基于历史预测下一次idle周期的时长，联系得到的最近的idle时长和可以选择的idle状态，选择最可能与下次idle周期结束相吻合的idle状态。menu管家对预期的唤醒时间适用不同的校正因子，如系统加载、等待I/O的task数量。这些校正因子按其设计目标限制进入idle状态效能影响。
    根据Wysocki的陈述，他发现menu管家存在诸多问题，使menu管家不能如预期般精确。第一个发现与中断历史pattern的创建相关；menu管家使用所有中断(包括定时器中断)，来预测下一个中断将要发生的时间。换句话说，它已经有下次定时器中断发生的时间信息了，但却不将两者相关联。这就导致可能发生管家预测了唤醒时间；而这一时间是管家应该已知就要发生的定时器事件。
    第二个发现是关于menu管家使用等待I/O的task数量作为校正因子，这是为了降低idle状态对高负载系统的影响。在高负载系统下进入更深的idle状态可能会对性能有更明显的影响，于是这一校正因子会选择更浅的idle模式。Wysocki说，等待I/O的task的数量对可用的idle模式没有影响，不应该加入考虑。最终，他认为menu管家采用的模式检测有时会考虑很大但不是与实践相关的值。而这些值也是应该被忽略的，且计算资源也会更省。
    Wysocki之前想重做menu管家来修正这些问题，但是这可能会使根据目前的menu管家调教过的负载状态性能变差。因此，他选择重新实现一种新的管家，允许用户用其实际工作负载来测试两种管家，并作出选择。
面向定时器事件的管家
    新的管家被称作是面向定时器的管家(TEO)。使用与menu管家相同的策略，即预测下一idle持续时间并选择最合适idle模式，但是考虑的校正因子却是不同的。TEO的理念是：在大量系统中，最频繁唤醒CPU的是定时器事件而不是设备中断。Wysocki提到，定时器事件发生的频繁程度可能比其他中断多2或更高个数量级。因此到下一次定时器事件的时间提供了强预测线索。
    另一个发现是使用最近的过去来精确估计idle周期就足够了。在最频繁唤醒CPU的源不是定时器的系统中，这一发现并不直接适用。不过Wysocki仍认为，分析可以基于少量idle时间周期。特别的，仅有比下一定时器事件间隔短的需要被考虑。这是因为更长的持续时间一般属于最近的定时器的模式。
    TEO是的围绕着下一次唤醒很可能是定时器事件到达的思想涉及；选择此间隔最深的idle模式。然后验证这一间隔是否与不考虑定时器事件的情况吻合(用在最近的过去观察idle事件的模式)。如果选择的idle模式在考虑或不考虑定时器的情况下一致，即选择此模式，否则TEO尝试稍浅的idle模式。
    TEO的算法还考虑了模式变换了的情况；其有一个特别的检查来确定最近用于选择idle模式的idle doration是否太短。如果是的话，TEO仅使用这些值来计算新的预期的idle duration。然后重新选择idle模式，并且会是更浅的idle模式。
    
当前状态和基准测试结果
    当前这一补丁已经到了第九版。各路开发者已经开始评估代码。Giovanni Gherdovich分享了对各个版本patch的基准测试结果；他们展示了一系列的用例：cpuidle管家的选择并不重要的和TEO能够提供少量性能提升的(较menu管家)。这些用例按照不同版本的patch分别测试过，展示了各版本patch对带宽和i/o延迟的影响。Doug Smythies提供的基准测试结果，表示性能提升和电量消耗与Giovanni的结果一致。
    TEO管家还处在早期阶段。尽管其代码是精巧的，但是仍需要更多工作和在不同的系统/架构中的基准测试，特别是考虑对电量消耗方面的影响。另外，Wysocki同样致力于其他电量消耗和idle状态方面的工作，已经在Kernel Recipes上呈现。初期结果是令人振奋的。开发的目标：对下一idle状态更好的预测似乎已经达到。