Linux电源管理_autosleep--(五)

本文深入探讨了Autosleep机制的设计理念与实现细节,旨在帮助读者理解如何在系统空闲时将其置于低功耗状态。文章详细介绍了Autosleep的工作流程,包括其与wakeup events框架的交互方式,以及如何通过sysfs接口配置Autosleep状态。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. 前言

Autosleep也是从Android wakelocks补丁集中演化而来的(Linux电源管理(9)_wakelocks),用于取代Android wakelocks中的自动休眠功能。它基于wakeup source实现,从代码逻辑上讲,autosleep是一个简单的功能,但背后却埋藏着一个值得深思的话题:

计算机的休眠(通常是STR、Standby、Hibernate等suspend操作),应当在什么时候由谁触发?

蜗蜗在“Linux电源管理(2)_Generic PM之基本概念和软件架构”中有提过,在传统的操作场景下,如PC、笔记本电脑,这个问题很好回答:由用户、在其不想或不再使用时

但在移动互联时代,用户随时随地都可能使用设备,上面的回答就不再成立,怎么办?这时,Android提出了“Opportunistic suspend(这个词汇太传神了,很难用简洁的中文去翻译,就不翻译了)”的理论,通俗的讲,就是“逮到机会就睡”。而autosleep功能,无论是基于Android wakelocks的autosleep,还是基于wakeup source的autosleep,都是为了实现“Opportunistic suspend”。

相比较“对多样的系统组件单独控制”的电源管理方案(如Linux kernel的Dynamic PM),“Opportunistic suspend”是非常简单的,只要检测到系统没有事情在做(逮到机会),就suspend整个系统。这对系统的开发人员(特别是driver开发者)来说,很容易实现,几乎不需要特别处理。

但困难的是,“系统没有事情在做”的判断依据是什么?能判断准确吗?会不会浪费过多的资源在"susend->resume-supsend…”的无聊动作上?如果只有一个设备在做事情,其它设备岂不是也得陪着耗电?等等…

所以,实现“Opportunistic suspend”机制的autosleep功能,是充满争议的。说实话,也是不优雅的。但它可以解燃眉之急,因而虽然受非议,却在Android设备中广泛使用。

其实Android中很多机制都是这样的(如wakelocks,如binder,等等),可以这样比方:Android是设计中的现实主义,Linux kernel是设计中的理想主义,当理想和现实冲突时,怎么调和?不只是Linux kernel,其它的诸如设计、工作和生活,都会遇到类似的冲突,怎么对待?没有答案,但有一个原则:不要偏执,不要试图追求非黑即白的真理!

我们应该庆幸有Android这样的开源软件,让我们可以对比,可以思考。偏题有点远,言归正传吧,去看看autosleep的实现。

2. 功能总结和实现原理

经过前言的瞎聊,Autosleep的功能很已经很直白了,“系统没有事情在做”的时候,就将系统切换到低功耗状态。

根据使用场景,低功耗状态可以是Freeze、Standby、Suspend to RAM(STR)和Suspend to disk(STD)中的任意一种。而怎么判断系统没有事情在做呢?依赖wakeup events framework。只要系统没有正在处理和新增的wakeup events,就尝试suspend,如果suspend的过程中有events产生,再resume就是了。

由于suspend/resume的操作如此频繁,解决同步问题就越发重要,这也要依赖wakeup events framework及其wakeup count功能。

3. 在电源管理中的位置

autosleep的实现位于kernel/power/autosleep.c中,基于wakeup count和suspend & hibernate功能,并通过PM core的main模块向用户空间提供sysfs文件(/sys/power/autosleep)

Autosleep architecture

注1:我们在“Linux电源管理(8)_Wakeup count功能”中,讨论过wakeup count功能,本文的autosleep,就是使用wakeup count的一个实例。

4. 代码分析

4.1 /sys/power/autosleep

