Linux 内核功耗子系统(十七):hibernation 过程梳理

全景介绍

三种睡下去

Linux 里整机休眠实际有三种，功耗从低到高：

• • s2idle（Suspend-To-Idle）：CPU 全部进 deep idle，DRAM 保 self-refresh，外设保供电，唤醒 latency 微秒级
• • s2ram / mem（Suspend-To-RAM，S3）：CPU 断电、外设断电、DRAM 保 self-refresh，SoC 只留 always-on 域，唤醒 latency 毫秒级
• • hibernation / disk（Suspend-To-Disk，S4）：整机断电，把整个内存内容写到磁盘，然后 shutdown。下次开机重新加载

前两种醒过来之后，还是原来那个内核，DRAM 里的所有指针、任务、缓存都在原地。hibernation 不一样：下次开机时，是一个新内核从磁盘里读一张旧内核的完整照片，然后原地覆盖自己。

这个两个内核的架构决定了 hibernation 的整套设计。

图 1 · 三种睡下去横向对比：s2idle / s2ram / hibernation

为什么还需要 hibernation

s2ram 已经省到只剩 DRAM refresh 的电流（几十 mW），为什么还要 S4？三个理由：

• • 零功耗：磁盘写完就 poweroff，插头拔了都行，笔记本长时间不用、服务器机房断电演练
• • 状态持久化：DRAM 数据不再受温度、电池老化、意外掉电的威胁
• • 跨物理设备迁移的萌芽：早年 tuxonice / uswsusp 甚至试图把 image 拷到另一台机器 resume，虽然实际用得少

代价也大：恢复时间从毫秒级变到秒级（要读几百 MB 到几 GB 数据）；对内存布局稳定性要求极高（image kernel 必须能重建那张历史照片）。

与前面几篇的关系

• • system sleep（十四） 讲的是 s2ram/s2idle 的整机流程，freezer + DPM + suspend_ops->enter
• • wakeup source（十六） 讲的是被谁抬回来，但 wakeup source 只在 s2ram/s2idle 时生效，因为 hibernation 已经 poweroff，只能靠电源键/RTC/WOL
• • hibernation（本篇） 补上第三条路径：不是睡而是快照 + poweroff + 重启加载

三种模式在 kernel/power/ 目录下并列：suspend.c（s2ram/s2idle）、hibernate.c（S4）、autosleep.c（Android 自动 s2ram）。

一个容易理解错的问题

写驱动最容易混淆的是 hibernation 和 suspend 用的 是同一套struct dev_pm_ops 回调，但语义差别很大：

• • suspend() / resume()：s2ram/s2idle 通用
• • freeze() / thaw()：hibernation 的第一阶段（造快照前后）
• • poweroff() / restore()：hibernation 的第二阶段（写盘 poweroff / 从盘恢复）

只写 suspend()/resume() 的驱动，hibernation 时 PM Core 会自动回退用 suspend/resume。但硬件状态在 hibernation 里被彻底断电，如果驱动依赖某个不能持久化的资源（比如 GPU 上的 firmware image），必须在 restore() 里重新加载。这个 fallback 陷阱是 hibernation 相关 bug 的最大来源。

实际情况

hibernation 有三个关键设计取舍决定了它今天的样子。

取舍一：两阶段快照，不是单阶段 dump

朴素想法：一次性把 DRAM 全部写盘。这不可行，因为你正在运行的内核也在 DRAM 里，写盘时它在改自己。

swsusp 的解法是 两阶段：

• • 阶段一：hibernation_snapshot()，把整个内存复制到另一半内存（叫 image pages）。快照过程中，freezer 保证用户态不动、GFP_ATOMIC 保证内核不产生新 page
• • 阶段二：hibernation_write_image()，从容地把 image pages 写盘，因为它们已经不再变化了

这就要求 hibernation 前至少要有 50% 内存空闲，一半装原始数据、一半装快照。所以 image_size 内核参数默认是当前空闲内存的 2/5，超过就分批 shrink。

取舍二：两个内核，不是一个内核继续跑

为什么 resume 不是接着当时那个状态继续跑？因为 hibernation 已经彻底 poweroff，DRAM 内容清空，下次开机必然是一个全新的内核（bootloader 加载的、和当时那个不同副本、内核版本/config 甚至可能不同）。

于是 resume 路径变成：

1. 1. boot kernel 启动到能挂载 swap 分区
2. 2. 检测到 swap 里有 hibernation image、且 signature 有效
3. 3. 分配一堆临时 pages 读出 image
4. 4. swsusp_arch_resume()，跳转到 image kernel 的入口，让它接管
5. 5. image kernel 恢复自己的所有指针、任务、page 表，然后 thaw 所有设备
6. 6. 原来 boot kernel 的所有 page 被丢弃，包括正在执行 swsusp_arch_resume() 的那段代码

这个从 A 内核跳到 B 内核的动作是 hibernation 里最魔幻的部分，它的实现是 arch 相关的汇编。arm64 平台的实现在 arch/arm64/kernel/hibernate-asm.S（x86_64 有一份对应的 arch/x86/power/hibernate_asm_64.S）；本文的汇编片段都以 arm64 为准。

