这里总结自己开发的经验，熟悉内核设备节点，对内核相关驱动的学习和开发都很有帮助

1 cpu信息查看

android应用设置界面，关于菜单下可以查看手机或者平板android设备的信息，这些信息都是内核预留出来的接口

作为内核开发人员，可以直接在串口调试查看到这些信息

#cd  /sys/devices/system/cpu/

在这个目录下有CPU的所有信息，如果是双核设备，会有cpu0 cpu1，cd进去，就可以看到很多信息了

2 cpu负载查看方法

这里给个链接，我学习的时候觉得比较好的

http://songxj.blog.51cto.com/620981/840906 

第一个命令是# uptime 

7:51pm up 2 days, 5:43, 2 users, load average: 8.13, 5.90, 4.94

命令输出的最后内容表示在过去的1、5、15分钟内运行队列中的平均进程数量

第二个命令就是cat /proc/loadavg

这些命令自己用下就知道是什么方面的信息了

3 cpu策略相关节点

http://blog.csdn.net/ganggexiongqi/article/details/6791659 

#cd  /sys/devices/system/cpu/

同样在这个目录下，cpu策略是cpu信息的一部分，当然和cpu信息查看在大目录上是一样的

只是后面的子目录分开了

在/sys/devices/system/cpu/cpufreq/下，有系统当前策略的相关设备节点，这些节点是策略初始化时候建立的

例如interactive策略，就会有个目录是interactive，cd进去，会看到这个策略的很多子目录接口，各有用处

可以结合代码看，也可以每个cd进去，或者cat echo下看看

在/sys/devices/system/cpu/cpu0/cpufreq/下，会看到stats节点，cd进去会有两个子节点，一个是cpu切换频率总次数，一个是cpu调频过程，调频结果频率分布，可以cat下

这些节点，被某些apk使用，就出来很多关于cpu操作显示的应用，比如查看cpu频率分布百分比的饼图

或者改变省电模式，改变cpu策略，设置负载阈值，等等

       纵观这几年的发展，移动手机的发展真是翻天覆地，前两年诺基亚一统天下，苹果颠覆了整个手机市场，安卓也分得了一杯羹，WindowPhone手机也纯纯欲动，Bada也抓紧推出自己的系统。360也要推出自己的手机系统，百度，腾讯纷拥而至。未来世界是谁的，说不好，让我们拭目以待吧。

                                                                                                                                                                    ------题记

        我从09年接触Android的，当时感觉Android离我太遥远了，没想到，到2010年Android铺天盖地席卷中国市场，摩托，HTC，菲利普，三星，联想，华为，中兴，酷派。。。等等，纷纷登上手机销售的舞台。当时我是做网站的，有同学做Android的，薪水挺高的。我刚参加工作，所以想先入门编程，然后再转行，所以在10年我没有进军Android，现在看来还是慢了一步。但我也没闲着、默默关注着这个行业，看它到底能走多远。。。

        君不见市场行情有多快，Android在10年迅速膨胀起来，这一年做Android的人挺火的，待遇都挺高的。与此同时，培训机构打着Android的旗号到处招生，看来培训机构也是跟着行情走。2011年我在同学的劝说下也按捺不住，转行进军Android，在转行之前，我先在网上下载视频，自学点Android入门的知识，搭建环境，写个小demo，自己还沾沾自喜的。第一份工作是做Android的office办公软件的，因为Android手机系统没有自己的office，（后来谷歌收购了一家做office的公司）所以一些公司看到这个情况，自己写office办公软件，卖给手机厂商，定制厂商自己的office办公软件，我当时负责的工作是改界面，根据客户的需求修改一些功能，干了3个月，感觉这个工作做起来得心应手了，就换了一家专做手机的公司。

        做手机的公司有钱途，也让我真正解了Android的架构，系统级地了解Andorid，我建议找工作还是找专做手机的公司。我刚开始就是做些杂活，解决短信Mms的一些bug。后来公司分工，我负责的模块是Launcher，同时也写一些配置脚本，了解了一些Linux的命令和语法。当时做的工作相对比较简单，在同事忙的时候也负责解决一些他们解决不过来的bug。后来分到我头上的模块变成Browser和Launcher，当时由于公司没有定制Launcher的需求，我专心搞了2个多月的Browser的问题，Android原生的2.3的Browser问题多多，尤其过联通测试的时候，一堆问题等着解决，公司做的手机是中低端，还是给别的公司定制的那种，所以有时候走商务来解决联通测试过不了的问题。通过做浏览器的模块，对Android的上网机制有了一定的了解。回想起当初刚接触Android源码的时候，感觉太大了，看什么类都看不懂，看得也非常吃力，现在回过头来一看，其实就是那么回事。多看几遍对流程有了一定的了解，bug就好解决了。最近公司和韩国做项目，需要定制4.0的Launcher，于是乎我就参与其中，Launcher模块不是特别复杂，基本的设计思想能看个大概，用到了MVC的设计思想，接口的思想，工厂模式等等，我通过3周的开发，基本搞定了大体功能。通过这3周的开发，得到了一个结论：“遇到事不慌，耐心研究，多看几遍，没有过不去的坎!”。做手机行业1年多了，感觉Android市场还有一定的市场份额，Android升级挺快的，一直在变化，从3.0到4.0，经过了短暂的时间，马上Android就要出5.0了，Android的版本升级基本上能跟上大家对新鲜事物好奇的节奏。但是背后累坏了那些硬件厂商，一直跟在Android屁股后面跑，Android上层framework和app层的代码基本不变，能适配所有的手机，但是Android底层BP，keneral层，厂商不同驱动就不一样，这就导致了公司做底层的一个项目对应一个厂商的型号；而上层来说一个项目修改了这个bug，所有的项目都适用。其实都一样，只要对这个模块有了一定的认识，对这个流程有了明确的认识，解决任何问题都不难。

        以上是我对Android工作的认识，下面来谈谈对Android手机的分析，Android确实给一些手机厂商带来了福利。比如说HTC，三星，都是借助Android的平台成为了手机的领军者，中兴，华为这些国内大公司也来抢占手机市场的份额，魅族手机，前身是做mp3的，现在在Android市场也占有一定份额，还有就是去年10月份开始火的小米手机，也是手机行业的一朵奇葩，屹立在Android阵营中。Android的开放式系统，虽然不同的版本，不同的分辨率给我们开发者带来了不必要的麻烦，但是也符合了市场灵活多变的要求。随着Android4.0的推出，谷歌意识到版本的问题，尽量代码中做到统一，手机和平板用一个操作系统。相信在5.0  ， 6.0中谷歌会更加注意到这点的。

        好了，废话说了这么多，总结一下，以后手机这个行业会起到非常重要的作用，而且它的发展会越来越快，对我们的生活来说越来越重要，手机的功能不仅仅是传统的打电话和发短信，更多的是有一种替代电脑的趋势。手机不仅仅给我们带来了通讯的功能，更多地是给我们生活带来了娱乐，带来了便利。手机有自己操作系统，这就像是一场工业革命。标志着我们进入到了一个新的时代。让我们期待移动手机未来美好的明天！

