Linux进程冻结技术
作者:itrocker 发布于:2015-11-24 15:01 分类:电源管理子系统
1 什么是进程冻结
进程冻结技术(freezing of tasks)是指在系统hibernate或者suspend的时候,将用户进程和部分内核线程置于“可控”的暂停状态。
2 为什么需要冻结技术
假设没有冻结技术,进程可以在任意可调度的点暂停,而且直到cpu_down才会暂停并迁移。这会给系统带来很多问题:
(1)有可能破坏文件系统。在系统创建hibernate image到cpu down之间,如果有进程还在修改文件系统的内容,这将会导致系统恢复之后无法完全恢复文件系统;
(2)有可能导致创建hibernation image失败。创建hibernation image需要足够的内存空间,但是在这期间如果还有进程在申请内存,就可能导致创建失败;
(3)有可能干扰设备的suspend和resume。在cpu down之前,device suspend期间,如果进程还在访问设备,尤其是访问竞争资源,就有可能引起设备suspend异常;
(4)有可能导致进程感知系统休眠。系统休眠的理想状态是所有任务对休眠过程无感知,睡醒之后全部自动恢复工作,但是有些进程,比如某个进程需要所有cpu online才能正常工作,如果进程不冻结,那么在休眠过程中将会工作异常。
3 代码实现框架
冻结的对象是内核中可以被调度执行的实体,包括用户进程、内核线程和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延后执行。
标记系统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状态,并做相应处理。
任务主动调用try_to_freeze的代码如下:
static inline bool try_to_freeze_unsafe(void) { if (likely(!freezing(current))) //检查系统是否处于freezing状态 return false; return __refrigerator(false); //主动进入冻结 } static inline bool freezing(struct task_struct *p) { if (likely(!atomic_read(&system_freezing_cnt))) //系统总体进入freezing return false; return freezing_slow_path(p); } bool freezing_slow_path(struct task_struct *p) { if (p->flags & PF_NOFREEZE) //当前进程是否允许冻结 return false; if (pm_nosig_freezing || cgroup_freezing(p)) //系统冻结kernel threads return true; if (pm_freezing && !(p->flags & PF_KTHREAD)) //系统冻结用户进程 return true; return false; }
进入冻结状态直到恢复的主要函数:
bool __refrigerator(bool check_kthr_stop)
{ ... for (;;) { set_current_state(TASK_UNINTERRUPTIBLE); //设置进程为UNINTERRUPTIBLE状态 spin_lock_irq(&freezer_lock); current->flags |= PF_FROZEN; //设置已冻结状态 if (!freezing(current) || (check_kthr_stop && kthread_should_stop())) //判断系统是否还处于冻结 current->flags &= ~PF_FROZEN; //如果系统已解冻,则取消冻结状态 spin_unlock_irq(&freezer_lock); if (!(current->flags & PF_FROZEN)) //如果已取消冻结,跳出循环,恢复执行 break; was_frozen = true; schedule(); } ...... }
4 参考文献
(1) http://www.wowotech.net/linux_kenrel/suspend_and_resume.html
(2) http://www.wowotech.net/linux_kenrel/std_str_func.html
(3) kenrel document: freezing-of-tasks.txt

评论:
2015-12-15 10:21
resume时如果是STR,就直接从内存中的runqueue继续调度
2015-12-28 10:39
2015-12-07 16:23
因为freeze task之后一些有趣的优化就成为了可能,比如cpu可能进入更深的cstate,可以停掉timer,timekeeping module甚至tsc,达到进一步节能。主要是,suspend to idle可以替代suspend to mem,毕竟后者需要firmware支持。
2015-12-08 09:18
2015-11-25 15:29
根据这篇文章,大伙都已经知道了在suspend过程中,application层是被freezed了,resume后该application会继续运行。(仿佛都不知道自己“休眠”了一段时间)
那么我们现在假设这么一个场景:
1.该APP是控制(或者与其通信)CPU外围一个运行着firmware的模块(比如DSP,FPGA)
2.在系统进入STR以后除了DDR里面内容是保持的,其他模块的logic都loss了(包括CPU)
3.系统resume以后,由于运行在CPU上的Linux有机制保证还原运行时的context, 但外围设备却不行,firmware是需要re-load
4.这样一来,如何能保证这个application能正常运行?
2015-11-24 19:03
现在freeze也被独立成一个电源状态,和standby、STR并列,而且设备的电源管理接口(struct dev_pm_ops)中也有很多freeze的回调函数(.freeze、freeze_late、.freeze_noirq),不知道itrocker 对此有什么看法?或者在哪里看到过这样的用法没?
2015-11-25 12:11
freeze作为电源状态应该是一种只冻结进程,而不改变cpu状态的低阶休眠。
在suspend_enter中,如果是freeze状态,系统就保持awake
if (state == PM_SUSPEND_FREEZE) {
freeze_enter();
goto Platform_wake;
}
dev_pm_ops中的freeze回调应该是考虑到系统暂停过程的各个阶段,一些复杂外设可能会有有不同的处理。.freeze、.freeze_late、.freeze_noirq分别会在dpm_suspend_start和dpm_suspend_end中调用
不过这些回调依赖于编译选项CONFIG_HIBERNATE_CALLBACKS,目前我还没有用到过。
功能
最新评论
- wangjing
写得太好了 - wangjing
写得太好了! - DRAM
圖面都沒辦法顯示出來好像掛點了。 - Simbr
bus至少是不是还有个subsystem? - troy
@testtest:只要ldrex-modify-strex... - gh
Linux 内核在 sparse 内存模型基础上实现了vme...
文章分类
随机文章
文章存档
- 2025年4月(5)
- 2024年2月(1)
- 2023年5月(1)
- 2022年10月(1)
- 2022年8月(1)
- 2022年6月(1)
- 2022年5月(1)
- 2022年4月(2)
- 2022年2月(2)
- 2021年12月(1)
- 2021年11月(5)
- 2021年7月(1)
- 2021年6月(1)
- 2021年5月(3)
- 2020年3月(3)
- 2020年2月(2)
- 2020年1月(3)
- 2019年12月(3)
- 2019年5月(4)
- 2019年3月(1)
- 2019年1月(3)
- 2018年12月(2)
- 2018年11月(1)
- 2018年10月(2)
- 2018年8月(1)
- 2018年6月(1)
- 2018年5月(1)
- 2018年4月(7)
- 2018年2月(4)
- 2018年1月(5)
- 2017年12月(2)
- 2017年11月(2)
- 2017年10月(1)
- 2017年9月(5)
- 2017年8月(4)
- 2017年7月(4)
- 2017年6月(3)
- 2017年5月(3)
- 2017年4月(1)
- 2017年3月(8)
- 2017年2月(6)
- 2017年1月(5)
- 2016年12月(6)
- 2016年11月(11)
- 2016年10月(9)
- 2016年9月(6)
- 2016年8月(9)
- 2016年7月(5)
- 2016年6月(8)
- 2016年5月(8)
- 2016年4月(7)
- 2016年3月(5)
- 2016年2月(5)
- 2016年1月(6)
- 2015年12月(6)
- 2015年11月(9)
- 2015年10月(9)
- 2015年9月(4)
- 2015年8月(3)
- 2015年7月(7)
- 2015年6月(3)
- 2015年5月(6)
- 2015年4月(9)
- 2015年3月(9)
- 2015年2月(6)
- 2015年1月(6)
- 2014年12月(17)
- 2014年11月(8)
- 2014年10月(9)
- 2014年9月(7)
- 2014年8月(12)
- 2014年7月(6)
- 2014年6月(6)
- 2014年5月(9)
- 2014年4月(9)
- 2014年3月(7)
- 2014年2月(3)
- 2014年1月(4)
2015-12-14 22:39