/sys/power/autosleep是在kernel/power/main.c中实现的,如下:

   1: #ifdef CONFIG_PM_AUTOSLEEP
   2: static ssize_t autosleep_show(struct kobject *kobj,
   3:                               struct kobj_attribute *attr,
   4:                               char *buf)
   5: {
   6:         suspend_state_t state = pm_autosleep_state();
   7:  
   8:         if (state == PM_SUSPEND_ON)
   9:                 return sprintf(buf, "off\n");
  10:  
  11: #ifdef CONFIG_SUSPEND
  12:         if (state < PM_SUSPEND_MAX)
  13:                 return sprintf(buf, "%s\n", valid_state(state) ?
  14:                                                 pm_states[state] : "error");
  15: #endif
  16: #ifdef CONFIG_HIBERNATION
  17:         return sprintf(buf, "disk\n");
  18: #else
  19:         return sprintf(buf, "error");
  20: #endif
  21: }
  22:  
  23: static ssize_t autosleep_store(struct kobject *kobj,
  24:                                struct kobj_attribute *attr,
  25:                                const char *buf, size_t n)
  26: {
  27:         suspend_state_t state = decode_state(buf, n);
  28:         int error;
  29:  
  30:         if (state == PM_SUSPEND_ON
  31:             && strcmp(buf, "off") && strcmp(buf, "off\n"))
  32:                 return -EINVAL;
  33:  
  34:         error = pm_autosleep_set_state(state);
  35:         return error ? error : n;
  36: }
  37:  
  38: power_attr(autosleep);
  39: #endif /* CONFIG_PM_AUTOSLEEP */

a)autosleep不是一个必须的功能,可以通过CONFIG_PM_AUTOSLEEP打开或关闭该功能。

b)autosleep文件和state文件类似:

     读取,返回“freeze”,“standby”,“mem”,“disk”, “off”,“error”等6个字符串中的一个,表示当前autosleep的状态,分别是auto freeze、auto standby、auto STR、auto STD、autosleep功能关闭和当前系统不支持该autosleep的错误指示;

     写入freeze”,“standby”,“mem”,“disk”, “off”等5个字符串中的一个,代表将autosleep切换到指定状态。

c)autosleep的读取,由pm_autosleep_state实现;autosleep的写入,由pm_autosleep_set_state实现。这两个接口为autosleep模块提供的核心接口,位于kernel/power/autosleep.c中。

4.2 pm_autosleep_init

开始之前,先介绍一下autosleep的初始化函数,该函数在kernel PM初始化时(.\kernel\power\main.c:pm_init)被调用,负责初始化autosleep所需的2个全局参数:

1)一个名称为“autosleep”的wakeup source(autosleep_ws),在autosleep执行关键操作时,阻止系统休眠(我们可以从中理解wakeup source的应用场景和使用方法)。

2)一个名称为“autosleep”的有序workqueue,用于触发实际的休眠动作(休眠应由经常或者线程触发)。这里我们要提出2个问题:什么是有序workqueue?为什么要使用有序workqueue?后面分析代码时会有答案。

如下:

   1: int __init pm_autosleep_init(void)
   2: {
   3:         autosleep_ws = wakeup_source_register("autosleep");
   4:         if (!autosleep_ws)
   5:                 return -ENOMEM;
   6:  
   7:         autosleep_wq = alloc_ordered_workqueue("autosleep", 0);
   8:         if (autosleep_wq)
   9:                 return 0;
  10:  
  11:         wakeup_source_unregister(autosleep_ws);
  12:         return -ENOMEM;
  13: }

4.3 pm_autosleep_set_state

pm_autosleep_set_state负责设置autosleep的状态,autosleep状态和“Linux电源管理(5)_Hibernate和Sleep功能介绍”所描述的电源管理状态一致,共有freeze、standby、STR、STD和off五种(具体依赖于系统实际支持的电源管理状态)。具体如下:

   1: int pm_autosleep_set_state(suspend_state_t state)
   2: {
   3:  
   4: #ifndef CONFIG_HIBERNATION
   5:         if (state >= PM_SUSPEND_MAX)
   6:                 return -EINVAL;
   7: #endif
   8:  
   9:         __pm_stay_awake(autosleep_ws);
  10:  
  11:         mutex_lock(&autosleep_lock);
  12:  
  13:         autosleep_state = state;
  14:  
  15:         __pm_relax(autosleep_ws);
  16:  
  17:         if (state > PM_SUSPEND_ON) {
  18:                 pm_wakep_autosleep_enabled(true);
  19:                 queue_up_suspend_work();
  20:         } else {
  21:                 pm_wakep_autosleep_enabled(false);
  22:         }
  23:  
  24:         mutex_unlock(&autosleep_lock);
  25:         return 0;
  26: }

a)判断state是否合法。

b)调用__pm_stay_awake,确保系统不会休眠。

c)将state保存在一个全局变量中(autosleep_state)。

