最近读了三篇1990-1995年的通过调度来降低cpu能耗的文章[1] [2] [3],简单总结一下该年代单核CPU功耗感知的调度策略。

Motivation

随着便携式设备逐渐兴起,人们对降低其功耗的研究开始出现,而在这之前,人们对计算机功耗的研究主要集中在显示和磁盘上,有研究表明,计算机系统中显示占总功耗的68%,磁盘读写占20%,而CPU只占12%[4]。其降低功耗的策略主要是power-down-when-idle,即不使用的时候就关掉设备。学者们逐渐意识到便携式设备通常没有磁盘,且在显示上消耗的能源并不是很多,对于这种设备,CPU成为了功耗的主要来源,而简单地将cpu在不用的时候关闭并不是最好的选择,因此需要使用其他手段来降低CPU的功耗。

当时对CPU低功耗的研究可以大致分为以下两个层次:

  • circuit level

    这不是我们关注的重点,大概有下面几种技术:

    • adiabatic switching

    • reversible logic

    • self-timed circuit[6]

      通过信号进行握手,计算复杂度(延迟)依赖数据,由于避免了冗余的反转,节省功耗。

  • operating level

    这一层级是我们的关注的重点,之前上一篇博客已经告诉我们动态功耗和电压频率的关系,那么简单来说通过减少电压或者频率可以达到功耗的降低。调整电压和频率很简单,但是知道在什么时候调整以及调整到什么水平却很难,所以操作系统层面的工作在于在“适当的时候”调整电压和频率。

Metric

在我们讲解操作系统调度策略之前,必须要加入这一章节,来介绍一下衡量调度策略好坏的指标,通常有以下几个物理量可以作为metric[5]:

  1. power:这并不是一个好的metric,因为它和频率成正比,降低频率可以实现power的降低,但同时会造成任务执行时间边长,总体上看一个任务消耗的能量是一样的。
  2. energy:通常用Jules/Instruction或其倒数SPEC/W来表示(SPEC是用来衡量CPU性能的指标,类似于频率或MIPS等),相同的表示还有power/performance和energy/throughput,该metric和供电电压的二次方成正比,比power指标要好,但这个指标也有一定的问题,处理器设计领域中,在衡量处理器的energy efficiency时,一个供电电压很低同时性能也很低的处理器和一个供电电压很高性能也很高的处理器,前者的energy肯定是要比后者要低的,但不代表前者在同等性能下,功耗会比后者低,有可能后者在高性能的条件下也将低功耗技术做到了极致,但是在energy这个metric上体现不出来。
  3. EDP(Energy Delay Product),我们通常想要的是同等性能下最小功耗或者同等功耗小最大性能,因此需要同时考虑energy和delay两个物理量,最简单的方法是令两者相乘(Jules/SPEC或其倒数SPEC^2/W),类似的还有EDDP等,这些指标更注重性能表现。

通常我们在调度算法中常见的metric是energy,最小化一个任务执行的energy是低功耗调度策略的目标。

Schedule

还是需要简单指出,三篇文章的背景均仅限于单核CPU下的功耗感知调度。

[1]工作最早,使用的energy metric为MIPJ,该metric不随时钟频率变化而变化,文章通过$E/clock \propto V^2$的关系指出降低供电电压可以实现大幅度energy减少,而电压和频率通常是线性关系,因此适当的降低频率减慢任务的运行可以减少energy。举个例子,一个任务要求100ms做完,普通系统全速运行50ms完成,然后进入idle等待50ms(假设不消耗energy),而如果可以降低电压,用一半的速度运行100ms正好完成,则Energy是原来的1/4。原因在于任务消耗的clock是一样的,但后者电压是前者的一半。通过这个例子,作者认为全速运行进入idle状态大大浪费了energy,因此应尽可能地晚点完成任务,减少在idle loop中的时间。

Put simply, the tortoise is more efficient that the hare

