如何利用dmesg优化启动速度

用 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 特征

定位到耗时阶段后，下一步是判断原因。下面这些是常见的“元凶”，它们在 dmesg 和火焰图里都有明显的特征。

• 驱动初始化过慢或同步等待：在 initcall 火焰图中表现为异常长的条块；在 dmesg 日志里，则能看到某个驱动的 probe 函数前后，有很长一段时间没有任何日志输出，仿佛系统“卡住”了。
• 压缩/解压内核耗时：这通常发生在启动早期。如果发现早期日志之间的时间间隔特别大，很可能时间都花在解压内核上了。试试更换内核压缩方式，比如从 GZIP 换成 LZO，对比一下启动时间，往往有惊喜。
• loops_per_jiffy 校准：如果内核没有预设这个值，启动时就会进行校准计算。在 dmesg 里你会看到 “Calibrating delay loop” 相关的信息。一个简单的优化是，在 cmdline 里直接加入预设值，比如 lpj=240000，就能跳过这个校准过程。
• PCI/USB 枚举与 BIOS 交接问题：硬件枚举有时会出岔子。如果 dmesg 里出现了 “EHCI/XHCI BIOS handoff failed” 这类字样，通常意味着硬件和固件之间发生了数百毫秒甚至秒级的等待，启动速度自然被拖慢。
• 控制台输出过多：大量 printk 刷屏会严重拖慢控制台的刷新速度。一个折中的办法是，结合 quiet 参数降低控制台输出量，但同时保留时间戳（printk.time=1），这样既不影响分析，又能提升速度。
• initramfs/initrd 体积大、初始化脚本串行：如果 dmesg 显示在 initramfs 阶段停留时间过长，那就要检查它的内容了。是不是塞了太多不必要的内核模块？初始化脚本是不是在串行执行一些可以并行的工作？精简和优化这里，效果立竿见影。

以上这些现象，在日志和图表中都有迹可循。学会按图索骥，优化方向就不会跑偏。

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

诊断完毕，就该动手优化了。根据上面找到的根因，可以采取以下具体动作，形成一个完整的优化闭环。

• 裁剪与按需编译：这是最根本的一步。关掉产品用不到的功能和驱动（设为模块或直接移除），既能减小内核镜像体积，又能减少需要初始化的项目。必要时，可以对内核进行深度裁剪。
• 调整内核压缩与加载方式：对比 LZO、GZIP 等不同压缩算法的压缩比和解压耗时，选择最适合你硬件的那一个。如果由 U-Boot 负责解压，还可以调整内核加载地址，避免自解压时发生耗时的内存搬移。
• 预设 lpj：在 dmesg 确认系统跳过了校准（显示 “Calibrating delay loop(skipped)”），或者拿到校准后的具体数值后，直接将这个值写入 cmdline（如 lpj=240000），一劳永逸地省去每次启动的校准时间。
• 并行化与延后加载：把非关键、耗时的驱动从内核“内置”改为“模块”，让它们在用户态按需加载。甚至可以将一些驱动的加载时机，延后到主要的系统服务启动之后，让用户先“用起来”。
• 优化 initramfs/initrd：大力精简，移除不必要的内核模块和脚本。检查并优化 init 脚本的执行逻辑，减少串行等待。调整 initramfs 的生成策略，比如使用 modules=dep 只包含依赖的模块。
• 降低控制台输出：在保留 printk.time=1 用于分析的前提下，使用 quiet 参数大幅减少控制台刷屏，这对提升实测的启动速度有直接帮助。
• U-Boot 配合：别忽略了引导程序。关闭 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” （聚焦关键总线/设备枚举）
• 判读要点
  • 在火焰图中，死死盯住那些最长的“条形块”，它们就是最主要的优化目标。
  • 在日志里搜索 “Calibrating delay loop”，判断是否可以通过预设 lpj 来优化。
  • 留意 “BIOS handoff failed” 这类关于 PCI/USB 交接的提示，它们往往是隐藏的耗时大户。
  • 对比开启和关闭 quiet 参数时，控制台输出的数据量变化，评估输出带来的开销。

这套命令组合拳，覆盖了从数据采集、问题筛选到结果判读的关键环节。配合火焰图进行可视化分析，你就能高效地完成从定位到优化的整个闭环。