linux启动,挑战Linux启动速度的优化极限

如果您有疑问或建议,请进入技术讨论区交流 >>>
每减少一秒钟Linux启动(设备复位)时间,对可靠性都是一个明显的提升。今天我们要做的是:挑战Linux启动速度的优化极限,目标启动时间是:2秒。
言归正传,如何着手对Linux的启动时间进行优化呢?
CELF(The Consumer Electronics Linux Forum)论坛为我们指引了一个方向。
(1)首先是对Linux启动过程的跟踪和分析,生成详细的启动时间报告。
较为简单可行的方式是通过PrintkTime功能为启动过程的所有内核信息增加时间戳,便于汇总分析。PrintkTime最早为CELF所提供的一个内核补丁,在后来的Kernel 2.6.11版本中正式纳入标准内核。所以大家可能在新版本的内核中直接启用该功能。如果你的Linux内核因为某些原因不能更新为2.6.11之后的版本,那么可以参考CELF提供的方法修改或直接下载它们提供的补丁:http://tree.celinuxforum.org/CelfPubWiki/PrintkTimes
开启PrintkTime功能的方法很简单,只需在内核启动参数中增加“time”即可。当然,你也可以选择在编译内核时直接指定“Kernel hacking”中的“Show timing information _disibledevent=> 上面分析结果中的 4、5 两项都是SMP初始化的一部分,因此不在CELF研究的范畴(或许将来会有采用多核的MP4出现?……),只能自力更生了。研究了一下SMP的初始化代码,发现“Migration Cost”其实也可以像“Calibrating Delay”采用预置的方式跳过校准时间。方法类似,最后在内核启动参数中增加:
migration_cost=4000,4000
而Intel的网卡驱动初始化优化起来就比较麻烦了,虽然也是开源,但读硬件驱动完全不比读一般的C代码,况且建立在如此肤浅理解基础上的“优化”修改也实在难保万全。基于可靠性的考虑,我最终在两次尝试均告失败后放弃了这一条路。那么,换一个思维角度,可以借鉴CELF在 “ParallelRCScripts”方案中的“并行初始化”思想,将网卡驱动独立编译为模块,放在初始化脚本中与其它模块和应用同步加载,从而消除 Probe阻塞对启动时间的影响。考虑到应用初始化也可能使用到网络,而在我们的实际硬件环境中,只有eth0是供应用使用的,因此需要将第一个网口初始化的0.3s时间计算在内。
除了在我的方案中所遇到的上述各优化点,CELF还提出了一些你可能会感兴趣的有特定针对性的专项优化,如:
ShortIDEDelays - 缩短IDE探测时长(我的应用场景中不包含硬盘,所以用不上)
KernelXIP - 直接在ROM或Flash中运行内核(考虑到兼容性因素,未采用)
IDENoProbe - 跳过未连接设备的IDE口
OptimizeRCScripts - 优化initrd中的linuxrc脚本(我采用了BusyBox更简洁的linuxrc)
以及其它一些尚处于设想阶段的优化方案,感兴趣的朋友可以访问CELF Developer Wiki了解详情。
(4)优化结果
经过上述专项优化,以及对inittab、rcS脚本的冗余裁减,整个Linux内核的启动时间从优化前的 6.188s 下降到了最终的 2.016s,如果不包含eth0的初始化,则仅需 1.708s(eth0初始化可以和系统中间件及部分应用加载并行),基本达到了既定目标。与Kexec配合,可以大大降低软件故障导致的复位时间,有效的提升了产品的可靠性。
大家如果对内核启动时间的优化还有什么建议或疑惑,都欢迎与我探讨。:)
Tags:  linux启动

延伸阅读

最新评论

发表评论