揣着这个目标,作者开始做实验了,其数据是从UNIX workstations上获取了一定时间范围内很多任务的信息,将他们划分为run_cycle和idle_cycle,并给出了以下假设:

  1. idle时不产生能量消耗
  2. energy和速度的平方成正比,而速度是平滑的(在下界和1.0中间变化)
  3. 转换速度不消耗时间
  4. 电压调节的范围有5、3.3、2.2和1,5V是速度的上界,后面三个电压给定了速度变化的下界,分别代表0.66、0.44和0.2。举个例子,当在3.3V情况下仿真时,其速度变化范围为[0.66, 1]。

基于上面四个假设,作者提出了三个算法:

  • unbounded-delay perfect-future(OPT)

    上帝视角,尽可能延长run_cycle,减少idle_cycle,是功耗最低的调度算法。

    • impractical:需要对未来有充分了解。
    • undesirable:产生巨大延迟,没有考虑到real-time event的相应需求。
  • bounded-delay limited-future(FUTURE)

    和OPT一样,也需要对未来有一定了解,但是存在一个小的window

    • impractical:也需要对未来有一定了解
    • desirable:延迟不会超过window时间
  • bounded-delay limited-past(PAST)

    存在一个小的window,根据过去window中的run_cycle和idle_cycle来调整执行速度,并在未来的一个window中以该速度执行。

我们主要关注有一定可行性的PAST算法,需要指出的是,在PAST算法中存在excess_cycle的概念,指上个window由于速度太慢导致未执行完的cycle需要移到下一个window中执行,也就是说该算法并不受real-time的限制,没有deadline time等概念。该算法的效果受到window interval和最小速度的影响,作者通过仿真得出结论:window interval过小时,调度粒度过细,节省的功耗越少;过大时则调度粒度过粗,excess cycle太多造成任务的响应时间太长。而电压为2.2V时,相比于1V可以提供绝大部分的功耗节省,同时有更少的excess_cycle。

[2]延续了[1]的工作,提出了更多的调度算法,相比于PAST有更好速度平滑效果和预测效果,目标都是尽可能降低速度(电压)来降低功耗。

[3]开始考虑到deadline time,提出了抢占式的最优调度算法。给出以下定义:

令t0和t1为固定时间间隔,调度问题可以看作在[to, t1]上执行集合J中的任务,假设每一个属于集合J的任务均有以下参数:

  • $a_j$ 到达时间
  • $b_j$ 截止完成时间(Deadline)
  • $R_j$ 需要的时钟周期数

调度是定义在[to, t1]上的一对函数S = (s, job)

  • s(t) >= 0定义为t时刻处理器的速度
  • job(t)定义为t时刻处理器执行的任务

s和job均为分段常量函数

对于任务集J,一个合理的(feasible)调度满足以下条件:

$$

\int_{aj}^{bj}s(t)δ(job(t), j)dt = R_j \quad for \ all \ j\ ∈\ J

$$

其中δ(x,y) = 1当x = y。总结来说对于每一个任务S必须满足其在到达时间和结束时间之间执行一定的CPU cycle(有可能是间断执行),我们假设能耗power是处理器运行速度的凸函数(convex function),则一个调度总体消耗的energy为

$$

E(S) = \int_{t0}^{t1} P(s(t))dt

$$

调度问题的目标被转化为对于任何的任务集,找到一个合理的调度S且令E(S)最小。

作者在文章中给出了一个离线最优的调度算法,重点是找出任务集J中的critical interval,根据critical interval计算得出critical job进行调度,然后删除被调度的任务,重新计算critical interval,进行递归求解,最后得到一个feasible且功耗最低的调度。

该算法的时间复杂度为$O(nlog^2(n))$,可以看到复杂度还是比较高的。之后作者又给出了一个在线启发式调度算法:Average Rate,通过计算每个任务的平均速度$d_j = R_i / (b_j - a_j)$,然后将t时刻所需要执行任务的平均速度相加,得到s(t),根据EDF策略调度任务执行。

