蜗窝科技

Linux PM QoS framework(2)_PM QoS class

作者：wowo 发布于：2015-2-10 23:09 分类：电源管理子系统

回顾上一篇文章（Linux PM QoS framework(1)_概述和软件架构），PM QoS framework抽象出4个系统级别的QoS constraint（统称为PM QoS class），分别是cpu&dma latency、network latency、network throughput和memory bandwidth。并提供一系列的接口，动态的搜集、整理系统对这些constraint的需求情况。

阅读全文>>

标签: Linux Kernel pm_qos qos

评论(7) 浏览(31067)

Linux PM QoS framework(1)_概述和软件架构

作者：wowo 发布于：2015-2-4 23:06 分类：电源管理子系统

QOS为Quality Of Service（服务质量）的简称，对PM QoS而言，表示Linux kernel电源管理相关的服务质量。那到底什么是服务质量呢？

我们知道，Linux PM的主要功能，是节省功耗，但同时，会付出一定的性能代价，例如延迟（latency）增加、吞吐量（throughput）下降。可以把PM当作一种服务，把它对性能的影响，类比为服务的质量（QoS）。对性能的影响越大，QoS越低，反之越高。

不过，PM QoS framework的存在，并不是为了定义并测量系统的服务质量（Linux系统对实际的qos没有任何兴趣），而是为了定义一套框架，以满足系统各个实体（如进程、设备驱动等等）对QoS的期望为终极目标。根据实际的场景，这些期望可描述为：xxx不大于某个值；xxx不小于某个值；等等。

这个终极目标，是基于这样的事实：机器是极端的实用主义者。最理想的状况，是刚刚满足系统各个实体对QoS的期望，因而可以在满足需求的同时，最大化的省电。粗俗一点，就是“我能考60分，为什么要多花一点力气去考61分？”。这样的思路，值得我们深思。

本文将基于PM QoS framework整体的软件架构，介绍它的功能、应用场景、使用方式等。

阅读全文>>

标签: Linux PM 电源管理 pm_qos qos

评论(5) 浏览(24316)

Linux cpuidle framework(4)_menu governor

作者：wowo 发布于：2015-1-18 23:14 分类：电源管理子系统

本文以menu governor为例，进一步理解cpuidle framework中governor的概念，并学习governor的实现方法。

在当前的kernel中，有2个governor，分别为ladder和menu（蜗蜗试图理解和查找，为什么会叫这两个名字，暂时还没有答案）。ladder在periodic timer tick system中使用，menu在tickless system中使用。

现在主流的系统，出于电源管理的考量，大多都是tickless system。另外，menu governor会利用pm qos framework（蜗蜗会在后续的文章中分析），在选择策略中加入延迟容忍度（Latency tolerance）的考量。因此本文选取menu governor作为分析对象，至于ladder，就不再分析了。

注：有关periodic timer tick和tickless的知识，可参考本站时间子系统的系列文章。

阅读全文>>

标签: Linux cpuidle menu governor pm_qos

评论(21) 浏览(22356)

Linux cpuidle framework(3)_ARM64 generic CPU idle driver

作者：wowo 发布于：2015-1-6 23:13 分类：电源管理子系统

本文以ARM64平台下的cpuidle driver为例，说明怎样在cpuidle framework的框架下，编写cpuidle driver。另外，本文在描述cpuidle driver的同时，会涉及到CPU hotplug的概念，因此也可作为CPU hotplug的引子。

阅读全文>>

标签: driver arm64 dts cpuidle

评论(13) 浏览(21138)

Linux cpuidle framework(2)_cpuidle core

作者：wowo 发布于：2014-12-30 22:38 分类：电源管理子系统

cpuidle core是cpuidle framework的核心模块，负责抽象出cpuidle device、cpuidle driver和cpuidle governor三个实体，并提供如下功能（可参考“Linux cpuidle framework(1)_概述和软件架构”中的软件架构）：

1）向底层的cpuidle driver模块提供cpudile device和cpuidle driver的注册/注销接口。

2）向cpuidle governors提供governor的注册接口。

3）提供全局的cpuidle机制的开、关、暂停、恢复等功能。

4）向用户空间程序提供governor选择的接口。

5）向kernel sched中的cpuidle entry提供cpuidle的级别选择、进入等接口，以方便调用。

本文会以这些功能为线索，逐一展开，分析cpuidle framework的实现思路和实现原理。

阅读全文>>

标签: Linux framework core cpuidle

评论(27) 浏览(30203)

Linux电源管理(13)_Driver的电源管理

作者：Physh 发布于：2014-12-26 18:31 分类：电源管理子系统

首先，回想一下wowo电源管理系列文章中提到的几个PM特性：

A. Wake Count/Wake Source

B. Wake Lock

C. Auto Sleep

D. Runtime Suspend

这篇文章就简单简单整理一下以上特性的在Driver中的使用场景，理解可能有偏差，大家多指教。

阅读全文>>

