Android待机的suspend_sys_sync_queue分析

Android待机的suspend_sys_sync_queue分析

Android的4.0在待机机制上和之前版本大同小异，也可以说是机制相对完善并没多大的问题反馈出来。不过有个细节的地方，改动幅度较大，来看看

在linux待机机制中，开始待机的时候会调用sys_sync函数，sys_sync系统调用被用户空间函数调用，

用来将缓存中的数据写入块设备，sys_sync系统调用将buffer、inode和super在缓存中的数据写入设备。

此函数的介绍参看博文链接http://blog.chinaunix.net/uid-24237502-id-106067.html。

sys_sync函数执行时间长度依文件系统而定，长至上百毫秒，也有若干毫秒。函数执行的必要性如何呢？

如果有种需求，在很短时间（毫秒级）内需要连续进出待机，sys_sync函数是否需要每次都执行一遍呢？

如果只第一次执行，会有什么隐患问题呢？

由于待机请求有自动超时待机和按键进入待机，自动进入待机问题不大，基本上是闹钟或者计时时间发起事件，

而按键进入待机不同，按键时间贯穿kernel到android上层，涉及节点处理，文件系统操作，

所以对同步设备节点数据sys_sync就有需求，可以看出来，android4.0在对sys_sync的调用修改上，也是考虑到按键进入待机的隐藏问题。

那到底做了哪些修改呢？

suspend_sys_sync_queue有三个地方在调用

Earlysuspend.c (kernel\power)

Suspend.c (kernel\power):

Wakelock.c (kernel\power):

定义是在Wakelock.c (kernel\power)中

这个函数实现执行队列中suspend_sys_sync_work

void suspend_sys_sync_queue(void)
{
	int ret;

	spin_lock(&suspend_sys_sync_lock);
	ret = queue_work(suspend_sys_sync_work_queue, &suspend_sys_sync_work);
	if (ret)
		suspend_sys_sync_count++;
	spin_unlock(&suspend_sys_sync_lock);
}

	suspend_sys_sync_work_queue =
		create_singlethread_workqueue("suspend_sys_sync");

static void suspend_sys_sync(struct work_struct *work)
{
	if (debug_mask & DEBUG_SUSPEND)
		pr_info("PM: Syncing filesystems...\n");

	sys_sync();

	if (debug_mask & DEBUG_SUSPEND)
		pr_info("sync done.\n");

	spin_lock(&suspend_sys_sync_lock);
	suspend_sys_sync_count--;
	spin_unlock(&suspend_sys_sync_lock);
}
static DECLARE_WORK(suspend_sys_sync_work, suspend_sys_sync);

所以调用 suspend_sys_sync_queue，其实最后还是调用sys_sync，只是增加对sys_sync执行次数的计数，以及队列方式执行并非立即执行。

队列方式执行，是对执行的时间上有要求，那么它到底需要等待多少时间呢？相对什么等待呢？

待机，对系统而言，就是冻结，退出待机时候，对系统而言相当于什么事情都没发生。

标准linux待机在待机的开始阶段，就会冻结所有的进程和任务，在唤醒时候恢复它们。

由于进程在kernel空间处理的复杂度，linux在冻结进程和任务的时候，不支持进程还跑在kernel空间，否则就是abort处理。

问题就出来了，最后一次按键进入待机，按键时间从键值采集、键值上报、上层对上报值的轮询、对按键事件分发、对按键时间的处理等，

都需要一定时间，如果在进程未能较快回到用户空间，freeze_processes的时候，如下

	printk("Freezing user space processes ... ");
	error = try_to_freeze_tasks(true);
	if (error)
		goto Exit;
	printk("done.\n");

在freezing user space processes会abort。

补充一下说明：这里针对的不全是最后一次按键，我们知道android为了增加用户体验，在超时进入待机时候，会启动一个5秒的定时闹钟，

从而阻止5秒内真正进入待机，在用户体验上，就是屏幕暗下来的5秒内，只要用户及时点亮屏幕，系统就没真正待机，不会有锁屏界面。

开发员在此过程中会看到freezing user space processes abort，是因为系统启动了alarm，从而推出待机，系统恢复。

这里增加了一个timer，用于等待sys_sync执行完毕

	error = suspend_sys_sync_wait();
	if (error)
		goto Exit;

int suspend_sys_sync_wait(void)
{
	suspend_sys_sync_abort = false;

	if (suspend_sys_sync_count != 0) {
		mod_timer(&suspend_sys_sync_timer, jiffies +
				SUSPEND_SYS_SYNC_TIMEOUT);
		wait_for_completion(&suspend_sys_sync_comp);
	}
	if (suspend_sys_sync_abort) {
		pr_info("suspend aborted....while waiting for sys_sync\n");
		return -EAGAIN;
	}

	return 0;
}

static bool suspend_sys_sync_abort;
static void suspend_sys_sync_handler(unsigned long);
static DEFINE_TIMER(suspend_sys_sync_timer, suspend_sys_sync_handler, 0, 0);
/* value should be less then half of input event wake lock timeout value
 * which is currently set to 5*HZ (see drivers/input/evdev.c)
 */
#define SUSPEND_SYS_SYNC_TIMEOUT (HZ/4)
static void suspend_sys_sync_handler(unsigned long arg)
{
	if (suspend_sys_sync_count == 0) {
		complete(&suspend_sys_sync_comp);
	} else if (has_wake_lock(WAKE_LOCK_SUSPEND)) {
		suspend_sys_sync_abort = true;
		complete(&suspend_sys_sync_comp);
	} else {
		mod_timer(&suspend_sys_sync_timer, jiffies +
				SUSPEND_SYS_SYNC_TIMEOUT);
	}
}

等待的时间should be less then half of input event wake lock timeout value，

evdev事件会超时50ms，这里的timeout需要小于25ms，此处设置为2.5ms。

对timeout的要求，应该是为了能够更快地在evdev超时后执行timer的handler。

以上这些代码，都可以追踪CONFIG_SUSPEND_SYNC_WORKQUEUE宏定义。