ACM

ACM通信

首页 / 杂志存档 / 2010年2月(第53卷第2期) / 低功耗软件 /全文

实践

低功耗软件

由埃里克·萨克斯
ACM通讯，2010年2月，Vol. 53 No. 2, 44-48页
10.1145/1646353.1646370
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit分享在StumbleUpon分享分享到黑客新闻在推特上分享在Facebook上分享

电源管理功能的发展速度简直令人惊叹。今天，几乎每一种大小和级别的计算机系统，从最小的传感器和手持设备到数据中心中的“大铁器”服务器，都提供了大量减少、计量和限制功耗的功能。如果没有这些功能，风扇的噪音将会主导办公室的氛围，而没有连接的笔记本电脑只能在很短的几个小时内可用(只有在人们能够承受高温的情况下)，而数据中心的电力、冷却成本和容量将变得难以控制。

尽管我们可能会认为电源管理功能是硬件的同义词，但软件在整个系统效率中的作用已成为不可否认的。尽管“软件功耗效率”的概念可能看起来很奇怪(因为软件并不直接消耗功耗)，但突出的部分实际上是软件与功耗系统资源交互的方式。

让我们首先将软件划分为两个熟悉的生态系统角色:资源管理器(生产者)和资源请求者(消费者)。然后，我们将研究每种因素如何影响(或破坏)整体系统效率。

电源管理的历史根源于小型系统和移动空间。按照今天的标准，这些系统相对简单，只拥有少量的组件，比如单核CPU和可能会休眠的磁盘。因为这些系统的资源很少，所以在实际使用中基本上是二元的，系统的资源要么在使用，要么不在使用。因此，电源管理资源的策略也可能相当简单，但很有效。

例如，一个守护进程可能会周期性地监视系统利用率，在一段时间内出现足够的空闲后，降低CPU的频率并关闭磁盘。这一切都可以以一种只需要很少或不需要与其他负责资源管理的子系统集成的方式来完成(例如，调度程序、文件系统等等)，因为在零利用率的情况下，不需要进行太多的资源管理。

相比之下，现代系统的拓扑结构要复杂得多。随着不断增长的CPU时钟速度这一“免费性能午餐”的结束，多核革命即将到来，其结果是，即使是最小的便携设备也存在多个需要管理的逻辑CPU。随着这些系统规模的扩大(呈现出更多的电力管理资源)，当系统只有一部分繁忙而其余部分空闲时，部分利用变得更加常见。当然，cpu只是电源管理系统资源的一个例子:物理内存的部分可能(很快)是电源管理的，对于存储和I/O设备也是如此。在更大的数据中心上下文中，系统本身可能是电力管理的资源。

现代系统中有效的资源管理要求至少有一定程度的资源管理者意识到不同的资源权力状态带来的异质性，并在可能的情况下对其进行一定的利用。(实际上，有效的资源管理通常需要意识到资源的异质性，不同的权力状态是资源异质性产生的一种方式。)根据所管理的内容，考虑因素可能是空间的、时间的，或者两者兼而有之。

回到顶部

空间的考虑

空间考虑包括决定提供哪些资源以及时响应消费者的请求。对于操作系统线程调度器/调度器，这可能决定向哪些cpu分配可运行线程，以及跨系统物理处理器的线程的总体最佳分布模式，以满足某些策略目标(性能、电力效率等)。对于虚拟内存子系统，对于物理内存的使用也是如此;对于文件系统/卷管理器，跨磁盘的块分配策略;以及在数据中心中，虚拟机如何跨物理系统放置。这些不同类型的资源管理器显示在图1．

其中一个空间方面的考虑是现有资源的当前动力状态。在某种意义上，一种资源的权力状态可以说是一组权衡。一些状态提供了一种机制，允许系统在性能和功耗之间进行权衡(CPU频率伸缩就是一个例子)，而其他状态可能提供(对于空闲资源)降低功耗与增加恢复延迟之间的权衡(例如，ACPI的c状态)。因此，资源管理器选择一种资源而不是另一种资源(基于电源状态)的行为是进行这种权衡的重要工具，理想情况下应该补充单个资源的电源管理策略。

