linux电源管理的一些梳理

linux电源管理的一些梳理,第1张

由于项目产品需要过能源之星30,所以最近做了一些电源管理低功耗方面的工作,抽个时间正好梳理一下。

其实Linux 电源管理非常复杂,牵扯到很多方面,比如系统级的待机、频率电压变换、系统空闲时的处理以及每个设备驱动对于系统待机的支持和每个设备的运行时电源管理,可以说和系统中的每个设备驱动也都息息相关。

在Linux内核上有如下的框架支持:

1 CPU 在运行时根据系统负载进行动态电压和频率变换的CPUFreq ;
2 CPU 在系统空闲时根据空闲的情况进行低功耗模式的CPUIdle ;

3 多核系统下CPU 的热插拔支持 ;

4 系统和设备对于延迟的特别需求而提出申请的PMQoS,它会作用于CPUIdle 的具体策略 ;

5 设备驱动针对系统Suspend to RAM/Disk 的一系列入口函数 ;

6 SoC 进入suspend 状态、SDRAM 自刷新的入口 ;

7 设备的runtime(运行时)动态电源管理,根据使用情况动态开关设备 ;

8 底层的时钟、稳压器、频率/电压表(OPP 模块完成)支撑;

Linux电源管理中主要使用的技术包括:
1、CPUFreq : 即DVFS(Dynamic voltage and frequency scaling),即动态电压频率调整。在系统运行时根据系统负载动态调节;

2、DEVFreq:CPUFreq只针对CPU做动态电压频率调节,而devfreq可以对设备,如DRAM,GPU等做动态电压频率调节;

3、CPUIdle:CPU在系统空闲时根据空闲的情况进行低功耗模式,比如C0--C3四个状态对应不同的低功耗策略;

4、CPUHotplug:多核系统下CPU的热插拔支持;

5、PM QOS:主要作用于cpuidle的具体策略,是针对系统和设备对于延迟的特别需求而提出的;

6、SUSPEND:主要有suspend to ram和suspend to disk两种,suspend to ram主要是挂起各设备,并使dram进入自刷新,而suspend to disk就干脆把dram也关掉,直接把状态保存到disk;

7、RUNTIME PM:设备的runtime(运行时)动态电源管理,根据使用情况动态开关设备;

8、Regulator:用于调节CPU等模块的电压和电流值;

9、OPP:可以使SOCs或者Devices正常工作的电压和频率组合。内核提供这一个Layer,是为了在众多的电压和频率组合中,筛选出一些相对固定的组合,从而使事情变得更为简单一些;

10、Thermal:温控管理。

电源管理相关源码在内核树中主要分布于:

kernel/power/

drivers/power/

drivers/base/power/

drivers/cpuidle/

drivers/cpufreq/

drivers/devfreq/

include/linux/power_supplyh

include/linux/cpuidleh

include/linux/cpufreqh

include/linux/cpu_pmh

include/linux/deviceh

include/linux/pmh

include/linux/pm domainh

include/linux/pm runtimeh

include/linux/pm wakeuph

include/linux/suspendh

11 top

12 vmstat

r 表示可运行进程数目,数据大致相符;而b表示的是 uninterruptible 睡眠的进程数目;swpd 表示使用到的虚拟内存数量,跟 top-Swap-used 的数值是一个含义,而如手册所说,通常情况下 buffers 数目要比 cached Mem 小的多,buffers 一般20M这么个数量级;io 域的 bi、bo 表明每秒钟向磁盘接收和发送的块数目(blocks/s);system 域的 in 表明每秒钟的系统中断数(包括时钟中断),cs表明因为进程切换导致上下文切换的数目。

说到这里,想到以前很多人纠结编译 linux kernel 的时候 -j 参数究竟是 CPU Core 还是 CPU Core+1?通过上面修改 -j 参数值编译 boost 和 linux kernel 的同时开启 vmstat 监控,发现两种情况下 context switch 基本没有变化,且也只有显著增加 -j 值后 context switch 才会有显著的增加,看来不必过于纠结这个参数了,虽然具体编译时间长度我还没有测试。资料说如果不是在系统启动或者 benchmark 的状态,参数 context switch>100000 程序肯定有问题。

13 pidstat