Summary

由上可见,90-95年代利用动态调频的调度算法研究才刚刚开始,也只有[3]考虑了不违反deadline的constraint,[1]和[2]则是根据过去或者未来的一些情况,进行动态调频,如果没完成任务则留到下一个调节窗口执行。三篇论文的目标均为尽可能找到最小可执行速度,调节到其对应的电压。他们的局限在于没有考虑电压切换的开销以及处理器电压一般不能连续变化,且实际上有最大最小电压限制。

Reference

[1] Weiser, M., Welch, B., Demers, A. & Shenker, S. Scheduling for reduced CPU energy. in Proceedings of the 1st USENIX conference on Operating Systems Design and Implementation 2-es (USENIX Association, 1994).

[2] Govil, K., Chan, E. & Wasserman, H. Comparing algorithm for dynamic speed-setting of a low-power CPU. in Proceedings of the 1st annual international conference on Mobile computing and networking 13–25 (Association for Computing Machinery, 1995). doi:10.1145/215530.215546.

[3] Yao, F., Demers, A. & Shenker, S. A scheduling model for reduced CPU energy. in Proceedings of IEEE 36th Annual Foundations of Computer Science 374–382 (1995). doi:10.1109/SFCS.1995.492493.

[4] K..Li, R. Kumpf, P. Horton, and T. Anderson, “A quantitative analysis of disk drive power management in portable computers,” PTUC. Winter 1994 USENIX Conf., pp. 279-292, Jan. 1994.

[5] R. Gonzalez and M. Horowitz, "Energy dissipation in general purpose microprocessors," in IEEE Journal of Solid-State Circuits, vol. 31, no. 9, pp. 1277-1284, Sept. 1996, doi: 10.1109/4.535411.

[6] Nielsen, L. S., Niessen, C., Sparso, J. & van Berkel, K. Low-power operation using self-timed circuits and adaptive scaling of the supply voltage. IEEE Transactions on Very Large Scale Integration (VLSI) Systems 2, 391–397 (1994).

90-95年CPU功耗感知调度研究的更多相关文章

  1. 96-00年CPU功耗感知调度研究

    最近读了一些1996-2000年的通过调度来降低cpu能耗的文章,主要文章有[1] [2] [3] [4] [5], 简单总结一些该时期单核CPU功耗感知的调度策略. 该时期还出现了很多关于低功耗电路 ...

  2. CPU的自动调度矩阵乘法

    CPU的自动调度矩阵乘法 这是一个有关如何对CPU使用自动调度程序的文档. 与依靠手动模板定义搜索空间的基于模板的autotvm不同,自动调度程序不需要任何模板.用户只需要编写计算声明,而无需任何调度 ...

  3. 使用XTU降低CPU功耗,自动执行不失效

    INTEL出品的XTU可以用来做软超频操作,给CPU/GPU加电压超频,也可以通过降低CPU/GPU电压来减少功耗. 以前用XTU设置好了之后,过一段时间就自动失效了,最近失效的频率突然很高,于是找了 ...

  4. mysql 占用90%多的CPU,解决思路

    网站打开很慢,爆出了连接数据库的错误,进入服务器,top 看了下,mysql占用cpu 基本维持在90以上: mysql> show variables like '%slow%';      ...

  5. wipefs进程是啥,占用了百分之90多的cpu

    http://www.cnblogs.com/liuchuyu/p/7490338.html

  6. 操作系统概念学习笔记 10 CPU调度

    操作系统概念学习笔记 10 CPU调度 多道程序操作系统的基础.通过在进程之间切换CPU.操作系统能够提高计算机的吞吐率. 对于单处理器系统.每次仅仅同意一个进程执行:不论什么其它进程必须等待,直到C ...

  7. OS之进程管理---实时CPU调度

    引言 一般来说,我们将实时操作系统区分为软实时系统(soft real-time system)和硬实时系统(hard real-time system).软实时系统不保证会调度关键实时进程,而只保证 ...

  8. 操作系统学习笔记:CPU调度

    CPU调度的目的在于提高CPU利用率,不让CPU闲着.CPU是宝贵的资源,如果有一个进程,本来在CPU中运行,忽然因为要使用IO资源,于是转而请求IO,这边CPU挂起,造成就绪队列中的其他进程等待,这 ...

  9. g77介绍 g77 是 Fortran77 的编译器。它对 Fortran 77 标准提供完备的支持,并支持 Fortran 90 和 95 的部分特性。 由于 Fortran 77 标准在数值计算中的影响力,g77 可能是应用最广的Fortran编译器。 在 GCC 4.0 之前,g77 是 GCC 的一部分,但现在,g77 已经停止开发。

    GFORTRAN 维基百科,自由的百科全书     跳到导航 跳到搜索 此条目需要扩充. (2018年11月2日)请协助改善这篇条目,更进一步的信息可能会在讨论页或扩充请求中找到.请在扩充条目后将此模 ...