管理资源的粒度是另一个重要的空间考虑因素。如果多核处理器只能在套接字级别上进行电源管理，那么就有很好的动机将系统负载整合到尽可能少的套接字上。整合提高了某些资源的利用率，同时暂停了其他资源。这允许对暂停的资源进行电源管理，同时将电源(和性能)“引导”到已使用的系统部分。

影响单个资源选择和利用分布决策的另一个因素是使用资源的工作负载的特征。例如，这可能决定资源管理器在不影响性能(由于资源争用)的情况下如何积极地整合整个系统的利用率，或者改变已使用资源的电源状态将在多大程度上影响用户的性能。

回到顶部

时间的考虑

一些资源管理器还可以根据时间以及(而不是)空间来分配资源。例如，计时器子系统可能允许客户机在未来的某个时间点(或某个时间间隔)安排一些处理，或者任务队列子系统可能提供异步或延迟执行的方法。对这些子系统的接口传统上是非常狭窄和规定性的，几乎没有留给时间优化的空间。一种解决方案是向本质上更具描述性的客户机提供接口。例如，与其提供一个狭窄的接口来精确说明应该发生什么以及何时发生:

计时器接口可以指定需要做什么，并在需要发生时描述约束条件:

类似于将负载合并到更少的套接字上以改善空间资源休眠，提供一些时间范围允许计时器子系统合并和批处理进程过期。而不是唤醒CPUn在给定的时间间隔内处理的次数n计时器(每次唤醒都会产生一些开销)，计时器子系统可以一次性唤醒CPU，并根据(更宽松的)约束批量处理所有允许的计时器，从而减少CPU开销时间并增加电源管理状态的驻留时间(参见图2)．

回到顶部

高效的资源消耗

显然，资源管理器可以对系统的整体效率做出很大贡献，但最终它们不得不在系统资源使用者提出的约束和请求范围内工作。如果约束过多，资源分配过度或没有有效地使用，那么即使是最复杂的电源管理特性的好处也可能是徒劳的，而整个系统堆栈的效率会受到影响。

设计良好、高效的软件是一种美丽的事物，它显示了利用率(和完成的有用工作)与消耗的资源数量之间的良好比例。对于乌托邦式的软件来说，这样的比例将是完美的，表明当没有工作完成时，没有使用任何资源;随着资源利用率的增加，完成的工作量也会增加(参见图3)．

但是，真正的软件并不是空想，让软件不消耗任何资源的唯一方法就是根本不运行它。实际上，即使在最低限度内运行性能非常好的软件，也需要一些资源开销。

相比之下，效率低下的软件在资源利用和完成的工作量之间显示出较差的比例。下面是一些常见的例子:

进程正在等待某些东西，例如某个条件的满足，并使用计时器周期性地唤醒以检查条件是否满足。在等待过程中没有任何有用的工作，但是每次它醒来检查时，CPU都会被迫离开空闲的电源管理状态。更糟糕的是，进程决定以高频率唤醒以“最小化延迟”(见图4)．
应用程序使用多个线程来提高并发性和扩展吞吐量。它盲目地创建与系统中cpu数量相同的线程，尽管由于内部瓶颈，应用程序无法扩展到少数线程。拥有更多的线程意味着必须唤醒更多的cpu来运行它们，尽管每增加一个线程对性能的贡献很小，甚至没有边际(参见图5)．
服务会缓慢地泄漏内存，随着时间的推移，它的堆会增长，消耗大量系统的物理内存，尽管实际上几乎不需要这些内存。因此，几乎没有机会对内存进行管理，因为大部分内存已经被分配。

回到顶部

观察软件生态系统中的低效

软件效率的综合分析需要观察资源利用与所执行的有用工作的比例关系的能力。当然，“已完成工作”的度量本质上是特定于工作负载的。一些工作负载(如Web服务器和数据库)可能是基于吞吐量的。对于这种工作负载，一种技术是绘制吞吐量(例如，每秒事务)与{cpu|内存|带宽|存储}资源消耗的关系。在曲线中存在“拐点”的地方(资源利用率上升，但吞吐量没有上升)，就有机会使用更少的资源来完成相同的工作，或者消除瓶颈，以便使用相同的资源来完成更多的工作。