d)调用__pm_relax,允许系统休眠。

e)根据state的状态off还是其它,调用wakeup events framework提供的接口pm_wakep_autosleep_enabled,使能或者禁止autosleep功能。

f)如果是使能状态,调用内部接口queue_up_suspend_work,将suspend work挂到autosleep workqueue中。

 

注2:由这里的实例可以看出,此时wakeup source不再是wakeup events的载体,而更像一个lock(呵呵,Android wakelocks的影子)。

注3:
该接口并没有对autosleep state的当前值做判断,也就意味着用户程序可以不停的调用该接口,设置autosleep state,如写“mem”,写“freeze”,写“disk”等等。那么suspend work将会多次queue到wrokqueue上。
而在多核CPU上,普通的workqueue是可以在多个CPU上并行执行多个work的。这恰恰是autosleep所不能接受的,因此autosleep workqueue就必须是orderd workqueue。所谓ordered workqueue,就是统一时刻最多执行一个work的worqueue(具体可参考include\linux\workqueue.h中的注释)。
那我们再问,为什么不判断一下状态内?首先,orderd workqueue可以节省资源。其次,这样已经够了,何必多费心思呢?简洁就是美。

pm_wakep_autosleep_enabled主要用于更新wakeup source中和autosleep有关的信息,代码和执行逻辑如下:

   1: #ifdef CONFIG_PM_AUTOSLEEP
   2: /**
   3:  * pm_wakep_autosleep_enabled - Modify autosleep_enabled for all wakeup sources.
   4:  * @enabled: Whether to set or to clear the autosleep_enabled flags.
   5:  */
   6: void pm_wakep_autosleep_enabled(bool set)
   7: {
   8:         struct wakeup_source *ws;
   9:         ktime_t now = ktime_get();
  10:  
  11:         rcu_read_lock();
  12:         list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
  13:                 spin_lock_irq(&ws->lock);
  14:                 if (ws->autosleep_enabled != set) {
  15:                         ws->autosleep_enabled = set;
  16:                         if (ws->active) {
  17:                                 if (set)
  18:                                         ws->start_prevent_time = now;
  19:                                 else
  20:                                         update_prevent_sleep_time(ws, now);
  21:                         }
  22:                 }
  23:                 spin_unlock_irq(&ws->lock);
  24:         }
  25:         rcu_read_unlock();
  26: }
  27: #endif /* CONFIG_PM_AUTOSLEEP */

a)更新系统所有wakeup souce的autosleep_enabled标志(太浪费了!!)。

b)如果wakeup source处于active状态(意味着它会阻止autosleep),且当前autosleep为enable,将start_prevent_time设置为当前实现(开始阻止)。

c)如果wakeup source处于active状态,且autosleep为disable(说明这个wakeup source一直坚持到autosleep被禁止),调用update_prevent_sleep_time接口,更新wakeup source的prevent_sleep_time。

queue_up_suspend_work比较简单,就是把suspend_work挂到workqueue,等待被执行。而suspend_work的处理函数为try_to_suspend,如下:

   1: static DECLARE_WORK(suspend_work, try_to_suspend);
   2:  
   3: void queue_up_suspend_work(void)
   4: {
   5:         if (autosleep_state > PM_SUSPEND_ON)
   6:                 queue_work(autosleep_wq, &suspend_work);
   7: }

4.4 try_to_suspend

try_to_suspend是suspend的实际触发者,代码如下:

   1: static void try_to_suspend(struct work_struct *work)
   2: {
   3:         unsigned int initial_count, final_count;
   4:  
   5:         if (!pm_get_wakeup_count(&initial_count, true))
   6:                 goto out;
   7:  
   8:         mutex_lock(&autosleep_lock);
   9:  
  10:         if (!pm_save_wakeup_count(initial_count) ||
  11:                 system_state != SYSTEM_RUNNING) {
  12:                 mutex_unlock(&autosleep_lock);
  13:                 goto out;
  14:         }
  15:  
  16:         if (autosleep_state == PM_SUSPEND_ON) {
  17:                 mutex_unlock(&autosleep_lock);
  18:                 return;
  19:         }
  20:         if (autosleep_state >= PM_SUSPEND_MAX)
  21:                 hibernate();
  22:         else
  23:                 pm_suspend(autosleep_state);
  24:  
  25:         mutex_unlock(&autosleep_lock);
  26:  
  27:         if (!pm_get_wakeup_count(&final_count, false))
  28:                 goto out;
  29:  
  30:         /*
  31:          * If the wakeup occured for an unknown reason, wait to prevent the
  32:          * system from trying to suspend and waking up in a tight loop.
  33:          */
  34:         if (final_count == initial_count)
  35:                 schedule_timeout_uninterruptible(HZ / 2);
  36:  
  37:  out:
  38:         queue_up_suspend_work();
  39: }