以下是基于interactive代码详细分析下的一些见解

从网上搜索的，比较详细的是：

http://bbs.gfan.com/android-976301-2-1.html

Advantages:
+ significantly more responsive to ramp cpu up when required (UI interaction)
+ more consistent ramping, existing governors do their cpu load sampling in a workqueue context, the 'interactive' governor does this in a timer context, which gives more consistent cpu load sampling.
+ higher priority for cpu frequency increase, rt_workqueue is used for scaling up, giving the remaining tasks the cpu performance benefit, unlike existing governors which schedule rampup work to occur after your performance starved tasks have completed.
优点：
此模式在与用户交互的时候，反应速度更快（即是频率调节的速度更快，更能随时对及时处理器的符合作出反应），由此，便可以提供更好地用户体验（conservative模式反应速度慢于此，因此有时候会出现稍卡的体验）
当然，为了达成这一点，interactive有更高的处理器负荷采样率，并且摒弃了上述两种调节方式在高负荷时候处理器频率不满足需求以后才进行调频，interactive保证了更快的反应，保留了频率调节器的高优先级，来更快地处理器负荷高起来的时候将频提高。

那么，我就有如下疑问：

反应速度如何更快？

为何需要更高采样率？更高是指多少的采样率？

举例说明如何升频，如何降频？

结合代码分析策略

cpufreq_interactive_init

初始化对5个全局变量进行赋值

三个参数：

go_hispeed_load = DEFAULT_GO_HISPEED_LOAD;

min_sample_time = DEFAULT_MIN_SAMPLE_TIME;

timer_rate = DEFAULT_TIMER_RATE;

一个队列：

/* No rescuer thread, bind to CPU queuing the work for possibly

   warm cache (probably doesn't matter much). */

down_wq = alloc_workqueue("knteractive_down", 0, 1);

一个任务栈：

up_task = kthread_create(cpufreq_interactive_up_task, NULL,

 "kinteractiveup");

go_hispeed_load：是高频阈值。当系统的负载超过该值，升频，否则降频。具体如何升频、如何降频，后面介绍。

min_sample_time: 最小采样时间。每次调频结果必须维持至少这个时间。

timer_rate：采样定时器的采样率。

down_wq ：降频队列。降频是以队列方式实现，实时性不高，或者说优先级较低。

up_task：升频任务栈。升频是以线程方式实现，只要有升频需求，立即生效，实时性高，优先级非常高。

到这里，对网上解释的“反应速度快”“保留了频率调节器的高优先级”就可以理解了。

下面介绍如何升频、如何降频

调频定时器，定时器时间被固定，每个timer周期完成如下事情：

