1. 从一次待机唤醒失败说起hibernation 到底在做什么前阵子调一块嵌入式板子的低功耗遇到一个很典型的现象系统进入休眠之后按电源键能亮屏但跑了一晚上的数据全丢了进程状态回到刚开机那会儿。当时第一反应是电源域没配好查了半天寄存器才发现问题出在休眠流程走的是 hibernation 而不是 suspend-to-RAM。这俩名字看着像实际干的事差得远——前者是把整个内存快照写到磁盘再断电后者只是把外设挂起、内存继续供电。搞混了行为自然对不上。这篇就围绕 Linux 内核功耗子系统里的 hibernation 过程做一次完整梳理。它属于内核电源管理Power Management里最重的一环涉及dev_pm_ops回调、快照生成、镜像写入、原子恢复等多个阶段横跨kernel/power/、drivers/base/power/以及各设备驱动。适合谁看如果你在做嵌入式低功耗、笔记本待机优化、或者单纯想搞明白/sys/power/state里写disk之后内核到底跑了哪些代码这篇能给你一条清晰的路径。我会按“整体设计—核心细节—实操过程—问题排查”的顺序展开中间穿插我自己踩过的坑和参数计算尽量让刚接触功耗子系统的同学也能跟下来。需要先明确一个概念边界hibernation 在 Linux 里也叫 suspend-to-diskSTD目标是把运行时的内存内容完整保存到持久化存储然后整机断电下次上电时再从存储读回镜像恢复到断电前的状态。它和 suspend-to-idle、suspend-to-RAM 最大的区别在于“断电”这一步所以对存储、对镜像完整性、对恢复阶段的内存布局都有额外要求。理解了这一点后面所有流程的设计动机就都能串起来了。2. hibernation 整体设计与思路拆解2.1 为什么要有 hibernation省电与状态保持的平衡suspend-to-RAM 的省电效果取决于内存是否继续刷新。DDR 在自刷新模式下仍然要消耗几十到几百毫安对于靠电池撑几周甚至几个月的设备来说这个底电流是致命的。hibernation 直接把电断掉静态功耗趋近于零代价是恢复时要重新走一遍内存初始化和镜像解压耗时从几百毫秒到几秒不等。这个取舍决定了它的适用场景长时间待机的移动设备、需要跨天保持会话的工控终端、以及那些“关机但不想丢现场”的场合。反过来如果你追求的是毫秒级唤醒那 hibernation 就不合适应该走 suspend-to-idle 或者 runtime PM。从内核设计角度看hibernation 要解决三个核心矛盾。第一内存快照必须一致不能一边改一边存所以需要冻结进程和内核线程第二镜像要能安全落盘写的过程中不能有新的脏页干扰第三恢复阶段内存管理还没完全就绪得用一套特殊的“原子恢复”路径先把关键结构还原。这三条贯穿了整个 hibernation 的实现。2.2 快照式休眠 vs 挂起式休眠两条技术路线的取舍内核里 hibernation 的实现其实有两条路线一条是快照式snapshot-based另一条是早年讨论过的挂起式suspend-based。现在主线用的是快照式也就是先把内存内容复制出来再决定写到哪。快照式的好处是逻辑清晰生成镜像、写镜像、断电三步解耦。坏处是需要额外内存来存放快照通常要求可用内存的 50% 左右。这个数字不是拍脑袋来的——镜像本身要占一份压缩过程中的临时缓冲、页表备份、以及恢复时用于“原地解压”的空间又要占一份所以内核默认会检查可用内存是否足够不够就直接拒绝进入 hibernation。挂起式路线当年想的是“边挂起边写盘”省掉一份快照内存但实现复杂度极高要在设备挂起的过程中保证内存不被改动几乎做不到。所以主线最终选择了快照式牺牲内存换正确性。这个取舍在嵌入式场景里尤其要注意因为很多板子内存本来就紧张进 hibernation 之前得先确认/sys/power/image_size和实际可用内存的关系。2.3 dev_pm_ops 在休眠流程中的角色定位设备驱动要参与 hibernation靠的是struct dev_pm_ops里的一组回调。这个结构体里和休眠相关的回调主要有freeze/thaw冻结和解冻设备用于生成快照前让设备进入静止状态poweroff/restore断电前和恢复时的回调suspend/resume和 suspend-to-RAM 共用的路径关键点在于hibernation 并不是简单调用suspend而是走freeze这条独立路径。为什么因为suspend的语义是“设备进入低功耗但系统还在跑”而 hibernation 要的是“设备停止活动马上要断电”。两者对设备状态的要求不同混用会出问题。比如某些存储控制器在suspend里会关掉时钟但保留寄存器而 hibernation 需要它彻底静默否则写镜像时可能触发意外中断。dev_pm_ops的回调调用顺序由设备树和dpm_list决定父设备先于子设备冻结恢复时反过来。这个顺序不能乱否则会出现子设备还在访问父设备资源、父设备已经挂起的情况。我在调试时就遇到过 I2C 控制器先于其下的传感器冻结导致传感器 thaw 时总线没恢复读寄存器直接超时。3. 核心细节解析与实操要点3.1 冻结阶段进程、内核线程与设备的协同hibernation 的第一步是冻结用户进程和大部分内核线程。这一步由freeze_processes()触发它会遍历所有任务把用户态进程置为TASK_INTERRUPTIBLE并挂起同时冻结那些标记了PF_NOFREEZE之外的内核线程。为什么要冻结因为快照要求内存状态一致。如果一边生成镜像一边有进程在改页存下来的就是残缺状态恢复后必然出错。冻结之后内核进入一个相对静止的窗口只有少数关键线程比如负责写盘的 kthread还在跑。设备冻结紧随其后走的是dpm_suspend()里的freeze回调。这里有个细节freeze回调里不能睡眠太久也不能申请大块内存因为此时系统已经接近静止内存分配器可能已经受限。我见过有驱动在freeze里做固件下载结果直接卡死后来改成在prepare阶段提前做完。注意freeze回调里禁止调用可能触发 I/O 的操作尤其是写存储。写镜像的工作由专门的 kthread 在冻结完成后执行驱动不要抢这个活。3.2 快照生成内存镜像的构建与压缩冻结完成后内核调用hibernate()进入快照生成。核心函数是snapshot()它会做几件事分配快照内存、复制页内容、标记哪些页需要保存。快照内存的分配策略值得说一下。内核会尝试分配一块连续的物理内存来存放镜像如果分配不到就退而求其次用分散的页。/sys/power/image_size控制镜像的最大尺寸默认是可用内存的一半。你可以手动调小它来降低内存压力但太小会导致镜像装不下进入 hibernation 直接失败。复制页内容时内核会跳过一些不需要保存的页比如标记为PG_reserved的、以及那些在恢复时会被重新初始化的。这个筛选过程直接影响镜像大小。实测下来一个跑着桌面环境的系统镜像压缩后大概是内存占用的 30% 到 40%压缩算法默认用 LZO可以在内核配置里换成 LZ4 换更快的解压速度。压缩这一步是可选的但强烈建议开。不开压缩的话镜像体积翻倍写盘时间也翻倍而且恢复时读盘更慢。LZO 的压缩比一般但胜在快LZ4 更快压缩比略低。嵌入式场景如果存储带宽紧张优先选 LZ4。3.3 镜像写入与断电存储路径的选择镜像生成后内核通过swsusp_write()把它写到存储。这里有个关键选择写到 swap 分区还是写到普通文件写 swap 分区是传统做法因为 swap 本身就是按页管理的写入效率高而且恢复时可以直接按页读回。写普通文件比如/var/swapfile或者专门的 hibernation 文件更灵活不需要单独划分区但要求文件系统支持并且文件不能有碎片。现在主流发行版默认用 swap 分区嵌入式场景如果存储紧张可以用文件方式。写入过程中内核会记录镜像的元数据包括页表、CPU 状态、以及一个校验和。这些元数据在恢复时用来重建内存布局。写完之后内核调用power_down()走dev_pm_ops的poweroff回调然后执行真正的断电指令。提示写镜像的存储设备本身不能被 hibernation 冻结流程挂起否则写不进去。内核通过pm_suspend_ignore_children之类的标记来保护这类设备驱动作者要确保自己的存储控制器在freeze阶段保持可用。3.4 恢复阶段原子恢复与内存重建恢复是 hibernation 里最微妙的部分。系统上电后bootloader 加载内核内核启动到一定阶段会检测到存在 hibernation 镜像然后走software_resume()路径。这个路径和正常启动不同它不会完整初始化所有子系统而是先做最小化初始化然后调用swsusp_read()把镜像读回内存。读回的过程叫“原子恢复”因为此时内存管理还没完全就绪不能走常规的页分配路径。内核用一套预分配的页表来映射镜像然后逐页还原。还原完成后内核跳回 hibernation 之前的执行点继续跑hibernate()之后的代码。从用户视角看就是“睡了一觉醒来什么都没变”。但底层其实经历了一次完整的断电重启只是内存内容被精确还原了。这里有个容易忽略的点恢复阶段的内存布局必须和休眠前一致否则页表对不上。所以内核在生成镜像时会记录物理页的分布恢复时按同样的分布还原。如果中间有内存被固件占用或者硬件保留区变化恢复就会失败。这也是为什么 hibernation 对硬件配置变化很敏感——换了内存条、改了 BIOS 保留区镜像可能就废了。4. 实操过程与核心环节实现4.1 环境准备与内核配置检查要让 hibernation 跑起来内核配置里得打开几个选项。以 5.x 之后的内核为例make menuconfig里确认CONFIG_HIBERNATIONy CONFIG_PM_SLEEPy CONFIG_PMy CONFIG_SUSPENDy CONFIG_SWAPy CONFIG_LZO_COMPRESSy CONFIG_LZO_DECOMPRESSy如果要用 LZ4把 LZO 换成CONFIG_LZ4_COMPRESS和CONFIG_LZ4_DECOMPRESS。另外CONFIG_PM_DEBUG和CONFIG_PM_TRACE建议打开调试阶段能省不少事。用户空间需要pm-utils或者systemd的支持。systemd 系统上systemctl hibernate会触发整个流程。手动测试的话直接往/sys/power/state写diskecho disk /sys/power/state执行前先确认 swap 空间够大。经验值是 swap 至少等于内存的 1.2 倍因为镜像压缩前可能接近内存大小压缩后虽然小但写入过程中需要缓冲。用free -h看 swap 剩余不够就加。4.2 手动触发一次 hibernation 并观察日志触发之前先把内核日志级别调高方便观察dmesg -n 8 echo 1 /sys/power/pm_debug_messages然后执行echo disk /sys/power/state。正常的话你会看到类似这样的日志序列PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.002 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. PM: Preallocating image memory ... done (allocated 1048576 pages) PM: Allocated 4194304 kbytes PM: Creating hibernation image ... PM: Need to copy 524288 pages PM: Normal pages needed: 524288 13107, available pages: 1048576 PM: Hibernation image created (524288 pages copied) PM: Writing image to disk ... PM: Image written, powering down.关键看两行Need to copy和available pages。前者是实际要保存的页数后者是可用页数。如果前者接近后者说明内存压力大镜像可能装不下。我一般会留 20% 余量。恢复时bootloader 之后的内核日志会显示PM: Checking hibernation image partition /dev/sda2 PM: Image signature found, resuming PM: Loading image data pages ... done PM: Restoring saved image ... done PM: Basic memory bitmaps freed看到Restoring saved image ... done就说明恢复成功了。4.3 参数计算image_size 与 swap 空间的匹配/sys/power/image_size默认是0表示由内核自动决定通常是可用内存的一半。你可以手动设一个值单位是字节。比如设成 2GBecho 2147483648 /sys/power/image_size这个值设太小镜像装不下会直接失败设太大内核会尝试分配过多内存可能触发 OOM。我的经验是设成“实际内存占用 × 1.5”比较稳。怎么看实际内存占用用cat /proc/meminfo里的MemTotal - MemFree - Buffers - Cached估算。swap 空间的计算类似。假设内存 8GB实际占用 4GB压缩比 0.4那镜像大约 1.6GB。swap 至少要 2GB 才够写。但考虑到写入过程中可能有临时缓冲建议 swap 给到 3GB 以上。嵌入式设备如果 swap 紧张可以开 zram 做压缩 swap但 zram 本身占内存要权衡。4.4 用 dev_pm_ops 给自定义驱动加 freeze 回调如果你在写驱动想让设备正确参与 hibernation需要在dev_pm_ops里实现freeze和thaw。一个最小示例static int mydev_freeze(struct device *dev) { struct mydev *d dev_get_drvdata(dev); /* 停止 DMA关闭中断保存寄存器 */ disable_irq(d-irq); mydev_save_regs(d); return 0; } static int mydev_thaw(struct device *dev) { struct mydev *d dev_get_drvdata(dev); mydev_restore_regs(d); enable_irq(d-irq); return 0; } static const struct dev_pm_ops mydev_pm_ops { .freeze mydev_freeze, .thaw mydev_thaw, .poweroff mydev_freeze, .restore mydev_thaw, };注意poweroff和restore通常复用freeze和thaw的逻辑因为断电前和冻结时的设备状态要求一致。但有些设备在poweroff时需要额外操作比如切断外部电源那就单独实现。注意freeze回调里不要调用msleep或者等待队列因为此时系统已经接近静止调度器可能不响应。需要延时的操作放到prepare阶段。5. 常见问题与排查技巧实录5.1 进入 hibernation 直接失败内存不足与 swap 配置最常见的失败是PM: Not enough free memory。原因通常是可用内存不够分配快照。排查步骤看dmesg里available pages和Normal pages needed的差值用free -h确认 swap 是否挂载、剩余多少检查/sys/power/image_size是否被设得过小如果 swap 没挂swapon -a挂上。如果 swap 够但内存碎片严重可以尝试echo 3 /proc/sys/vm/drop_caches释放缓存再触发一次。还有一种情况是PM: Cannot find swap device说明内核没找到可用的 swap 分区。检查/proc/swaps确认 swap 分区在dpm_list里没有被提前挂起。5.2 恢复后设备异常freeze/thaw 不对称的坑恢复后设备不工作十有八九是freeze和thaw不对称。比如freeze里关了时钟thaw里忘了开或者freeze里改了寄存器thaw里没还原。排查方法在freeze和thaw里加dev_info打印对比进入和退出时的寄存器状态。我一般会 dump 关键寄存器的值恢复后逐个比对。如果某个寄存器对不上就顺着那条路径查。另一个常见问题是thaw的调用顺序。恢复时thaw是反向遍历dpm_list子设备先于父设备。如果子设备的thaw依赖父设备已经恢复就会失败。解决办法是在freeze时记录依赖关系或者把父设备的thaw提前。5.3 镜像写入中断存储驱动的电源管理冲突写镜像到一半失败日志显示PM: I/O error on swap device通常是存储驱动在freeze阶段被挂起了。内核虽然会保护 swap 设备但如果你的存储控制器驱动没有正确标记还是会被冻结。检查驱动的dev_pm_ops确认 swap 设备对应的控制器在freeze里返回 0 但不做实际挂起。有些驱动用pm_runtime的ignore_children标记来保护可以参考。还有一种情况是存储介质本身在写入时掉电。比如 eMMC 在 hibernation 写镜像时如果电压不稳会写坏块。这种硬件问题只能从电源设计上解决软件层面可以加重试但治标不治本。5.4 常见问题速查表现象可能原因排查方法解决思路进入失败提示内存不足可用内存不够分配快照看 dmesg 的 available pages释放缓存、调小 image_size、加 swap找不到 swap 设备swap 未挂载或被冻结cat /proc/swaps挂载 swap检查驱动 freeze 回调恢复后设备不工作freeze/thaw 不对称对比寄存器 dump补全 thaw 里的恢复操作写镜像 I/O 错误存储驱动被挂起看 dmesg 的 I/O 错误保护 swap 设备不被冻结恢复后进程状态错乱快照不一致检查冻结是否完整确认所有可冻结任务都被冻结恢复卡在 loading image镜像损坏或校验失败看镜像签名和校验和重新生成镜像检查存储坏块5.5 几个我踩过的坑和独家技巧第一个坑是freeze回调里调用了mutex_lock。当时觉得锁一下没关系结果系统直接死锁因为持锁的线程已经被冻结了。后来改成用spinlock或者干脆不加锁靠冻结顺序保证一致性。第二个坑是镜像大小估算。我一开始按内存的 50% 设image_size结果跑桌面环境的板子镜像超了进入失败。后来改成动态计算先读/proc/meminfo估算实际占用再乘 1.5。这个逻辑可以写进启动脚本每次进 hibernation 前自动调整。第三个技巧是用pm_trace定位恢复阶段的设备问题。打开CONFIG_PM_TRACE后内核会记录每个设备的freeze和thaw时间戳恢复后通过/sys/kernel/debug/pm_trace查看。哪个设备耗时异常或者没被调用一目了然。还有一个经验是调试阶段先把CONFIG_PM_DEBUG里的PM_DEBUG_STATISTIC打开它会统计每个阶段的耗时和失败次数。我靠这个发现过某个 I2C 设备在thaw时重试了 200 多次最后定位到是上拉电阻配置问题。6. 从流程梳理到实际调优的几点体会把 hibernation 的流程走一遍之后最深的感受是它和 suspend 的边界比想象中模糊。很多驱动作者会把freeze和suspend写成同一套逻辑短期看没问题长期看迟早出事。因为两者的语义不同suspend允许设备保留部分上下文freeze要求设备彻底静默。混用会导致某些边界条件下状态不一致而这种问题往往在恢复后才暴露排查成本极高。另一个体会是内存管理在 hibernation 里的分量。快照生成、压缩、写入、恢复每一步都和内存分配器打交道。理解PG_reserved、PG_save这些页标记的作用比死记流程更有用。我后来调优时就是靠分析哪些页被标记为需要保存把镜像体积压下去了 15%。最后说一个实际调优的方向如果你的设备存储带宽有限可以考虑把镜像写到压缩后的文件系统上利用文件系统本身的压缩减少写入量。但要注意文件系统在freeze阶段的行为有些文件系统会在这时候刷日志反而增加 I/O。这个取舍得实测没有通用答案。