标签: Kernel driver

评论(32) 浏览(32430)

Linux电源管理(12)_Hibernate功能

作者：Physh 发布于：2014-12-22 11:51 分类：电源管理子系统

本文简要分析了Linux一种Hibernation实现机制——Swap Suspend的是实现方法。本文会尽量从机制出发，不会深入代码分析，如果您感兴趣，可以参照附件给出的流程图，阅读内核代码，相信您也可以找到其中乐趣。

A. Swap Suspend的原因

B. 如何实现STF

C. Swap Suspend的关键

阅读全文>>

标签: Kernel hibernation

评论(23) 浏览(22951)

Linux cpuidle framework(1)_概述和软件架构

作者：wowo 发布于：2014-12-17 23:04 分类：电源管理子系统

在计算机系统中，CPU的功能是执行程序，总结起来就是我们在教科书上学到的：取指、译码、执行。那么问题来了，如果没有程序要执行，CPU要怎么办？也许您会说，停掉就是了啊。确实，是要停掉，但何时停、怎么停，却要仔细斟酌，因为实际的软硬件环境是非常复杂的。

我们回到Linux kernel上，Linux系统中，CPU被两类程序占用：一类是进程（或线程），也称进程上下文；另一类是各种中断、异常的处理程序，也称中断上下文。

进程的存在，是用来处理事务的，如读取用户输入并显示在屏幕上。而事务总有处理完的时候，如用户不再输入，也没有新的内容需要在屏幕上显示。此时这个进程就可以让出CPU，但会随时准备回来（如用户突然有按键动作）。同理，如果系统没有中断、异常事件，CPU就不会花时间在中断上下文。

在Linux kernel中，这种CPU的无所事事的状态，被称作idle状态，而cpuidle framework，就是为了管理这种状态。

注：cpuidle framework系列文章会以ARM64作为示例平台，由于ARM64刚刚发布不久，较早版本的kernel没有相关的代码，因此选用了最新的3.18-rc4版本的kernel。

阅读全文>>

标签: Linux framework cpuidle

评论(42) 浏览(62920)

Linux common clock framework(3)_实现逻辑分析

作者：wowo 发布于：2014-11-24 22:31 分类：电源管理子系统

前面两篇clock framework的分析文章，分别从clock consumer和clock provider的角度，介绍了Linux kernel怎么管理系统的clock资源，以及device driver怎么使用clock资源。本文将深入到clock framework的内部，分析相关的实现逻辑。

注：本文使用的kernel版本为linux-3.10.29。虽然最新版本的kernel增加了一些内容，但主要逻辑没有改变，就不紧跟kernel的步伐了。

 

阅读全文>>

标签: Linux framework clock 实现

评论(21) 浏览(30447)

Linux PM domain framework(1)_概述和使用流程

作者：wowo 发布于：2014-11-13 22:09 分类：电源管理子系统

在复杂的片上系统（SOC）中，设计者一般会将系统的供电分为多个独立的block，这称作电源域（Power Domain），这样做有很多好处，例如：

1）将不同功能模块的供电分开，减小相互之间的干扰（如模拟和数字分开）。

2）不同功能所需的电压大小不同：小电压能量损耗低，但对信号质量的要求较高；大电压能量损耗高，对信号质量的要求较低。因此可以根据实际情况，使用不同的电压供电，例如CPU core只需1.2v左右即可，而大部分的I/O则需要3.3v左右。

3）系统运行的大部分时间，并不需要所有模块都处于power on状态，因此可以通过关闭不工作模块的供电，将它们的耗电降为最低。

4）等等

虽然电源域的好处多多，却不是越多越好，因为划分电源域是需要成本的（需要在PMU中使用模拟电路完成，包括金钱成本和空间成本）。因此，大多数系统会根据功能，设置有限的几个电源域，例如：CPU core（1、2、3…）；GPU；NAND；DDR；USB；Display；Codec；等等。

这种设计引出一个问题：存在多个模块共用一个电源域的情况。因而要求在对模块power on/off的时候，考虑power共用的情况：只要一个模块工作，就要power on；直到所有模块停止工作，才能power off。

Kernel的PM domain framework（位于drivers/base/power/domain.c中），提供了管理和使用系统power domain的统一方法，在解决上面提到的问题的同时，结合kernel的suspend、runtime pm、clock framework等机制，以非常巧妙、灵活的方式，管理系统供电，以达到高效、节能的目的。

同样，作为一个framework，我们可以从三个角度分析：使用者（consumer）的角度；提供者（provider）的角度；内部实现。具体如下。

注：本文的linux kernel版本为3.18-rc4。一般情况下，对于那些相对稳定的framework，蜗蜗不会说明文章所使用的kernel版本，但本文是个例外，因为PM domain很多方便、易用的patch，只能在最新版本（当前为3.18-rc4）kernel上才能看到。

阅读全文>>

标签: Linux PM 电源管理 framework domain

评论(32) 浏览(30080)