检查策略有效性，即是否当前策略使能状态

系统在最近一个采样周期内的负载计算，用于决定升降频

根据负载，得出升降频的判定

升频/降频的实施

下面就是该策略的精髓了，如何判定升降频

if (cpu_load >= go_hispeed_load) { if (pcpu->policy->cur == pcpu->policy->min) new_freq = hispeed_freq; else new_freq = pcpu->policy->max * cpu_load / 100; } else { new_freq = pcpu->policy->cur * cpu_load / 100; }

这里

go_hispeed_load = 816MHz

pcpu->policy->min = 252MHz

pcpu->policy->max = 1416MHz

把代码转换成语言描述就是

1、如果系统负载超过负载阈值，而且系统当前频率是系统最低频，那么升频到816MHz

2、如果系统负载超过负载阈值，但是系统当前频率不是最低频率，那么升频到1416MHz*系统负载

3、如果系统负载没有超过负载阈值，那么降频到 系统当前频率*系统负载，至于是否降频还是保持当前频率后面自然会处理

到此，对网上解释“频率调节的速度更快，更能随时对及时处理器的符合作出反应”就很好理解了。

接下来，对于升频或者降频，新频率值的确定是策略的另一部分，且往下看

#define CPUFREQ_RELATION_L 0  /* lowest frequency at or above target */

#define CPUFREQ_RELATION_H 1  /* highest frequency below or at target */

这两个声明的作用是，当我们用上面负载乘以频率得到的频率值，在频率列表中查找对应频率点时，CPUFREQ_RELATION_L 是取上限值，CPUFREQ_RELATION_H 是取下限值。

对于上面去上限值还是下限值如果不理解，或者有疑问，看下代码

struct cpufreq_frequency_table optimal = { .index = ~0, .frequency = 0, }; struct cpufreq_frequency_table suboptimal = { .index = ~0, .frequency = 0, };

第一步：初始化两个结构体，索引号很大，频率为0

switch (relation) { case CPUFREQ_RELATION_H: suboptimal.frequency = ~0; break; case CPUFREQ_RELATION_L: optimal.frequency = ~0; break; }

第二步：这一步要结合下面一起看

for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) { //循环频率列表，寻找需要的频率值 unsigned int freq = table[i].frequency; if (freq == CPUFREQ_ENTRY_INVALID) continue; if ((freq < policy->min) || (freq > policy->max)) continue; //有效性检查结束 switch (relation) { case CPUFREQ_RELATION_H: //如果是H，在上一步中suboptimal.frequency = ~0，optimal.frequency = 0 if (freq <= target_freq) { //当前频率比目标频率小，记录当前频率作为下限 if (freq >= optimal.frequency) { optimal.frequency = freq; optimal.index = i; } } else {//当前频率比目标频率大，记录当前频率作为上限 if (freq <= suboptimal.frequency) { suboptimal.frequency = freq; suboptimal.index = i; } } break; case CPUFREQ_RELATION_L: if (freq >= target_freq) { if (freq <= optimal.frequency) { optimal.frequency = freq; optimal.index = i; } } else { if (freq >= suboptimal.frequency) { suboptimal.frequency = freq; suboptimal.index = i; } } break; }

第三步：找到了目标频率对应在那个频率段，并且知道了上下限频率值

if (optimal.index > i) {//如果下限频率是最高频 if (suboptimal.index > i) return -EINVAL; *index = suboptimal.index;//如果已经是最后一档的频率，取最高频 } else *index = optimal.index;//正常情况，取下限频率

举个例子：

当前系统频率504MHz，系统负载阈值80，当前系统负载90

索引列表是 

252 504 816 1008 1200 1272 1416

由系统负载算出新频率（目标频率）是

1416 * 90% ， 介于1272和1416之间，取1272MHz

Interactive策略考虑的比较细，因为当系统在最低频，例如252MHz时，稍微的任务启动，都会使得系统负载时100%，如果按照以上算法，必定跑到系统最高频，

例如1416MHz。

所以对于系统最低频有特殊处理

当系统处于最低频时，负载超过负载阈值，直接升频至已经实现指定的go_hispeed_load ，例如816MHz。

以上是升频的算法，接下来看看如何决定降频值

当系统负载没有达到负载阈值，就决定要降频了，不同于升频的是，降频是用系统当前频率，也就是系统自身频率值，乘以负载百分比，得到新频率，即目标频率，同样在频率索引列表中，寻找合适的频率值，也是取下限频率。

举个例子：

当前系统频率504MHz，系统负载阈值80，当前系统负载60

索引列表是 

252 504 816 1008 1200 1272 1416

由系统负载算出新频率（目标频率）是

504* 60% ，介于252和504之间，取252MHz

调频和调压，就是动态调压调频DVFS

频率确定后，对应的arm和logic电压也就确定

如果是升频，先升压，后升频

如果是降频，先降频，后降压