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

评论:

hzm
2018-01-11 22:17
@wowo:
你在下面回答的问题,我有个疑问
a.关键点在于:freeze task的过程是“请求freeze”,也就是说给要被freeze的thread发一个信号,接下来的freeze过程是thread自行处理的。
=>看了代码的流程,没看到有发信号的地方呀,能指出一下吗?
b.因此kthread_freezable_should_stop是被freeze thread自己调用的。
=>同样,没进程处理signal的时候有调用到这个函数,能一起把代码指出一下吗?

非常感谢~
hzm
2018-01-15 11:43
@hzm:看到了,应该是这里
2138int get_signal(struct ksignal *ksig)
2139{
2140    struct sighand_struct *sighand = current->sighand;
2141    struct signal_struct *signal = current->signal;
2142    int signr;
2143
2144    if (unlikely(current->task_works))
2145        task_work_run();
2146
2147    if (unlikely(uprobe_deny_signal()))
2148        return 0;
2149
2150    /*
2151     * Do this once, we can't return to user-mode if freezing() == T.
2152     * do_signal_stop() and ptrace_stop() do freezable_schedule() and
2153     * thus do not need another check after return.
2154     */
2155    try_to_freeze();
2156
wowo
2018-01-16 09:38
@hzm:找到就行了,最近太忙,没来得及回复,抱歉哈~~
wmzjzwlzs
2017-11-04 09:27
1.没有设置为可冻结状态的内核线程有可能在device suspend之后还在运行?
2.如果一个内核线程设置成可冻结的,是不是系统会等待这个线程主动冻结自己后才不调度它,如果这个线程就是不主动冻结自己,是不是系统就睡不下去了
wowo
2017-11-06 09:10
@wmzjzwlzs:是的。这个问题其实很好验证,了解了kernel的机制之后,你可以写一个不可冻结的应用程序,实际测试一下。
wmzjzwlzs
2017-11-06 15:23
@wowo:谢谢wowo大神,测试了下
1.没有设置为可冻结状态的内核线程确实在device suspend之后还在运行
2.我把一个内核线程设置成可冻结的,然后就是不主动冻结自己,系统确实就睡不下去了
wowo
2017-11-06 16:55
@wmzjzwlzs:实践是检验真理的唯一标准啊,赞!!!~~~
yinjian
2017-10-23 15:23
你好,对于内核线程freeze的过程,还有点疑问:执行完wake_up_state函数后,是如何跑到kthread_freezable_should_stop函数的? :)
wowo
2017-10-24 09:27
@yinjian:关键点在于:freeze task的过程是“请求freeze”,也就是说给要被freeze的thread发一个信号,接下来的freeze过程是thread自行处理的。
因此kthread_freezable_should_stop是被freeze thread自己调用的。
kernel中有对应的例子,你可以看看。
废柴
2017-04-01 15:15
@wo神,

有个疑惑,android6.0以后搞出来一个Doze模式,请问Doze和PM suspend有关系么,还是说Doze仅仅只是android层的一种低功耗模式,和PM suspend没毛线关系?

谢谢

废柴
wowo
2017-04-01 16:43
@废柴:Doze是应用层的节电行为,和kernel中的PM没有关系。
comlee
2017-02-18 14:41
@wowo
你好,请问一个弱弱的问题。
如果应用释放的wake_lock锁是系统中的最后一把wake_lock锁的话,那么系统会马上进入suspend吗?还是要系统中的所有应用不再跑或进入阻塞等状态才进suspend?
wowo
2017-02-18 16:11
@comlee:一般情况下,负责电源管理的进度或者线程,优先级应该是最低的。
另外,休眠的过程中,执行freeze的过程,也会给应用机会,所以休眠的时候,应该应该不跑了。
comlee
2017-02-19 12:33
@wowo:@wowo:我看到/proc/power/wake_unlock这个节点的内核实现会在unlock时check并进入suspend流程。另外,我自己写了两个应用进行测试:
1.    main
     {
         while(1)
           ;
     }
发现这个系统是可以进入suspend的。

但是
    main()
    {
         system("echo 'mylock'>/proc/power/wake_lock");
         while(1)
           ;
     }
跑这个的话,系统进不了suspend(两个测试程序分别都是在init rc里面启动)。

所以看上去系统不会等应用层的程序阻塞或休眠才suspend? 只要应用释放的是系统最后一把wake_lock就走suspend流程?
wowo
2017-02-19 21:18
@comlee:是的,wakeup lock的思路就是,假如你不想让系统睡,你就要持一个锁。既然你没有保持锁,系统就假设可以睡了。
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

发表评论:

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