如果你用过 Linux 笔记本大概率经历过这么一件事合上盖子合久了满电直接掉到没电但下一次打开系统居然还在原封不动等着你。这种“断电后依然原地复活”的能力靠的并不是屏幕关闭也不是 suspend-to-RAMS3而是今天要聊的 hibernation——Linux 内核功耗子系统里的 S4 状态。它和 suspend 最大的区别只有一个S3 还得靠内存供电S4 则把内存整个搬到磁盘然后真正断电。只要你机器的 swap 或者 hibernation 专用文件够大系统就像给内存拍了个快照罐头断电之后还能整罐拆开、原样还原。这篇就来把 Linux 内核里 hibernation 的完整过程从头到尾梳理一遍用户态怎么触发、内核怎么冻结进程、怎么把内存镜像写进 swap、机器怎么掉电以及下一次开机时内核又怎么沿着完全不同的路径把自己恢复回那个“快照”里的状态。这篇文章适合所有想理解 Linux 电源管理原理的人——不管是嵌入式开发调试 suspend/resume、写驱动时需要处理恢复回调还是维护服务器的同学想搞清楚挂起和休眠到底有什么区别。我会按实际内核代码路径和调试经验来讲尽量让没有读过内核源码的人也能跟着走一遍。1. 先弄明白hibernation 和 suspend 的根本分歧点1.1 同样叫“休眠”为什么 S3 和 S4 走的是两条完全不同的路很多人在/sys/power/state里看到freeze、mem、disk几个选项常常以为它们只是深度不同其实mem和disk在内核眼里是两套完全独立的机制。mem走的是 suspend-to-RAMCPU 进入更深度的 idle大部分设备的寄存器被打到低功耗状态内存进入自刷新模式唯一不能断的是内存供电。只要还有一丝电RAM 里的内容就不会丢所以唤醒时只需要恢复 CPU 上下文接着执行 suspend 时保存的下一条指令就行。整个过程像是按下暂停键再松开。disk走的是 suspend-to-disk也就是 hibernation整套系统进入“存档退出”逻辑。内核要先冻结用户进程和设备让系统状态不再变化然后对全部物理内存制作镜像把这个镜像写到稳定的块设备上——通常是 swap 分区或 swap 文件——最后真正执行机器的关机或断电。下一次开机时系统会先读取镜像把内存状态全部还原就像从存档点继续游戏一样。我遇到过不少同事把两者混为一谈但如果你带着“suspend 的扩展版”这个认识去读kernel/power/hibernate.c会发现代码结构完全不同suspend 的核心在kernel/power/suspend.c而 hibernation 的核心在kernel/power/hibernate.c和kernel/power/snapshot.c。后续所有分析都要围绕这条主线展开。1.2 为什么有了 suspend 还需要 hibernation断电场景下的救赎从功耗角度说S3 的功耗已经很低了但对某些场景S3 仍然撑不住笔记本电脑合盖后在包内存放几天S3 的漏电足以把电池耗尽一旦电池没电内存数据灰飞烟灭。hibernation 可以在电量低时自动触发把状态存到硬盘再关机。嵌入式系统有些设备要求掉电后快速恢复到工作现场而不是重新启动整个系统。hibernation 让它们断电后还能“续命”。服务器整机迁移或维护时可以先 hibernation再到别处恢复省去完整启动时间。我见过一个比较典型的产品应用是在车载平板上车辆断电后系统自动进入 hibernation下次上电时两三秒内就能回到之前的界面而不是等 Android 或 Linux 完全冷启动。这类场景如果只依赖 suspend一次亏电就完蛋。另外一个容易忽略的点hibernation 不仅仅是块设备的镜像写入它实际上是内核里“状态保存与恢复”的通用框架很多代码思路原子快照、页位图后来被 CRIU 等用户空间技术借鉴。所以就算你不做功耗管理读一读 snapshot.c 的思路也对理解内存管理有帮助。1.3 用户空间的进入姿势/sys/power/state 和 /sys/power/disk内核把 hibernation 的控制权通过 sysfs 暴露出来。最常见的是直接写 state 文件cat /sys/power/state # 输出里应该有 freeze、mem、disk 等选项 echo disk /sys/power/state如果只是写disk内核会使用默认的休眠模式通常是进入平台定义的电源状态如 S4 或实际关机掉电。/sys/power/disk还可以控制休眠的具体动作platform调用 platform 的休眠方法例如 ACPI S4 状态。shutdown进入 hibernation 后执行普通关机流程。reboot恢复镜像后重启。suspend同时启用 S3 和 hibernation也就是 hybrid suspend 的一种。我建议先花两分钟看看这两个文件里都有什么再继续读代码会容易得多。2. 休眠主流程拆解从 echo disk 到真正断电2.1 触发链路PM 核心怎么一步步陷进去当用户在 shell 里写下echo disk /sys/power/state最终会调用到hibernate()函数。这一步不是直接冻结进程而是先做一些前置校验交换空间是否存在、是否允许休眠、有没有被其他机制退出——例如正在使用firmware_loader之类的驱动可能阻止休眠。hibernate()大致流程如下加锁pm_mutex防止多个休眠请求并发。调用pm_notifier_call_chain(PM_HIBERNATION_PREPARE)通知各类子系统准备休眠。冻结所有用户态进程以及内核线程调用链是freeze_processes()。申请休眠镜像所需的内存通常是总内存的 1/16 左右保存到临时 page。调用suspend_console()、suspend_devices_and_enter()等让设备进入低功耗状态。创建内存镜像snapshot并在写入过程中进入“atomic section”。把镜像写入 swap写完后调用平台切换状态如 ACPI S4或者直接 power off。如果中途失败则回滚恢复设备并返回错误。这里边值得注意的是真正的镜像创建不是一次完成的而是经过“预冻结——拷贝——再次冻结”的两轮过程。原因很简单你想保存内存但保存内存本身需要时间在这段时间里进程还在跑内存还会变必须要有一个一致性的截断点。2.2 进程冻结与设备 suspend 的顺序为什么不能反你可能觉得“先把设备停了再冻结进程”更省事。但内核恰恰反着来先冻结进程后挂起设备。这是因为进程冻结后内存中不再有任何会修改页表的活动代码。如果先挂起设备设备可能还在 DMA 写入内存导致快照里的页被改动内核拿不到一致性视图。反过来先冻结进程后设备仍在工作但设备写入内存的行为一般由内核驱动控制驱动可以在设备 suspend 时完成 flush 或 DMA 停止这样内存状态就稳定了。所以实际流程是freeze_processes()向所有用户态进程发送冻结信号让它们进入不可中断的睡眠状态。freeze_kernel_threads()把内核线程也冻结。注意有些线程不能冻结例如用来写回 swap 的线程。suspend_console()暂停打印防止日志刷屏干扰时序。dpm_suspend_start()/dpm_suspend_end()设备进入 suspend这一步会调用各设备的-suspend_late和-suspend_noirq回调。我在实际调试中遇到过一个问题驱动在suspend回调里睡眠等待某个工作队列而那个工作队列里的内核线程已经被冻结了于是死锁。这也解释了为什么内核要求 suspend 回调不能随便依赖普通内核线程除非那个线程标记为不可冻结。2.3 内存快照的原子性为什么快照拷贝要搞两轮snapshot.c里的核心函数是create_basic_memory_bitmaps()和snapshot_read()。整个过程可以简化成三个步骤先把内存页的位图建立起来标记哪些页是“可释放”的、哪些是需要保存的。第一次遍历全部内存页把内容拷贝到预先分配的临时内存区域。在写镜像前重新冻结系统再执行一次 copy 迭代。此时用户进程全部冻结但页表可能因为上一步的改动而略有变化需要把变化的部分再同步进去。这个“两次拷贝”的设计本质上是解决“写快照时快照本身会被写快照扰动的”自指问题。一个更形象的类比你要给游泳池拍照但水还在流动你拍照的一瞬间水面会变化。你不能一边排水一边拍除非先让水平静一阵子再快速拍摄再观察位图确定哪些水少了补齐那些区域。具体实现里内核使用copy_bm位图来跟踪哪些页已经复制。第一轮拷贝时内核不冻结所有设备只是冻结进程因此可以安全地遍历内存。第二轮进入 atomic section关闭所有设备的中断停止调度这时内存状态绝对稳定需要复制的只有第一轮拷贝后变化过的页。这个过程被很形象地称为“atomic snapshot”。2.4 镜像写入与机器电源状态切换快照完成后内核进入名为hibernation_snapshot()的原子状态把控制权交给kernel/power/swap.c的写入层。swap writer 会依次把镜像头、内存页、页位图等写入交换设备。这块需要特别留意写入镜像时系统处于“近似冻结”的原子环境中断是被关闭的所以不能依赖普通块层的睡眠式 IO 路径。内核为此准备了一套专用的 swap 读写机制hib_bio_read/write直接构造 bio 请求并且使用 spinlock 而不是 mutex确保不睡眠。写入完成后power_down()会被调用。根据/sys/power/disk的配置它可能执行 ACPI 的 S4 转换、直接关机、或进入重启流程。到这里原本“活着”的内存内容已经完完整整躺在磁盘上了。3. 镜像落盘swap 上到底藏了什么秘密3.1 swap 分区 vs swap 文件hibernation 的选择逻辑交换空间本身是给内存回收用的但它也承载了 hibernation 镜像。这对 swap 布局提出了要求系统要有足够的空闲 swap 容纳压缩后的内存镜像且内核必须能找到 swap 设备上的锚点。传统做法是单独划分一个 swap 分区然后在/sys/power/resume或内核参数resume里写设备名。比如echo /dev/sda2 /sys/power/resume echo disk /sys/power/state如果要使用 swap 文件恢复时的定位逻辑要复杂一些因为镜像可以写在文件内部的任意偏移上。内核需要resumeUUID文件所在设备以及resume_offset文件偏移两个参数。新一点的发行版一般会在 initramfs 里配置好这些不需要手动干预。我建议嵌入式开发的同学优先用 swap 分区做测试因为它最简单不容易被文件系统元数据干扰。等整个链路调通之后再切换成 swap 文件。3.2 镜像在 swap 里的结构header、bitmaps、pages写进 swap 的镜像数据不是一堆裸内存页而是一个有结构的元数据包。按顺序来说镜像数据由多个struct swsusp_info描述的 section 组成。swsusp_info头部包含魔数、版本、页大小、镜像页数量、位图位置等信息。除了数据页本身还有内存页位图。内核使用两个位图一个是“已分配”位图标记哪些内存页在恢复时需要保留另一个是“写入”位图表示哪些页已经写盘。恢复时内核会先读取头部然后根据位图按页还原。读取这个结构最直接的办法是在休眠后用 crash 工具打开 vmcore或者用专门脚本解析 swap 内容。不过平时调试不需要到这一步明白头部和位图是为了让恢复器能知道“哪些内存页需要被还原、哪些页是临时镜像页”就够了。3.3 压缩、加密与 SNAPSHOT 的交互内核 2.6.32 以后镜像支持 LZO 压缩这能大幅减小 swap 占用和 IO 时间。配置项是CONFIG_HIBERNATION_COMP_LZO默认很多发行版都开着。压缩发生在 swap writer 一次写入多个页时使用内部压缩工作区。加密方面内核同样支持CONFIG_HIBERNATION_AES但很少有分发版默认开启因为密钥管理非常麻烦休眠时的密钥谁保存如果 key 不持久化恢复时怎么解密镜像内核的解决方案是把密钥密封在 TPM 里如果没有 TPM基本只能裸写。所以实践中安全敏感环境更多用块设备加密如 LUKS来保护整个 swap 分区而不是依赖休眠加密功能。压缩和加密都会影响一个重要指标可休眠性判定。在kernel/power/swap.c里有一个enough_swap()函数它根据总内存量和交换空间大小判断当前配置是否允许休眠。如果开了压缩判定时就把内存总量换算成“预计压缩后大小”这也是你在一个 8GB 内存的机器上只用 2GB swap 也能休眠成功的原因之一。3.4 空间估算与“Cannot hibernate: not enough swap”这类错误我看到很多帖子问为什么echo disk /sys/power/state会直接退出并打印Cannot hibernate: not enough swap。内核的enough_swap逻辑大致是这样static int enough_swap(unsigned int nr_pages) { // 计算已分配 swap 块数量 // 计算空闲可用的 swap 页面数 // 比较两者 }它的输入是待保存的页数输出决定是否可以休眠。没有开启压缩的时候要求free swap pages total memory pages metadata pages开启压缩时会按total pages * 压缩比来估算但压缩比通常假设为 50%。所以如果你的 swap 太小比如只有 1GB 而内存 4GB压缩后可能还是放不下。这里有个非常容易被忽略的点swap 里如果有正在使用的匿名页交换槽这部分空间是不能用于镜像的。所以即使free -h显示还有 5GB swap如果已经有进程使用了一部分内核会用swap_map统计实际可写的空闲块。我建议在休眠前先swapoff -a再swapon -a清空一次彻底避免这种边界问题。4. 恢复流程一条和休眠完全相反的独立路径4.1 引导阶段 resume 参数内核怎么知道去哪里找镜像系统休眠后等于关机。下一次上电要走完整的 bootloader 流程。如果 bootloader 或者内核命令行里没有指定 resume 设备内核会当作一次冷启动自动丢弃原镜像你再也回不到休眠时的现场。因此恢复过程的第一步是找到镜像。常见配置有两种内核命令行直接写resume/dev/sda2或resumeUUIDxxxx。由 initramfs 里的工具如 systemd、dracut、initramfs-tools解析 resume 参数通过/sys/power/resume写入值再触发内核恢复。如果是纯内核引导一般会经过启动早期内存管理初始化完成。解析resume参数。找到 swap 设备上的swsusp_info头部。校验魔数与版本如果匹配进入恢复模式。否则正常启动。我在移植内核到新板子时经常遇到resumeUUIDuuid无效的情况问题多半是 initramfs 里没有包含对应文件系统驱动无法在解挂 rootfs 之前打开 swap。不要小看这一步很多“休眠后无法恢复”的 bug 是坏在 initramfs 而不是内核本身。4.2 内存镜像加载恢复器如何重建整个内存现场一旦确认镜像存在内核会调用snapshot.c里的swsusp_read()读取镜像头并分配临时页。这个过程就像拆一座乐高积木重新拼起来读取struct swsusp_info获取内存页总数、位图位置、平台信息。分配一整套临时地址空间来映射将要恢复的页。根据位图逐页读回数据并标记哪些页是镜像元数据页、哪些是要恢复的普通页。读完后解除 old memory 的映射把页表切换到恢复后的状态。这里的难点是“页表重建”。休眠前内核把内存页写成了连续镜像恢复时系统刚开机内存管理完全是初始状态需要先把镜像 header 映射到临时地址按位图一块一块恢复。如果恢复过程中发现内存布局和休眠时不一致比如换了内存条、容量变小恢复基本失败因为这些位图记录的是旧内存页的物理地址。实际内核代码中有一个函数memory_bm_begin()和memory_bm_end()专门管理这个临时位图宏PG_ANY、PG_SAFE两位用来标识页是否属于保存区。普通读者不必细抠页面只需要记住恢复时用的页分配和休眠时用的是完全不同的机制它绕过了正常的内存分配器直接操作物理页。4.3 设备恢复顺序为什么反着来从 noirq 到 normal休眠时设备的顺序是suspend普通可睡眠suspend_latesuspend_noirq中断关闭后而恢复时正好反过来resume_noirq中断关闭状态下恢复硬件最基本功能resume_earlyresume正常启用中断内核这么设计是为了保证注册了 irq 的设备在中断来之前就已经恢复到可以屏蔽中断的状态。如果你的驱动只实现了resume而没有实现resume_noirq在中断恢复的那一瞬间硬件可能还处于未知状态IRQ 线已经拉高驱动没准备好处理就会出现唤醒后死锁或中断风暴。我在做 PCIe 网卡驱动时遇到过恢复后网络不通的问题。最后发现是因为resume_noirq阶段需要恢复 PCIe 的链路状态如果延迟到正常 resume 才有机会触发中断已经跑飞了。所以每个人的驱动都值得检查一下dev_pm_ops里对noirq回调的支持。4.4 为什么恢复之后有些驱动会“失灵”常见失败模式恢复过程只会还原内存和 CPU 状态不会还原外设内部状态。外设的所有寄存器内容在断电时丢得一干二净。内核只能重新初始化它们。如果驱动没有好好处理resume回调你会看到网卡链接消失需要手动ip link set eth0 down/up才能恢复。显示输出没有信号重启显示管理器才行。音频设备不可用因为 DMA 通道没有重新配置。触摸屏失灵因为 HID 设备需要重新创建输入节点。检查这种问题最重要的手段是看dmesg里有没有关于 suspend/resume 的警告。比如[ 123.456] device eth0 failed to resume: error -110如果看到-110一般表示超时通常是驱动在等待某个设备完成 reset但硬件没有回应。5. 实践中的调试手段与踩坑经验5.1 打开哪些日志和配置才能看到完整的休眠过程默认发行版的内核日志级别比较克制很多时候你只看到结果看不到细节。建议在调试时关闭 quiet并打开这些选项# 内核参数 nokaslr ignore_loglevel # sysfs 里的磁盘模式 echo shutdown /sys/power/disk同时确保内核配置里有CONFIG_PM_DEBUGy CONFIG_PM_SLEEP_DEBUGy CONFIG_HIBERNATIONy CONFIG_PM_TRACEyPM_TRACE会在休眠失败时打印一个设备调用链的 hash 值。这个值可以通过pm_trace_rtc机制回溯到具体是哪个设备导致的失败非常有用。具体做法是echo 1 /sys/module/pm_trace/parameters/perm cat /sys/power/pm_trace_time然后查看dmesg里打印出来的hash与候选硬件比对。虽然做得粗糙但在找不到原因的现场很有价值。5.2 最常见的一类故障休眠成功但恢复后文件系统损坏很多人遇到“休眠后开机根文件系统只读”的问题。根因几乎都不是内核 bug而是交换区与根文件系统同时位于同一块磁盘上恢复时 initramfs 尝试挂载根文件系统但swap 区域还没有解除映射导致文件系统元数据状态混乱。解决方法是使用单独的 swap 分区或 swap 文件。确保 initramfs 中挂载根分区之前先完成 resume 操作。resume 完成后立即 swapoff 镜像占用保证文件系统挂载干净。我在 Ubuntu 上使用 swap 文件休眠时偶尔会遇到 initramfs 报Failed to find root device后来查是因为 swap 文件里保存镜像后文件系统的目录项被镜像修改了因为 swap 文件本身是文件系统里的一个文件。恢复系统需要先通过裸块设备读取文件偏移再把根文件系统挂载。此时如果文件系统有日志回放就可能导致元数据不一致。推荐用 swap 分区来规避。5.3 做个自动化回归脚本化休眠/恢复测试休眠是个低频操作手工测试很难保证每次覆盖。最简单的自动化是反复进行休眠恢复循环同时记录关键指标#!/bin/bash # 简单 hibernate 压力测试脚本 for i in $(seq 1 20); do echo cycle $i date sync echo disk /sys/power/state sleep 10 dmesg | tail -30 | grep -E PM:|hibernation|resume /tmp/hib_test.log done注意这个脚本如果真的有休眠成功那么机器会在echo disk /sys/power/state后断电脚本的上下文根本不会继续执行。所以保存状态要依靠启动后的服务来自动记录而不是在脚本里 sleep。我一般是在 systemd 服务里通过ExecStart捕获启动后时间与上次休眠时间做对比。更高级的做法是使用/sys/power/wakeup_count结合rtcwake实现“定时唤醒后自动再次休眠”。这需要板级 RTC 支持但确实能模拟笔记本电脑合盖后的真实场景。5.4 从 hibernation 行为反推你的电源策略是否合理最后分享一个我在项目后期经常做的事通过分析休眠日志来评估整个设备的功耗策略。看什么看三个阶段的时间freeze processes 的时间如果用户空间有很多不可冻结的进程这个阶段会很长通常超过 1 秒就需要优化。device suspend 的时间驱动里/sys/kernel/debug/suspend_stats会记录每个阶段耗时。如果某个设备 suspend 特别慢值得单独看看它是不是一直在 poll 寄存器。镜像写入时间这个直接受 swap 速度和镜像大小影响。如果发现写入时间比冷启动还长可能你的镜像压缩策略不合适或者 swap 设备太慢这时可以考虑换成 SSD或者关掉压缩改走更快的裸写入。我遇到过一台平板休眠耗时 40 秒大部分时间浪费在写入 4GB 镜像到 eMMC。后来打开压缩并把 swap 移动到一个独立分区后时间降到 12 秒用户体验从“几乎不可用”变成“偶尔可以接受”。所以不要以为 hibernation 复杂度高就放弃优化瓶颈往往就那几个。在这篇文章里我没有刻意介绍每一个结构体细节因为对大多数人来说先形成“休眠——快照——写盘——恢复——重建”的完整逻辑链比死记硬背struct swsusp_info字段更有价值。等你真正调试时打开kernel/power/hibernate.c按流程定位再配合dmesg和/sys/power这两个工具至少能走完八成问题。我自己每次看这套代码都还能发现新的边界情况尤其是驱动和时序之间的微妙关系这大概就是功耗子系统里最有意思的部分了。