linux动态频率分析.doc

linux动态频率分析.doclinux低功耗研究也冇一段时间了,基木把低功耗的实现方式想清楚了(主要分成机制和策略),这段时间的工作主要在机制上。暂时想实现的主要的机制有:cpu级,设备驳动级,系统平台级。管理颗粒度不断递增,形成三驾马车齐驱的形势。卬U级:主要实现比较容易的在系统处于目标在于频繁发生、更高粒度的电源状态改变,主要的实现方式为idle,包括今天的主要想讲的动态主频。设备驱动级:主要实现对单个设备驱动的管理(suspend,resume等),通过系统监测将闲置的设备,通过从用户态对sys文件目录动态进行单个驶动设备的管理,迸于省电模式。系统平台级:F1标在于管理较大的、非常见的重大电源状态改变,用于减少产品设备在长时间的空闲Z后,减少电源消耗。主要实现方式是依托linux内核所支持的apm技术,实现整个系统的睡眠/恢复(sleep)这儿个层次其实并不是相互独立的,都是相互交义的,比如系统平台级的睡眠不可避免会涉及到cpu的sleep模式和设备驱动的挂起,而动态主频的实现除了cpu本身的支持也需要外围驱动随着主频变化做出和应的适应活动。因此这里的分级只是一•种粗范围的,逻辑上的分层。前段时间还调研了一下IBM和MontaVista搞得那套DPM(DynamicPowerManagement)机制,看了不少论文和观点,总的感觉就是太过复杂而且也不是很实用,感觉噱头大过实际功效,(因此这套机制始终还不能进入内核的mainline),言归正传,还是重点讲述下cpufreq技术。为什么要卬ufreq?关于要不要实现卬ufreq技术,我也纠结过,一个原因是:当时对内核如何提供这么一套动态变频的机制还不了解,只觉得应该非常麻烦,因为涉及到外围驱动的参数更新,另外一个原因是:在SEP4020这种体量的处理器上跑linux,即使运行在最高频率时的处理能力可能也不是很富余,我再给它降频还冇没冇意义?挣扎Z后还是觉得要实现它,我也给自己列了这么几条原因:n 虽然cpu在板级屮已不是主要的耗电源,但是仍然占着举足轻重的位直,功耗机制到最后就是儿毫安儿毫安的扣了,降频肯定能在一定程序上节约功耗那我为什么不采用?n 细化功耗管理的颗粒度,为应用程序提供更多的功耗节省机制n 对普通的应用,系统可以运行在维持平台运作的最低频率,在有处理任务时,变频机制会自动切换到合适的高主频,并且在任务结束时重冋省电的低主频,这样就解决了我之前的第二个疑惑。SEP4020在运行在88M时板级功耗为:222mA? SEP4020在运行在56M时板级功耗为:190mA,降低14%? SEP4020在运行在32M时板级功耗为:160mA,降低28%n 实现的一些工作是我们一宜需要去做但是一宜没有动力做的? 变频会涉及到大屋模块的参数的重新配置,作为cpu原厂,我们需要把这些参数彻底掌握? 对这些参数的充分理解,能对现有系统进行优化,提升整体系统的效率,比如使用发现一些参数还是太过保^(sdram,nand),我们的通用配置在系统降为32M时仍能止常工作。n 可行性论证没有问题:偶然看到armkiller同志捉供的nand驱动代码屮有变频的实现(这里非常感谢armkiller),网上这方而的文章很少,于是翻阅了linux内核源码中自带的/documentation/cpufreq后,对这种机制大概有一定的了解(linu