随机推荐

  1. ECMA 2022 (es13) 新特性

    本文主要整理了截至到 2021年10月12日 为止的且处于 Stage 3->Stage 4 阶段的ECMA提案. 主要包括: Class Fields RegExp Match Indices ...

  2. 飞猪基于 Serverless 的云+端实践与思考

    作者 | 王恒飞(承荫) 本文整理自飞猪旅行前端技术专家--王恒飞(承荫)在[阿里云 Serverless Developer Meetup 上海站]上的分享.点击查看直播回放:https://dev ...

  3. 洛谷4219 BJOI2014大融合(LCT维护子树信息)

    QWQ 这个题目是LCT维护子树信息的经典应用 根据题目信息来看,对于一个这条边的两个端点各自的\(size\)乘起来,不过这个应该算呢? 我们可以考虑在LCT上多维护一个\(xv[i]\)表示\(i ...

  4. pytest执行时mian函数传参

    在代码中执行pytest可以通过main函数 加参数来指定运行规则时,参数需要放在列表或者元祖中 # pytest.main(["--html=report.html"]) # p ...

  5. 这么多TiDB负载均衡方案总有一款适合你

    [是否原创]是 [首发渠道]TiDB 社区 前言 分布式关系型数据库TiDB是一种计算和存储分离的架构,每一层都可以独立地进行水平扩展,这样就可以做到有的放矢,对症下药. 从TiDB整体架构图可以看到 ...

  6. k8s学习笔记(3)- kubectl高可用部署,扩容,升级,回滚springboot应用

    前言:上一篇通过rancher管理k8s,部署服务应用扩容,高可用,本篇介绍kubectl命令行部署高可用集群节点,测试升级.扩容等 1.测试环境:3节点k3s,使用其中2节点(ubuntunode1 ...

  7. Java泛型背后是什么?

    文Java中泛型的应用,让大家更好地理解泛型,以及常说的泛型类型擦除是什么概念,举一个简单的例子,如下: 这里可以看出来在代码编写阶段就已经报错了,不能往string类型的集合中添加int类型的数据. ...

  8. 深入理解java中main方法

    理解main方法语法 深入理解main方法: 解释main方法的形式:public static void main(String[] args){} main方法调用者:虚拟机 java虚拟机需要调 ...

  9. HCNP Routing&Switching之BGP路由宣告

    前文我们了解了BGP报文结构.类型以及邻居状态相关话题,回顾请参考https://www.cnblogs.com/qiuhom-1874/p/15422924.html:今天我们来聊一聊BGP路由宣告 ...

  10. SpringCloud 2020.0.4 系列之Eureka

    1. 概述 老话说的好:遇见困难,首先要做的是积极的想解决办法,而不是先去泄气.抱怨或生气. 言归正传,微服务是当今非常流行的一种架构方式,其中 SpringCloud 是我们常用的一种微服务框架. ...