对于使用并发性来加速处理的并行计算工作负载，可以绘制经过的计算时间和消耗的资源，并使用类似的技术来识别和避免收益递减点。

与使用特定于工作负载的分析不同，另一种富有成效的技术是查看系统范围内的资源利用行为，在什么情况下利用率应该为零(系统空闲)。根据定义，系统没有做任何有用的事情，所以任何积极消耗CPU周期的软件都是可疑的。PowerTOP是Intel开发的一个开放源码实用程序，专门用于支持这种分析方法(参见图6)．在一个本来应该是空闲的系统上运行该工具，理想情况下，系统的处理器100%都是电力管理的，但在实践中，低效的软件(通常进行周期性的基于时间的轮询)将使cpu略微繁忙。PowerTOP显示了浪费的程度，同时也显示了哪个软件是罪魁祸首。然后，系统用户可以将观察到的浪费报告为bug，并/或选择运行更高效的软件。

回到顶部

设计高效的软件

效率作为软件的设计和优化点乍一看可能有点陌生，所以让我们将其与其他一些可论证的更成熟的点进行比较:性能和可伸缩性。

在给定一组固定资源的情况下，性能良好的软件可以最大限度地增加已完成的有用工作的数量(或最小化完成工作所需的时间)。
可伸缩软件将证明，随着使用更多的资源，性能会成比例地提高。

高效的软件可以说是性能和可伸缩性都很好，但是在资源利用方面有一些额外的限制。

给定一个固定的性能水平(完成有用工作的数量或完成它所花费的时间)，软件使用所需的最少资源集。
随着性能的降低，资源利用率也会相应降低。

这意味着除了关注绩效的数量和比例之外考虑到资源利用率，为了获得效率，软件设计师还需要考虑资源利用的数量和比例考虑到性能。如果这一切看起来太抽象，这里有一些更具体的因素要记住:

在设计需要自己获取资源的软件时，确保它理解完成工作需要哪些资源，并在不需要时返还这些资源，以方便空闲资源电源管理。如果所采购的资源是间歇性地需要的，那么让软件尝试利用一些特性，这些特性可以向资源管理器提供关于何时使用(或何时不使用)资源的提示，至少可以促进有源电源管理。

关于CPU利用率:

当线程等待某些条件时，尝试利用事件触发模式来消除基于时间的轮询的需要。不要写“我们到了吗?”的软件。
如果这是不可能的，尝试不频繁地投票。
如果无法消除它，那么至少要确保批量处理所有周期性/轮询活动。利用提供优化空间的计时器子系统特性，例如粗化分辨率或允许计时器提前/延迟。

关于内存利用率:

注意内存泄漏。
释放或取消映射不再需要的内存。一些操作系统提供有关内存利用率的咨询接口，例如Solaris下的madvise(3c)。

关于I/O利用率

如果可能的话，缓冲/批处理I/O请求。

回到顶部

朝着高效的系统堆栈前进

每隔一段时间，硬件设计的发展和创新就会给软件带来新的机遇和挑战。即使在最大的系统中，降低未充分利用的系统资源功耗的特性也已经非常普遍，负责管理这些资源的软件层必须逐步实现策略，以提高已利用资源的性能，同时降低未充分利用的资源的功耗。

除了资源管理器之外，资源使用者显然有很大的机会提高或破坏更广泛堆栈的效率。尽管让程序员从不同的角度思考他们设计软件的方式不仅仅是一个技术问题，但是像PowerTOP这样的工具代表了一个伟大的第一步，它向程序员和管理员提供了对软件效率低下的观察、优化的参考点，以及对软件在节能计算中扮演的重要角色的认识。

作者

埃里克·萨克斯是Sun微系统公司Solaris内核开发组的一名工程师。在Sun工作的过去10年里，他参与了许多与调度器/调度器相关的内核组件，包括CMT(芯片多线程)调度子系统、Power Aware Dispatcher和MPO (Solaris NUMA框架)，他是几个相关的美国专利的主要发明人。

回到顶部