该接口是wakeup count的一个例子,根据我们在“Linux电源管理(8)_Wakeup count功能”的分析,就是read wakeup count,write wakeup count,suspend,具体为:

a)调用pm_get_wakeup_count(block为true),获取wakeup count,保存在initial_count中。如果有wakeup events正在处理,阻塞等待。

b)将读取的count,写入。如果成功,且当前系统状态为running,根据autosleep状态,调用hibernate或者pm_suspend,suspend系统。

d)如果写count失败,说明读写的过程有events产生,退出,进行下一次尝试。

e)如果suspend的过程中,或者是suspend之后,产生了events,醒来,再读一次wakeup count(此时不再阻塞),保存在final_count中。

f)如果final_count和initial_count相同,发生怪事了,没有产生events,竟然醒了。可能有异常,不能再立即启动autosleep(恐怕陷入sleep->wakeup->sleep->wakeup的快速loop中),等待0.5s,再尝试autosleep。

4.5 pm_autosleep_state

该接口比较简单,获取autosleep_state的值返回即可。

<think>我们正在讨论Linux内核中的初始化机制,特别是`pm_init`函数以及`__init`和`core_initcall`的含义。根据引用[1]和[2],我们知道内核使用`initcall`机制来管理不同阶段的初始化函数。这些初始化函数被分为不同的级别,比如`core_initcall`、`subsys_initcall`等。 用户的问题是关于`pm_init`函数的,但引用中并没有直接提到`pm_init`,而是提到了`register_cpufreq_notifier`和`mmc_init`作为例子。因此,我们需要结合已知的初始化机制来解释。 首先,我们分解问题: 1. `pm_init`函数:这是电源管理(Power Management)的初始化函数。它负责初始化内核的电源管理子系统。 2. `__init`:这是一个宏,用于标记只在初始化阶段使用的函数和数据结构。被标记为`__init`的代码在初始化完成后会被释放,从而节省内存。 3. `core_initcall`:这是一个宏,用于将函数放入特定的初始化段中,使得内核在启动时按照一定的顺序(从`core_initcall`到`device_initcall`等)调用这些函数。`core_initcall`是其中最早被调用的级别之一。 现在,假设`pm_init`函数在代码中是这样定义的: ```c static int __init pm_init(void) { // 初始化电源管理子系统 ... } core_initcall(pm_init); ``` **含义解释:** 1. **`__init`修饰符**: 表示`pm_init`函数只在系统初始化期间使用,当初始化完成后,该函数所占用的内存会被内核释放。 2. **`core_initcall`宏**: 将`pm_init`函数标记为“核心初始化调用”级别。这意味着它会在内核启动过程的早期阶段被调用,具体来说,是在`core_initcall`级别的函数中执行。这个级别通常用于初始化内核中非常重要的核心子系统,比如电源管理、调度器等。 3. **初始化顺序**: 内核的初始化调用分为多个级别(定义在`include/linux/init.h`中),按顺序执行: - `early_initcall`:最早,用于非常早期的初始化。 - `core_initcall`:核心初始化,如电源管理- `postcore_initcall`:核心初始化之后。 - `arch_initcall`:架构相关的初始化。 - `subsys_initcall`:子系统初始化(如MMC框架的初始化,如引用[2]中的`mmc_init`)。 - `fs_initcall`:文件系统初始化。 - `device_initcall`:设备初始化。 - `late_initcall`:最后阶段。 因此,`core_initcall(pm_init)`保证了电源管理子系统在内核启动的早期就被初始化,这样后续的子系统(比如设备驱动)就可以依赖它。 **作用:** `pm_init`函数的主要作用是初始化内核的电源管理框架。这包括: - 初始化电源管理相关的数据结构。 - 注册sysfs接口(例如,在`/sys/power/`目录下创建属性文件,如之前讨论的`kobject_create_and_add("power", NULL)`)。 - 设置电源管理的事件处理机制(如休眠、唤醒等)。 **引用说明:** - 引用[1]说明了`core_initcall`的使用方式,例如`core_initcall(register_cpufreq_notifier)`,这类似于`pm_init`的注册方式。 - 引用[2]提到`subsys_initcall(mmc_init)`,这属于比`core_initcall`稍晚的初始化级别(subsys_initcall),说明不同子系统根据其重要性被安排在不同阶段初始化。 **总结:** `pm_init`函数是电源管理子系统的初始化函数,使用`__init`修饰表示它仅在初始化阶段存在,使用`core_initcall`宏将其放入核心初始化阶段,确保在内核启动早期执行,为其他子系统提供电源管理支持。 --- ### 相关问题 1. 内核初始化调用(`initcall`)有哪些级别?它们的执行顺序是怎样的? 2. 为什么电源管理子系统(`pm_init`)需要使用`core_initcall`级别? 3. 被标记为`__init`的函数在初始化完成后如何处理? 4. 如何在内核中添加一个新的初始化函数,并指定它在某个特定阶段执行?</think>### Linux 内核中 `pm_init` 函数及相关初始化机制解析 #### 1. **`__init` 宏的作用** - **内存优化**: 标记函数或数据结构仅在内核初始化阶段使用,初始化完成后自动释放其内存空间[^1]。 ```c static int __init pm_init(void) { ... } // 函数内存将在初始化后回收 ``` - **防止误用**: 避免在初始化阶段后调用这些函数,确保内核运行时稳定性。 #### 2. **`core_initcall` 宏的作用** - **初始化顺序控制**: 属于 Linux 内核的 `initcall` 机制,将函数注册到**核心初始化阶段**(优先级 2)[^1][^2]。 - **执行时机**: 在 `early_initcall`(优先级 1)之后、`subsys_initcall`(优先级 4)之前执行,顺序如下: ```plaintext early_initcall → core_initcall → postcore_initcall → arch_initcall → subsys_initcall ``` - **典型应用场景**: 用于初始化内核核心子系统(如电源管理、调度器),为后续子系统提供基础支持[^2]。 #### 3. **`pm_init` 函数的作用** - **电源管理框架初始化**: - 创建 sysfs 接口(如 `/sys/power/` 目录) - 注册电源管理事件处理机制(如休眠/唤醒) - 初始化电源管理核心数据结构 - **依赖关系示例**: ```c core_initcall(pm_init); // 电源管理核心初始化 subsys_initcall(mmc_init); // MMC 存储子系统初始化(依赖电源管理)[^2] ``` #### 4. **完整初始化流程解析** ```mermaid graph LR A[内核启动] --> B[early_initcall] B --> C[core_initcall] --> pm_init C --> D[postcore_initcall] D --> E[arch_initcall] E --> F[subsys_initcall] --> mmc_init F --> G[设备驱动初始化] ``` - **关键阶段**: 1. `core_initcall`:初始化核心基础设施(如 `pm_init`) 2. `subsys_initcall`:初始化子系统(如 MMC/SDIO 总线)[^2] 3. 设备驱动初始化:最后阶段加载具体硬件驱动 #### 5. **设计意义** - **模块化分层**: 通过 `initcall` 级别实现“内核核心 → 子系统 → 驱动”的分层初始化[^3]。 - **依赖管理**: 确保基础设施(如电源管理)先于依赖它的子系统(如存储)初始化[^2]。 - **性能优化**: `__init` 宏回收内存,减少内核运行时占用[^1]。 --- ### 相关问题 1. **`core_initcall` 和 `subsys_initcall` 有何区别?** (提示:核心基础设施 vs. 功能子系统,执行顺序差异) 2. **如何在内核中添加自定义初始化函数并控制其执行顺序?** (示例:使用 `device_initcall` 注册设备驱动初始化) 3. **`__init` 宏如何实现内存回收?其底层机制是什么?** (提示:链接脚本中的 `.init.text` 段) 4. **电源管理初始化失败会对系统产生什么影响?** (关联:休眠功能失效、设备功耗控制异常) [^1]: `__init` 和 `core_initcall` 用于内核初始化阶段的内存管理和执行顺序控制。 [^2]: 子系统初始化(如 MMC)通过 `subsys_initcall` 注册,依赖核心设施(如电源管理)。 [^3]: 内核初始化采用分层模型,从核心到驱动逐级构建。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值