Linux 2.6 内核中的最新电源管理技术综述 03 Linux, 电源, 技术, 读者, 开发

samwalton

Ondemand governor 的由来及其实现刚刚我们在 cpufreq-info 的输出中可以看到 cpufreq 子系统一共提供了五种 governors 供用户选择使用，它们分别是 userspace，conservative，ondemand，powersave 和performance。在最新的内核中如果用户不进行额外设置的话，ondemand 会被作为默认的 governor 使用。为了理解是什么原因造成了这种现状，我们在这里带领读者回顾一下 cpufreq 子系统中的governor在内核中的开发历史。
Cpufreq 作为一个子系统最早被加入到 Linux 内核中时只配备了三个governors ，分别是performance、powersave 和userspace。当用户选择使用 performance governor 时，CPU会固定工作在其支持的最高运行频率上；当用户选择使用powersave governor 时，CPU会固定工作在其支持的最低运行频率上。因此这两种 governors 都属于静态 governor ，即在使用它们时 CPU 的运行频率不会根据系统运行时负载的变化动态作出调整。这两种 governors 对应的是两种极端的应用场景，使用 performance governor 体现的是对系统高性能的最大追求，而使用 powersave governor 则是对系统低功耗的最大追求。虽然这两种应用需求确实存在，但大多数用户在大部分时间里需要的是更加灵活的变频策略。最早的 cpufreq 子系统通过 userspace governor 为用户提供了这种灵活性。正如它的名字一样，使用 userspace governor 时，系统将变频策略的决策权交给了用户态应用程序，并提供了相应的接口供用户态应用程序调节 CPU 运行频率使用。通过使用 cpufrequtils 工具包中的 cpufreq-set 将 userspace 设置为 cpufreq 子系统所使用的 governor 后，我们可以看到与之前相比在 /sys/devices/system/cpu/cpuX/cpufreq/ 目录下多出了一个名为 scaling_setspeed 的文件，这正是 userspace governor 所提供的特殊用户接口。用户可以通过向该文件写入任何一个 scaling_available_frequencies 中所支持的运行频率，从而将 CPU 设置在该频率下运行。
# cpufreq-set -g userspace
# cat cpuinfo_cur_freq
1000000
# cat scaling_available_frequencies
1667000 1333000 1000000
# echo 1333000 >scaling_setspeed
# cat cpuinfo_cur_freq
1333000

刚刚提到在使用 userspace governor 时，系统将变频策略的决策权交给了用户态应用程序。该用户态应用程序一般是一个 daemon 程序，每隔一定的时间间隔收集一次系统信息并根据系统的负载情况使用 userspace governor 提供的 scaling_setspeed 接口动态调整 CPU 的运行频率。作为这个daemon 程序，当时在几个主要的 Linux 发行版中使用的一般是 powersaved 或者 cpuspeed。这两个 daemon 程序一般每隔几秒钟统计一次 CPU 在这个采样周期内的负载情况，并根据统计结果调整 CPU 的运行频率。这种 userspace governor 加用户态 daemon 程序的变频方法虽然为用户提供了一定的灵活性，但通过开源社区的广泛使用所得到的意见反馈逐渐暴露了这种方法的两个严重缺陷。第一个是性能方面的问题。例如powersaved 每隔五秒钟进行一次系统负载情况的采样分析的话，我们可以分析一下在下面给出的应用场景中的用户体验。假设 powersaved 的采样分析刚刚结束，而且由于在刚刚结束的采样周期内系统负载很低，CPU 被设置在最低频率上运行。这时用户如果打开 Firefox? 等对 CPU 运算能力要求相当高的程序的话，powersaved 要在下一个采样点——大约五秒钟之后才有机会观察到这种提高 CPU 运行频率的需求。也就是说，在Firefox 启动之初的五秒钟内 CPU 的计算能力并没有被充分发挥出来，这无疑会使用户体验大打折扣。第二个是系统负载情况的采样分析的准确性问题。将监控系统负载情况并对未来 CPU 的性能需求做出判断的任务交给一个用户态程序完成实际上并不合理，一方面是由于一个用户态程序很难完整的收集到所有需要的信息，因为这些信息大部分都保存在内核空间；另一方面一个用户态程序如果想要收集这些系统信息，必然需要进行用户态与内核态之间的数据交互，而频繁的用户态与内核态之间的数据交互又会给系统性能带来负面影响。
那么这两个问题有没有解决的方法呢？应该讲社区中的开发人员就第二个问题比较容易达成一致，既然在用户态对系统的负载情况进行采集和分析存在这样那样的问题，那么更加合理的做法就是应该将这部分工作交由内核负责。但是第一个问题呢？第一个问题最直观的解决方案就是降低对系统负载进行采样分析的时间间隔，这样 powersaved 就能尽早的对系统负载的变化做出及时的响应。然而这种简单的降低采样分析的时间间隔的方案同样存在着两方面的问题，一方面这意味着更加频繁的用户态与内核态之间的数据交互，因此必然也就意味着对系统性能带来更大的负面影响；另一方面的主要原因在于当时各个 CPU 生产厂家的变频技术在硬件上仍不完善，具体体现就是在对 CPU 进行变频设置时所需的操作时间过长，例如 Intel 早期的 Speedstep 技术在对 CPU 进行变频设置时需要耗时 250 微秒，在此过程中 CPU 无法正常执行指令。