取舍三：freezer 是硬门槛，不是软约束

hibernation 开始前必须把所有用户态进程和大部分内核 kthread 冻住。这不是可选项：

• • 用户态进程持续在写内存 → 快照瞬间不一致 → resume 后数据损坏
• • 某些 kthread（比如 workqueue、io_wq）也会污染快照

freeze_processes() 用一个 flag PF_FROZEN + try_to_freeze() 的检查点让所有可冻结任务停在安全位置。任何一个进程冻结失败，hibernation 直接 abort，这就是为什么服务器上跑着某个顽固进程时，hibernate 会失败。

抽象对象

一句话概括：hibernation 是内存分区 → 快照容器 → 落盘协议三件套。

中心一：struct swsusp_info（image header）

写盘时最先落盘的是一个 header：

// kernel/power/swsusp.c
struct swsusp_info {
struct new_utsname  uts;            // uname 信息，用于校验
    u32                 version_code;   // 内核版本号
    unsigned long       num_physpages;  // 快照前的物理页数
    int                 cpus;
    unsigned long       image_pages;    // image 中 page 数
    unsigned long       pages;          // 加上元数据后的总 page 数
    unsigned long       size;           // 字节大小
} __aligned(PAGE_SIZE);

这个 header 是这张照片属于哪个内核的身份证，resume 时 boot kernel 会先读这一页，看 uts 和 version_code 是不是自己（或至少是兼容的），不匹配就拒绝 resume。

中心二：struct snapshot_handle（快照迭代器）

实际的快照是一堆散乱的 page，用 handle 迭代访问：

// kernel/power/power.h
struct snapshot_handle {
    unsigned int        cur;            // 当前 page 索引
    void                *buffer;        // 当前 page 的内容
    int                 sync_read;      // 是否同步读
};

上层协议就是一个 snapshot_read_next(handle) / snapshot_write_next(handle) 循环，每次拿到下一页 4KB 数据。这个抽象让写盘和用户态 uswsusp 走同一套接口（/dev/snapshot 就是把这个 handle 封给了用户态）。

中心三：swap_map[]（磁盘位置索引）

image page 落到 swap 分区里的哪些扇区？用一个大数组记下来：

// kernel/power/swap.c
static sector_t swsusp_last_page = 0;
struct swap_map_page {
    sector_t        entries[MAP_PAGE_ENTRIES];
    sector_t        next_swap;      // 下一个 swap_map_page 的位置
};

swap_map_page 本身也占一个扇区，多个 map page 用链表串起来，read 时按链表一路遍历。第一个 swap_map_page 的位置存在 swap header 的 resume_offset 字段，bootloader 传给 boot kernel 后，kernel 就知道从哪读起。

图 2 · swap 分区 image 布局与 header/map/data 三段

视角一：控制入口，/sys/power/state 和 /sys/power/disk

用户态发起 hibernation 有两条路：

• • 写 /sys/power/state = disk：走内核默认路径，模式由 /sys/power/disk 决定
• • 走 /dev/snapshot：用户态自己控制每一步（uswsusp/tuxonice 用），细粒度大

/sys/power/disk 有五个可选值：

• • platform：调用 platform_ops->finish/enter 让固件把机器 poweroff（ACPI S4）
• • shutdown：等价于 reboot -h，写盘完就 shutdown
• • reboot：写盘完就 reboot，重启后 resume
• • suspend：hybrid sleep，先写盘，再 s2ram。电池撑得住就走 resume from RAM 快路径，撑不住就走 resume from disk
• • test_resume / testproc：调试用

视角二：resume 触发，resume 内核参数 / initramfs 里的 resume 工具

resume 侧的入口有两个：

• • 内核内建：cmdline 里 resume=/dev/sda2 resume_offset=12345 直接告诉内核到哪找 image
• • initramfs 里的 resume 工具：update-initramfs 会把 resume 逻辑打包进 initramfs，好处是可以选择 resume 前先 mount root、prompt 用户

内核路径最后都会走到 software_resume()：读 swap header → 找 signature → 分配 image pages → 读盘 → 调 hibernation_restore() 跳转到 image kernel。

视角三：设备侧，dev_pm_ops 的第二组回调

驱动为 hibernation 提供的是四个第二组回调：

struct dev_pm_ops {
    // 第一组（s2ram/s2idle）
    int (*suspend)(struct device *dev);
    int (*resume)(struct device *dev);

    // 第二组（hibernation 特有）
    int (*freeze)(struct device *dev);      // 快照前，停止硬件活动
    int (*thaw)(struct device *dev);        // 快照完成，恢复正常运行（image 已在内存中）
    int (*poweroff)(struct device *dev);    // 写盘完成，即将 poweroff
    int (*restore)(struct device *dev);     // 从盘恢复后，重建硬件状态
};

时序上，一次完整的 hibernate + resume 是：

freeze → snapshot → thaw → (系统正常运行几秒钟) → poweroff → 写盘 → 断电
    ...下一次开机...
boot kernel 起来 → 读盘 → jump 到 image kernel → restore

freeze 和 poweroff 的差别：freeze 阶段设备只是暂停（快照要包含设备当前寄存器），thaw 后设备恢复继续跑；poweroff 阶段设备要做实际的下电准备（因为快照已经写完，接下来断电了）。

视角四：内存侧的 page 分类与 shrink

hibernation 把物理内存 page 分成几类，落盘策略不同：

• • saveable pages：普通数据，进快照
• • highmem pages：ARM32 / x86_32 遗留概念，需要临时映射后再拷
• • nosave pages：kernel text/rodata、per-CPU init 数据、initrd 释放的 pages，不进快照（下次开机 boot kernel 会重建）
• • unsaveable pages：某些 hardware DMA 缓冲、free pages，被跳过

如果 image 太大装不下，shrink_all_memory() 会主动收缩 page cache、释放 slab、swap out 部分匿名页，image 太大是 hibernate 失败的第二大原因（第一大是 freezer 失败）。

模型

hibernation 的核心模型有两个：快照生命周期 和 两内核 handoff。

快照生命周期模型

一张快照从造出来到写盘到读回来到销毁，经历这些状态：

hibernation_snapshot()
[空闲]  ──────────────────────────► [in-memory image]
                                    │
                    hibernation_write_image()
                                    ▼
                            [written to disk]
                                    │
                            系统 poweroff
                                    │
                                    ▼
                            [持久化在磁盘上]
                                    │
                            下次开机 boot kernel
                            software_resume()
                                    │
                                    ▼
                            [in-memory image (in boot kernel)]
                                    │
                            swsusp_arch_resume()
                                    │
                                    ▼
                            [restored (in image kernel)]

关键点：image 在磁盘上可以躺任意长时间，只要 swap 分区不被写坏、内核版本兼容，一年后开机也能 resume（虽然实践中没人这么用）。

图 3 · 快照生命周期（in-memory → disk → in-memory → restored）

两内核 handoff 模型

boot kernel 和 image kernel 共存的窗口只有几十毫秒，但是这段时间的语义最诡异：

图 4 · 两内核 handoff 双时序（boot kernel 与 image kernel）

[boot kernel]                       [image kernel]
    │
    software_resume():
      读 image 到 safe pages
      调用 arch handoff
      │
      ─────► swsusp_arch_resume() ────► restore_registers()
                                          │
                                          切换 page table
                                          │
                                          恢复所有 CPU 寄存器
                                          │
                                          ─────► [image kernel 完全接管]
                                                    │
                                                    thaw_processes()
                                                    resume_console()
                                                    ...

image kernel 醒来时看到的时间戳、系统状态、进程列表都是当年那个，它完全不知道刚才发生了一次 poweroff 和一次重启。所以：

• • jiffies 会突然跳跃（RTC 会尝试修正，但精度有限）
• • 网络连接全部失效（TCP 对端已经超时了）
• • 硬件中断号如果 SoC 有变化就完蛋（虽然同一台机器不会有）
• • 时钟源（clocksource）需要重新校准

数据流

从触发 hibernate 到下次 resume 完成，数据流分成四段。

图 5 · hibernate + resume 完整数据流泳道

阶段一：freeze + snapshot

用户态写 /sys/power/state = disk 触发 hibernate()：

// kernel/power/hibernate.c
int hibernate(void)
{
    int error, nr_calls = 0;

    // 1. 通知所有 PM notifier
    error = __pm_notifier_call_chain(PM_HIBERNATION_PREPARE, -1, &nr_calls);

    // 2. 拿 hibernation 独占锁（防并发）
    lock_system_sleep();

    // 3. 冻结用户态
    error = freeze_processes();
    if (error)
        goto Thaw;

    // 4. 冻结内核态 kthreads
    error = freeze_kernel_threads();
    if (error)
        goto Thaw;

    // 5. sync 磁盘（保证脏 page 落盘）
    ksys_sync_helper();

    // 6. 造快照（这是核心）
    error = create_image(in_suspend);
    ...
}

create_image() 内部：

// kernel/power/hibernate.c
static int create_image(int platform_mode)
{
    // 关中断、把 CPU 降到 non-boot CPU 全下线
    error = disable_nonboot_cpus();

    // suspend 所有设备的 noirq 阶段
    error = dpm_suspend_end(PMSG_FREEZE);

    // 开始真正的 snapshot
    save_processor_state();

    // 这里是关键：hibernation_snapshot 会造出 in-memory image
    error = swsusp_arch_suspend();

    // 从这里返回可能是两条路：
    // - 造 image 结束（in_suspend == 1，接着 poweroff）
    // - image kernel 醒来（in_suspend == 0，接着 restore）

    restore_processor_state();
    dpm_resume_start(in_suspend ? PMSG_QUIESCE : PMSG_RECOVER);
    enable_nonboot_cpus();
    return error;
}

swsusp_arch_suspend() 是 arch 相关的核心（arm64 版）：