Linux进程冻结技术

作者:itrocker 发布于:2015-11-24 15:01 分类:电源管理子系统

1 什么是进程冻结

进程冻结技术(freezing of tasks)是指在系统hibernate或者suspend的时候,将用户进程和部分内核线程置于“可控”的暂停状态。

2 为什么需要冻结技术

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

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

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

(3)有可能干扰设备的suspendresume。在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_freezingsystem_freezing_cntpm_nosig_freezing,如果全为0,表示系统未进入冻结;system_freezing_cnt>0表示系统进入冻结,pm_freezing=true表示冻结用户进程,pm_nosig_freezing=true表示冻结内核线程和workqueue。它们会在freeze_processesfreeze_kernel_threads中置位,在thaw_processesthaw_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


标签: Linux freeze

评论:

heziq
2015-12-14 22:39
我比较关心那么没有freeze的kernel thread,在cpu down的时候,怎么处理的?resume的时候 ,它们又是从哪里开始的。
itrocker
2015-12-15 10:21
@heziq:这个点在文中第2节只是一笔带过。其实不只是kernel thread,如果没有freeze,所有的task都是在cpu down时从dying cpu的runqueue迁移到剩余active cpu的runqueue
resume时如果是STR,就直接从内存中的runqueue继续调度
C
2015-12-28 10:39
@itrocker:freeze跟cpu down没关系吧。有些涉及到磁盘操作的kernel thread是freezable的,因为freeze task最早提出是因为做磁盘的hibernation,比如kjournald,而workqueue则不再接收新的work item的queue请求。
C
2015-12-28 10:41
@C:sorry我没看到最初的问题,请无视上面的回答。
wmzjzwlzs
2017-11-04 09:26
@itrocker:1.没有设置为可冻结状态的内核线程有可能在device suspend之后还在运行?
2.如果一个内核线程设置成可冻结的,是不是系统会等待这个线程主动冻结自己后才不调度它,如果这个线程就是不主动冻结自己,是不是系统就睡不下去了
C
2015-12-07 16:23
今年CLK南京的会议上的topic就是suspend-to-idle。 freeze task的一个重要作用就是支持s2i。
因为freeze task之后一些有趣的优化就成为了可能,比如cpu可能进入更深的cstate,可以停掉timer,timekeeping module甚至tsc,达到进一步节能。主要是,suspend to idle可以替代suspend to mem,毕竟后者需要firmware支持。
wowo
2015-12-08 09:18
@C:suspend-to-idle是很诱人的,我们在很久之前一个项目中也想这样做,但是迫于框架的不完善,最终没敢行动。我觉得它的好处主要是在于便利性,随时睡,随时醒。如果省电效果不错的话,还是很好用的。
passerby
2015-12-28 15:01
@wowo:@wowo,suspend-to-idle是指所有CPU都不会掉电,只是进入CPU的低功耗状态吗?这样就不需要将task irq等从nonboot cpu中转移到boot cpu吗?
wowo
2015-12-28 16:29
@passerby:是的,对软件来说,这些CPU都还在,只是小睡了一下。
archer
2016-01-30 12:03
@C:请问一下,为什么要freeze task呢?就是为了避免进程运行干扰suspend的过程吧?但是suspend to idle也可以达到同样的效果吧?

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能正常运行?
itrocker
2015-11-25 16:28
@云:有些firmware会有自己的suspend逻辑。
个人感觉如果firmware上下文与AP强相关,会有相互同步协议保证一致性。
wowo
2015-11-25 16:33
@云:我觉得里面的关键点是:你这个APP,应该能保证不依赖DSP/FPGA的状态而独立运行,这样它才有机会re-load。因此只要在resume后,APP能判断是否需要re-load即可。
wowo
2015-11-24 19:03
非常感谢itrocker帮我把这篇文章补齐啊!~~~
现在freeze也被独立成一个电源状态,和standby、STR并列,而且设备的电源管理接口(struct dev_pm_ops)中也有很多freeze的回调函数(.freeze、freeze_late、.freeze_noirq),不知道itrocker 对此有什么看法?或者在哪里看到过这样的用法没?
itrocker
2015-11-25 12:11
@wowo:哈哈,主要是参考了wowo对suspend的精彩介绍。

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,目前我还没有用到过。

2015-11-25 15:19
@itrocker:我实现过suspend to RAM.
我想了解下目前在ARM上有实现HIBERNATE么?比如suspend to disk这种方案,suspend时候需要把memory snapshot保存在flash(nand或者emmc)上。
itrocker
2015-11-25 16:22
@云:hibernate好像一般用在PC或服务器,arm一般用于终端设备,所以很少使用CONFIG_HIBERNATION选项

2015-11-24 16:27
很棒的分析, suspend很重要的一个环节就是freezing task :)

感谢分享
itrocker
2015-11-24 16:50
@云:O(∩_∩)O
Daniel Shieh
2015-11-24 15:47
文章短小精悍^_^.
itrocker
2015-11-24 16:14
@Daniel Shieh:^_^  freeze确实简单而巧妙,我思考它最多的地方是为什么会产生这个技术

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog