linux电源管理--task freeze

在Linux kernel的睡眠主流程中，有一个关键动作就是冻结进程，为什么要冻结进程？

假设没有冻结技术，进程可以在任意可调度的点暂停，而且直到cpu_down才会暂停并迁移。这会给系统带来很多问题：

(1)有可能破坏文件系统。在系统创建hibernate image到cpu down之间，如果有进程还在修改文件系统的内容，这将会导致系统恢复之后无法完全恢复文件系统；

(2)有可能导致创建hibernation image失败。创建hibernation image需要足够的内存空间，但是在这期间如果还有进程在申请内存，就可能导致创建失败；

(3)有可能干扰设备的suspend和resume。在cpu down之前，device suspend期间，如果进程还在访问设备，尤其是访问竞争资源，就有可能引起设备suspend异常；

(4)有可能导致进程感知系统休眠。系统休眠的理想状态是所有任务对休眠过程无感知，睡醒之后全部自动恢复工作，但是有些进程，比如某个进程需要所有cpu online才能正常工作，如果进程不冻结，那么在休眠过程中将会工作异常。

标记系统freeze状态的有三个重要的全局变量：pm_freezing、system_freezing_cnt和pm_nosig_freezing，如果全为0，表示系统未进入冻结；system_freezing_cnt>0表示系统进入冻结，pm_freezing=true表示冻结用户进程，pm_nosig_freezing=true表示冻结内核线程和workqueue。它们会在freeze_processes和freeze_kernel_threads中置位，在thaw_processes和thaw_kernel_threads中清零。

fake_signal_wake_up函数巧妙的利用了信号处理机制，只设置任务的TIF_SIGPENDING位，但不传递任何信号，然后唤醒任务；这样任务在返回用户态时会进入信号处理流程，检查系统的freeze状态，并做相应处理。

为什么UNINTERRUPTIBLE的task设计成 不能freeze，即freeze_task()为什么调用wake_up_state(p, TASK_INTERRUPTIBLE)而不是 wake_up_state(p, TASK_UNINTERRUPTIBLE);
系统suspend的流程肯定是先freeze所有的task，然后suspend driver，类似人睡眠时 先停止跳舞/吃饭的活动，再躺下闭上眼睛 停止身体；
但是一个 UNINTERRUPTIBLE的task，比如一个file write的操作，给disk发送了指令 并等待IO完成；如果他被freeze了，在从free_task到suspend_disk中间，disk的IO完成了，此时 之前的task已经freeze无法响应此complete或者需要重新唤醒来响应此IO的complete。
所有，最好还是设计成UNINTERRUPTIBLE的task在freeze时失败，并循环检测几次（freeze_timeout_msecs = 20s）等待IO完成，如果IO一直没有完成，退出suspend，一个task处于suspend时间过长也是有问题的。

冻结的对象是内核中可以被调度执行的实体，包括用户进程、内核线程和work_queue。用户进程默认是可以被冻结的，借用信号处理机制实现；内核线程和work_queue默认是不能被冻结的，少数内核线程和work_queue在创建时指定了freezable标志，这些任务需要对freeze状态进行判断，当系统进入freezing时，主动暂停运行。

kernel threads可以通过调用kthread_freezable_should_stop来判断freezing状态，并主动调用__refrigerator进入冻结；work_queue通过判断max_active属性，如果max_active=0，则不能入队新的work，所有work延后执行。