Linux PM QoS framework(3)_per-device PM QoS

作者:wowo 发布于:2015-2-26 22:44 分类:电源管理子系统

per-device PM QoS是针对指定设备的QoS framework,背后的思考如下:

1)resume_latency

Runtime PM的框架下,当device的引用计数减为0的时候,RPM会suspend该device。不过,device进入suspend状态以及从suspend状态resume是需要消耗时间的(相关信息保存在pm domain中),而系统其它实体(如用户空间程序)可能对该设备的响应时间有要求,这就是一种形式的QoS request,称作resume_latency。

per-device PM QoS framework会提供相应的接口,收集指定设备的resume_latency request,并提供给Runtime PM,它在suspend设备时,会考虑这种需求,并决定是否suspend设备。

2)latency_tolerance

一些复杂的设备,在运行状态(active)时,为了节省功耗,也有可能自行进入某些省电状态,相应的,设备的响应速度可能降低。如果该设备足够智能,可能会提供一个回调函数(.set_latency_tolerance,位于dev_pm_info结构中),以便设置最大的延迟容忍时间。这称作latency_tolerance。

对per-device PM QoS来说,需要提供一种机制,收集所有的、针对某个设备的latency_tolerance需求,并汇整出可以满足所有需求的latency_tolerance,通过设备的回调函数告知设备。

3)no power off/remote wakeup

Runtime PM的框架下,设备suspend之后,还可以进一步通过pm domain关闭该设备的供电,以节省功耗。但关闭供电时,除了要考虑对设备resume_latency的需求之外,还要考虑该设备是否允许关闭供电,以及该设备是否需要作为一个唤醒源(remote wakeup)。

这是另一种形式的QoS request,称作per-device PM QoS flag,表示系统其它实体对该设备的一些特定行为的需求。当前的flag有两种:

PM_QOS_FLAG_NO_POWER_OFF,表示不允许设备断电
PM_QOS_FLAG_REMOTE_WAKEUP,表示设备应具备唤醒功能

这两个flag可以通过或操作,同时生效。

因此,per-device PM QoS framework的功能,就是抽象上面两类需求,包括:向requestor提供QoS request的add、update、remove等API,包括内核空间API和用户空间API;汇整、整理这些request;向电源管理有关的service(主要是pm domain framework)提供汇整后的request信息,以便这些service可以做出正确的决定。

下面将会结合source code(位于drivers/base/power/qos.c中),介绍上面的实现逻辑。

阅读全文>>

标签: Linux Kernel pm_qos per-device

评论(9) 浏览(4133)

支持wowo,有这样一块小天地享受技术,感觉棒棒哒!

作者:孤寂的侵凌 发布于:2015-2-25 0:21

希望以后都可以没事来看一看,玩一玩,和wowo以及朋友们讨论一些问题!

评论(6) 浏览(3178)

计算机科学基础知识(三):静态库和静态链接

作者:linuxer 发布于:2015-2-16 15:15 分类:基础学科

本文是编译、链接和加载系列文章中的第二篇,主要描述静态链接

阅读全文>>

标签: 静态库 静态链接

评论(3) 浏览(4999)

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

评论(5) 浏览(6355)

计算机科学基础知识(二):Relocatable Object File

作者:linuxer 发布于:2015-2-9 19:17 分类:基础学科

一个合格的c程序员(也可以叫做软件工程师,这样看起来更高大上,当然,我老婆心情不好的时候总是叫我“死打字的”,基本也能描述这份职业,呵呵) 需要理解编译、链接和加载的过程,而不是仅仅关注c语言的语法和词法。本文主要以此为切入点,描述linux系统下,一个普通的hello world程序的生命历程,并借机灌输一些程序编译时和运行时的基本术语和概念。当然,由于我本人是一个linuxer,因此借用linux来描述这些知 识会方便些,但是对于计算机科学而言,这些东西概念上是类似的,只是实现细节不同而已(windows程序员或者其他程序员可以阅读本文哦)。

本 文也是阅读了Computer System,A programmer’s perspective的第七章的一个读书笔记,方便日后查阅。注:Computer System,A programmer’s perspective绝对是一本值得反复阅读的书籍,强力推荐。

阅读全文>>

标签: Object Relocatable File

评论(10) 浏览(8299)

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) 浏览(6909)

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog