Android待机的suspend_sys_sync_queue分析
Android的4.0在待机机制上和之前版本大同小异,也可以说是机制相对完善并没多大的问题反馈出来。不过有个细节的地方,改动幅度较大,来看看
在linux待机机制中,开始待机的时候会调用sys_sync函数,sys_sync系统调用被用户空间函数调用,
用来将缓存中的数据写入块设备,sys_sync系统调用将buffer、inode和super在缓存中的数据写入设备。
此函数的介绍参看博文链接http://www.zzzyk.com/os/201204/126687.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
[csharp]
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);
}
[csharp]
suspend_sys_sync_work_queue =
create_singlethread_workqueue("suspend_sys_sync");
[csharp]
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的时候,如下
[csharp]
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执行完毕
[csharp]
error = suspend_sys_sync_wait();
if (error)
goto Exit;
[csharp]
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;
}
[csharp]
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宏定义。
摘自 J.A.Y的专栏
补充:移动开发 , Android ,