如何利用dmesg优化系统启动速度

用 dmesg 定位瓶颈并用针对性优化缩短启动时间

系统启动慢，问题到底出在哪？很多时候，答案就藏在 kernel 的日志里。与其靠感觉盲目调优，不如让数据说话——用 dmesg 这把手术刀，精准定位耗时环节，再对症下药。

一、快速定位瓶颈

先说说怎么拿到那些带时间戳的内核日志，然后盯着异常和耗时的阶段看。

• 查看完整日志：dmesg -T | less
• 关注错误与警告：dmesg -T | egrep -i "error|fail|warn|timeout"
• 按设备/子系统过滤：dmesg -T | grep -i "usb|pci|ahci|nvme|mmc"
• 观察挂载与文件系统：dmesg -T | grep -i "mount|fsck|EXT4-fs"
• 跟踪模块加载：dmesg -T | grep -i "module|insmod"
• 如果日志被轮转覆盖了，还有后手：sudo journalctl -k -b -e 可以查看持久化的内核日志。

那么，发现了长时静默段怎么办？相邻两条日志的时间戳如果差值比较大，往往就是驱动探测、设备初始化或者 I/O 在“磨洋工”。这时候，结合关键字（比如 usb、pci、block、scsi、mmc、nvme）就能快速锁定嫌疑模块或硬件路径。

二、把耗时环节做成“可视化时间线”

光看文本还不够直观，得把它画出来。

• 首先，在内核命令行加入两个参数：initcall_debug printk.time=1 quiet。initcall_debug 会打印每个 initcall 的开始、结束和耗时；printk.time=1 显示时间戳；quiet 用来减少控制台输出带来的额外开销（调试阶段可以先不加 quiet）。
• 保存日志并生成时间图：

  dmesg > boot.log
  perl scripts/bootgraph.pl boot.log > boot.svg

  用浏览器打开生成的 boot.svg，耗时最长的 initcall 一眼就能看出来——色块越长越扎眼。对着它，就可以决定是“裁剪”、“延后”还是“并行化”。
• 如果需要更细粒度的观测，可以配合串口抓时序（比如 grabserial），把外部观测和内核日志对齐起来看。

三、常见高影响问题与 dmesg 线索

控制台输出过慢
线索：大量串口输出期间，时间线明显被拉长。
优化：内核参数里加上 quiet；必要时降低打印级别（比如 loglevel=）。只有在确认问题排干净之后，再做“终极”静默（比如关闭 CONFIG_PRINTK），否则会影响后续排障。

驱动探测与初始化过慢
线索：initcall 时间图里，某些驱动 initcall 持续数百毫秒甚至秒级；dmesg 中相关设备探测信息扎堆出现。
优化：把非关键驱动编译成模块，在用户空间按需加载；对可延后初始化的驱动，让它返回 -EPROBE_DEFER；对必须内置的驱动，则要精简它的探测逻辑和依赖关系。

PCI/USB 控制器 BIOS 交接失败或延迟
线索：dmesg 里出现 “EHCI/XHCI BIOS handoff failed (BIOS bug?)” 之类的字样，随后跟着明显的等待。
优化：升级 BIOS/UEFI；在内核参数中尝试用 usbcore.quirks=… 绕过这个问题；必要时将相关控制器驱动改为模块，延后加载，让图形或动画先跑起来。

存储与文件系统挂载慢
线索：dmesg 中 “Waiting for /dev/… to be ready…”、“EXT4-fs (recover)”、“fsck” 等阶段耗时较长。
优化：确保存储健康、分区对齐；优化 /etc/fstab（比如加上 noatime、data=ordered 等选项）；必要时将关键文件系统检查改为异步或后台执行（视发行版支持）；在嵌入式或定制场景下，可以评估精简 initramfs 甚至做拼接策略。

内核与 initramfs 过大，解压和初始化慢
线索：dmesg 早期阶段占用时间长，bootgraph 显示大量 initcall 集中在核心子系统。
优化：裁剪未使用的驱动和调试选项；尝试更优的压缩算法（gzip/lzo 在不同平台表现不同）；把非必要功能编译为模块；在资源允许的情况下，可以考虑把 Kernel 和 initramfs 拼接起来，省去块设备和文件系统的初始化步骤（不过需要评估解压开销和兼容性）。

四、从内核到用户空间的闭环优化

内核与引导
裁剪与配置：关闭用不到的驱动、子系统和调试功能（比如 Tracers、CONFIG_PRINTK/CONFIG_KALLSYMS 等，只有在确认没有排障需求时才关）；选择合适的内存分配器（SLAB 还是 SLUB，得实测才能决定）；尝试更优的内核压缩算法；必要时预设 lpj 值，避免启动时做校准。
引导器：缩短或移除 bootdelay；精简功能和输出；在条件允许时，采用 SPL/U-Boot Falcon Mode 直接加载内核，减少阶段切换的开销。

用户空间
并行与按需：结合 systemd-analyze blame/plot 找出用户空间的长任务，能并行的就并行，能按需的就延后；非必要的服务直接 disable 或 mask。
图形会话：减少登录后同步执行的重型组件（比如蓝牙、截图、输入法、托盘应用等），对不必要项设置 X-GNOME-autostart-Delay，或者直接移出自启动目录。
日志开销：如果不需要持久化内核日志，可以在 /etc/systemd/journald.conf 中将 Storage 设为 none（注意这会影响后续排障）。

五、可复用的操作流程清单

1. 采集日志：dmesg -T > boot.log；必要时用 journalctl -k -b -e 补充持久化日志。
2. 初筛问题：grep -i "error|fail|warn|timeout" boot.log；然后按设备类目二次过滤（usb/pci/nvme/block/fs）。
3. 生成时间图：perl scripts/bootgraph.pl boot.log > boot.svg，定位最长的 initcall。
4. 实施优化（按影响度从高到低）：
   • 控制台输出：加 quiet；必要时降低打印级别。
   • 驱动：非关键驱动改模块并延后加载；对可延后者返回 -EPROBE_DEFER。
   • 硬件交接：升级 BIOS；尝试 usbcore.quirks；必要时延后相关控制器驱动。
   • 存储/文件系统：优化 fstab 挂载选项；必要时异步/后台 fsck；评估 initramfs 精简与拼接。
   • 内核/引导：裁剪配置、选优压缩、预设 lpj；缩短/优化引导器流程。
5. 复测与回归：对比 boot.log 与 boot.svg，确认关键阶段耗时明显下降；保留关键日志，为后续排障留一手。