如果想对某个进程进行全面具体的追踪,没有什么比 pidstat 更合适的了——栈空间、缺页情况、主被动切换等信息尽收眼底。这个命令最有用的参数是-t,可以将进程中各个线程的详细信息罗列出来。

-r: 显示缺页错误和内存使用状况,缺页错误是程序需要访问映射在虚拟内存空间中但是还尚未被加载到物理内存中的一个分页,缺页错误两个主要类型是

-s:栈使用状况,包括 StkSize 为线程保留的栈空间,以及 StkRef 实际使用的栈空间。使用ulimit -s发现CentOS 6x上面默认栈空间是10240K,而 CentOS 7x、Ubuntu系列默认栈空间大小为8196K

14 其他

while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done

21 iostat

31 netstat

➜ ~ netstat -antp #列出所有TCP的连接

➜ ~ netstat -nltp #列出本地所有TCP侦听套接字,不要加-a参数

32 sar

33 tcpdump

Linux *** 作系统主要有以下三大应用领域:

1Linux作为企业级服务器的应用

Linux系统可以为企业架构>

2嵌入式Linux系统应用领域

由于Linux系统开放源代码,功能强大、可靠、稳定性强、灵活而且具有极大的伸缩性,再加上它广泛支持大量的微处理体系结构、硬件设备、图形支持和通信协议,因此,在嵌入式应用的领域里,从因特网设备(路由器、交换机、防火墙,负载均衡器)到专用的控制系统(自动售货机,手机,PDA,各种家用电器),LINUX *** 作系统都有很广阔的应用市场。特别是经过这几年的发展,它已经成功地跻身于主流嵌入式开发平台。

3个人桌面Linux应用领域

所谓个人桌面系统,其实就是我们在办公室使用的个人计算机系统,例如:Windowsxp、windows7、Mac等。Linux系统在这方面的支持也已经非常好了,完全可以满足日常的办公及家长需求。

1、性能

当公司网站的流量和内容不是很大时,Linux服务器的性能比Windows好很多,Linux服务器占用资源更少。

2、稳定性

Windows系统是使用最广泛的 *** 作系统,受到了很多黑客的攻击,相应的系统安全漏洞也会比较多。Linux是一个多用户进程系统。Linux可以同时处理大量正在运行的进程,远远超过Windows。

3、安全性

这两个系统都有各自的安全技术。Linux开源软件开发方法帮助暴露错误并以每个人的智慧解决问题。各种补丁更新很快。在这一点上,Linux不像Windows那样严格。并且Linux远程过程调用被限制使用。

4、性价比

在性价比方面,Linux服务器优势明显。Linux作为资源管理和 *** 作系统,是开源且免费的。正版Windows系统是收费的,因为Linux服务器比Windows服务器好。

两者没有可比较性,服务器配置低的情况下Linux负载更低性能更好,windows系统本身则比较占用硬件配置,从安全性角度Linux相对更安全,Linux系统开源修复漏洞较快,windows则需要微软官方修复漏洞补丁,运行NET应用则只能使用windows服务器系统,至于怎么选择首先考虑自己的业务适合什么运行环境,两则都可以运行的情况下选择需要看服务器运维管理员擅长何种 *** 作系统运维管理。

和信云桌面的3V架构都可以部署在linux上,已经多年稳定运行。可以兼容CentOS、Ubuntu等国外linux,也兼容麒麟、UOS等主流国产化服务器 *** 作系统。终端也兼容国内外linux。

在Linux系统中,CPU利用率的最大值是100%。但是,当一个进程使用了多个CPU核心时,它的CPU利用率可能会显示为超过100%的数字。例如,如果一个进程使用了4个CPU核心,则它的CPU利用率可能会显示为400%。如果一个进程使用了8个CPU核心,则它的CPU利用率可能会显示为800%。
这种情况通常发生在多线程程序中,每个线程都在一个单独的CPU核心上运行。因此,如果一个进程有多个线程并且每个线程都在一个单独的CPU核心上运行,则它的CPU利用率可能会显示为超过100%的数字。
需要注意的是,这种超过100%的CPU利用率并不表示真正的CPU使用率超过了100%,而是表示该进程利用了多个CPU核心。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/12859585.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-28
下一篇 2023-05-28

发表评论

登录后才能评论

评论列表(0条)

保存