如何利用dmesg优化启动速度

用 dmesg 定位瓶颈并落地优化

一、快速定位耗时阶段

启用内核时间信息：在内核配置中打开 CONFIG_PRINTK_TIME=y，或在启动命令行加入 printk.time=1，让每条内核日志前带有时间戳，便于计算阶段耗时。
打开 initcall 级别耗时：在命令行加入 initcall_debug=1，启动时会打印每个 initcall 的开始与结束时间、耗时。
生成火焰图：启动完成后执行
dmesg | perl $(KERNEL_DIR)/scripts/bootgraph.pl > boot.svg
用浏览器打开 boot.svg，一眼看出哪些 initcall/阶段最耗时。
串口时间戳辅助：若需对齐 U-Boot 与内核时序，可用 grabserial 抓取串口日志并自动加时间戳，例如
grabserial -d /dev/ttyUSB0 -t -m “Starting kernel”
以上步骤能快速把“时间黑洞”定位到具体驱动或初始化阶段，为后续优化提供明确靶心。

二、常见高耗时根因与 dmesg 特征

驱动初始化过慢或同步等待：initcall 火焰图中长条块；dmesg 中可见某驱动 probe 前后长时间无日志。
压缩/解压内核耗时：启动早期日志间隔较大；可通过更换 内核压缩方式（如 LZO/GZIP）并实测对比启动时间。
loops_per_jiffy 校准：若未预设，会看到 “Calibrating delay loop” 计算过程；可在 cmdline 加入 lpj=240000（示例值）跳过校准。
PCI/USB 枚举与 BIOS 交接问题：dmesg 出现 “EHCI/XHCI BIOS handoff failed” 等字样，往往伴随数百毫秒甚至秒级等待。
控制台输出过多：大量 printk 会拖慢控制台刷新；可结合 quiet 降低控制台输出，同时保留时间戳用于分析。
initramfs/initrd 体积大、初始化脚本串行：dmesg 中 initramfs 阶段时间长；可减少不必要的 ko、优化 init 脚本并行度。
以上现象在 dmesg 与火焰图中均有明显特征，按图索骥即可落地优化。

三、从 dmesg 到优化的闭环动作

裁剪与按需编译：关闭产品不需要的功能与驱动（设为 module 或移除），既减小镜像又减少初始化项；必要时做内核裁剪。
调整内核压缩与加载方式：对比 LZO/GZIP 等压缩比与解压耗时；若由 U-Boot 解压，可调整加载地址避免自解压时的内存搬移。
预设 lpj：在 dmesg 确认 “Calibrating delay loop(skipped)” 或拿到 lpj 数值后，写入 cmdline（如 lpj=240000）以省去校准。
并行化与延后加载：对非关键驱动改为 module 并在用户态按需加载；将耗时驱动从内核内置改为模块，必要时延后到系统服务启动后再加载。
优化 initramfs/initrd：精简不必要的 ko 与脚本，减少 init 阶段的串行等待；必要时调整 initramfs 生成策略（如 modules=dep）。
降低控制台输出：在保留 printk.time=1 的前提下使用 quiet 减少控制台刷屏时间，避免影响实测。
U-Boot 配合：关闭不必要的功能与输出、缩短或去除 bootdelay，减少引导阶段等待。
这些动作均源自 dmesg/initcall_debug 的指认结果，按“影响最大、代价最小”的顺序实施，收益通常立竿见影。

四、实操命令清单与判读要点

采集与可视化
- dmesg -T > boot.log（人类可读时间戳）
- dmesg | perl scripts/bootgraph.pl > boot.svg（火焰图）
- 串口对齐：grabserial -d /dev/ttyUSB0 -t -m “Starting kernel”
快速筛选
- dmesg | grep -i “error|fail|warn”
- dmesg | grep -E “usb|pci|ehci|xhci|mmc|sd”
判读要点
- 关注火焰图中“长条”initcall；
- 查找 “Calibrating delay loop” 是否可 lpj 预设；
- 留意 “BIOS handoff failed” 等 PCI/USB 交接提示；
- 对比开启/关闭 quiet 时的控制台输出量变化。
  以上命令覆盖从采集、筛选到判读的关键环节，配合火焰图即可高效闭环优化。

最新问答