如何通过dmesg优化Linux启动速度

用 dmesg 定位瓶颈并用三步完成优化

一、建立可度量的时间基线

• 在内核配置中开启时间戳，便于量化每一阶段的耗时：
  • 配置项：CONFIG_PRINTK_TIME=y（内核打印带时间戳）
  • 可选：CONFIG_BOOT_TRACER=y（配合 initcall 跟踪）
• 引导参数建议一次性加入，便于后续分析：
  • printk.time=1（强制打印时间戳）
  • initcall_debug（打印每个 initcall 的开始/结束与耗时）
  • quiet（减少控制台输出，实测可缩短启动时间）
• 采集日志并生成火焰图/时间线：
  • 采集：dmesg > boot.log
  • 图形化：cat boot.log | perl scripts/bootgraph.pl > boot.svg（内核源码 scripts/ 目录）
• 判定基准：以内核日志中首次出现 “Freeing unused kernel memory” 作为内核启动完成的稳定标记，便于对比优化前后差异。

二、用 dmesg 快速定位常见瓶颈

• 驱动与设备初始化过长
  • 现象：大量 initcall 返回时间偏大，或特定驱动（如 omap8250_platform_driver_init、cpsw_driver_init）耗时明显。
  • 处理：裁剪未使用的驱动、合并/延后非关键外设初始化、关闭不使用的 SoC 功能节点。
• 存储与文件系统挂载延迟
  • 现象：两行日志时间戳间隔很大，或挂载失败/重试；分区调整后启动显著变慢。
  • 处理：核对 /etc/fstab 的 UUID/设备名 是否正确；对网络/不可达挂载加 nofail、x-systemd.device-timeout=5；必要时修正 initramfs 中的 resume/swap UUID 并更新（如 Debian 系执行 update-initramfs -u）。
• 校准与日志开销
  • 现象：启动早期出现 “Calibrating delay loop…”，或控制台大量输出。
  • 处理：从一次启动日志中读取 lpj 值（如 lpj=4980736），在后续启动参数中预设 lpj=4980736 以跳过校准；必要时使用 quiet 降低控制台输出带来的同步等待。
• 并行度与 SMP 初始化
  • 现象：单核平台仍启用 SMP，初始化开销偏大。
  • 处理：单核场景可关闭 CONFIG_SMP 以缩短启动时间（注意评估运行时影响）。

三、把 dmesg 线索转化为具体优化动作

• 内核配置裁剪
  • 关闭不需要的总线/控制器/接口（如 USB 客户端/DFU、未用外设）、移除 Tracers、精简驱动，减小镜像与初始化工作量。
• 启动参数固化与收敛
  • 固化 lpj 值；保留 initcall_debug 仅用于阶段性分析，常态使用 quiet 降低 I/O 与同步开销；必要时关闭 CONFIG_SMP（单核场景）。
• 根文件系统和 initramfs
  • 场景允许时，将精简后的 rootfs 直接作为 initramfs 拼接进内核，减少块设备与文件系统早期探测；权衡镜像变大带来的解压时间。
• 用户空间的协同优化（与 dmesg 结论联动）
  • 若 dmesg 显示存储/挂载正常但整体仍慢，用 systemd-analyze blame/critical-chain 检查服务链；对 NetworkManager-wait-online.service、bluetooth.service、cups.service、ModemManager.service 等非必要项执行 disable/mask；对网络非强依赖服务将 After=network-online.target 调整为 After=network.target；将 apt-daily.service 改为 timer 触发，避免开机即更新。

四、验证与回退的闭环流程

• 每次只变更一个变量（如仅加 lpj、仅裁剪一项驱动、仅关闭一个服务），重启后用同一方法采集 dmesg 并对比 “Freeing unused kernel memory” 时间戳或 boot.svg 火焰图，确认收益与副作用。
• 若优化引入功能缺失或不稳定，回退对应配置/参数，再尝试其他路径；保留一份 “baseline” 日志与配置，便于随时比对。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！