RFC-0255：系统活动调节器

RFC-0255：系统活动调节器
状态已接受
领域
  • 电源
说明

定义一个组件，该组件利用电源拓扑概念管理平台的挂起状态。
问题
Gerrit 更改
作者
审核人
提交日期（年-月-日）2024-05-07
审核日期（年-月-日）2024-08-02

修改此 RFC

修改 RFC 元数据

摘要

此 RFC 建议添加一个名为“系统活动调节器 (SAG)”的核心组件 管理系统的电源级别。本文档介绍了 SAG 的概念、其政策，以及实现过程中用于实现 系统电源电平的管理。此 RFC 可视为 RFC-0230: Suspend-To-Idle in Fuchsia 的实现。

目标

  • 启用对发生挂起到空闲的管理的管理。
  • 提供暂停方面的统计数据，以便日后进一步改善电力供应， 启用监控舰队范围内的功耗。

非目标

  • 实现特定硬件系统到不同电源状态的转换 包括但不限于 CPU、GPU、内存、网络接口等。
  • 实现触发任务暂停的逻辑，例如zx_system_suspend_enter。

设计初衷

Fuchsia 是一个通用型操作系统，旨在支持多种多样的 生态系统。为了满足对功率敏感的需求 硬件和软件，Fucsia 必须能够管理 以及运行应用的硬件平台这包括 将 CPU 转换到低功耗模式、触发系统级任务暂停、 激活内存自刷新以及任意数量的其他省电硬件 功能。一组旨在降低功耗的硬件配置或状态 用量被划分到一个概念，称为“挂起状态”。

许多系统都支持多种挂起状态。每种挂起状态都有一组 硬件状态、电源使用情况和恢复延迟时间（退出 挂起状态）。每个系统都可以在概念中定义相同的挂起状态 （挂起到空闲）映射到完全不同的硬件集 配置。

例如，Fuchsia 可能在具有不同 CPU 的两个系统上运行。1 个 CPU 可以支持的功耗状态低于另一个状态； 不过，两个系统都可能会将过渡到最低电源状态 使其进入“挂起到空闲”状态。

在考虑这一主题时，该平台的状态如下所示：

  • RFC-0230：Fuchsia 中的挂起到空闲定义了简要要求和 “挂起到空闲”的设计这是目前唯一的挂起状态 支持 Fuchsia 平台。
  • RFC-0250：电源拓扑定义了支撑未来的电源拓扑 Fuchsia 的电源管理系统。
  • 单独的 RFC 定义了管理电源拓扑的组件 运行时：Power Broker。
  • 必须解读来自不同子系统的各种信号， 过渡到“挂起到空闲”。

为了实现 RFC-0230: Suspend-To-Idle in Fuchsia（使用 RFC-0250：电源拓扑，一个组件，用于实现要管理的政策 需要创建“挂起到空闲”的转换：系统活动调节。

利益相关方

教员：

Adam Barth abarth@google.com

审核者：

已咨询：

社交化：

与负责 包括内核、驱动程序、驱动程序框架、组件框架、产品政策和 电源框架

要求

支持转换为挂起状态的系统必须支持 Fuchsia 产品以及挂起状态的硬件要求。接收者 适当地促成过渡，使其暂停，同时保持 产品，SAG 必须满足以下要求：

  1. Fuchsia 组件（包括驱动程序）必须能够防止转换 在关键操作正在进行时暂停。例如，假设 用户观看视频的场景设备不应尝试 在视频播放时挂起系统；否则 糟糕的体验
  2. 为实施产品驱动的中止政策，有关中止的统计信息 必须收集和公开数据。例如，假设有一款产品 只能在事件发生后至少 1 秒内触发 之前的简历。为了让产品组件支持这一功能， 必须能够计算距离上次恢复过渡的时间。

  3. SAG 仅负责确定何时进行过渡。通过 向每种挂起状态的过渡的定义和协助 由实现 fuchsia.hardware.suspend.Suspender 协议。此 RFC 推迟 用于定义完整协议，但 Suspender 必须提供以下内容 功能：

    • 列出硬件支持的挂起状态。
    • 将硬件转换为挂起状态。

在此设计中，SAG 充当着系统 执行代码，由 Fuchsia Suspend HAL（用于实现 上述 Suspender 协议）将系统转换为挂起状态。 为适应这一概念，我们做出以下假设：

  • 硬件平台是指硬件和软件的集合 可让计算设备执行此 RFC 中的代码的系统。这个 通常包括 CPU、内存、操作系统 （时钟树、电源域等）。这个 明确不包含传统的外围组件，如 微控制器装置、无线装置、显示屏控制器、辅助存储设备 （固态硬盘、eMMC）等
  • 所有要实现以下目的的产品中都必须存在电源代理组件 支持硬件平台暂停。
  • 在暂停期间，Fuchsia 组件不会在 CPU 上执行 包括 SAG 本身。在微控制器或其他 外围设备硬件可以继续处理数据。当硬件平台 进入挂起状态，CPU 可以离线，调度器可以 更新其政策，而外围设备可以更改配置。
  • Fuchsia 组件必须（直接或间接）与电源 拓扑以允许和/或阻止转换暂停。这种集中式的 会计机制使 SAG 能够了解系统的其余部分需要什么 而无需知道这些组件的状态。
  • 未与电源拓扑集成的 Fuchsia 组件不得 不会出现中断的执行。这需要用到任何预期 不间断执行以执行关键任务（例如，接收数据 以解决由 Google 暂停的硬件平台， 在其中一个方法中与电源框架直接或间接交互 请参阅防止暂停。
  • 当发生唤醒中断时，硬件平台不得挂起 待处理。这对所有驾驶员都很重要，因为这让他们有机会 而不受其与电源交互的影响 框架。在确认中断后需要执行更多处理的驱动程序 必须与电源框架交互，以防止硬件平台 暂停。
  • SAG 必须可供功耗感知型驱动程序和紧急组件使用 且存在于内核读取的第一个文件系统中（例如：bootfs， 来自 RFC-0167：早期用户空间中的软件包 引导用户）。如果没有自定义组件， 将无法设置电源配置来阻止 系统暂停服务，直到 SAG 之后可用。此外，在 挂起转换，则可以配置更高级别的文件系统， 低于较低级别文件系统中的驱动程序关闭。 这会造成电源元素依赖关系问题。
  • SAG 会推动硬件平台实现最低功率水平 尽可能使用电源拓扑概念。归根结底， 设备是否进入/保持在最低电量水平取决于产品 行为和政策、环境条件以及用户行为。

设计

系统活动调节器由以下部分组成：

  1. 力量元素
  2. 用于初始化、状态管理和电源处理的业务逻辑 更改。
  3. FIDL 服务，用于提供对挂起/恢复相关统计信息的访问权限。
  4. FIDL 服务可让客户端使硬件平台保持唤醒状态， 获得暂停/恢复转换的通知。

FIDL 服务的确切定义将取决于 API 评估/校准会议。

电源拓扑

如需了解电源拓扑图惯例，请参阅 RFC-0250：电源拓扑。

电源拓扑 图表

SAG 会创建和管理电源元素 Execution State，它代表 硬件平台执行代码的能力。这种力量元素 汇总来自其他组件的信号，以确定何时挂起过渡 。

通过制作强效元素，SAG 可让其他组件：

  • 提高硬件平台执行状态的功率电平， 只要他们持有坚实的声明
  • 说明硬件平台应继续执行代码的原因 通过电源元素及其依赖项链
  • 保留机会性声明，以响应执行状态的变化。 这也使得 SAG 实现能够产生副作用来响应 每个依赖 Execution State 的功率电平变化。
  • 最重要的是，RFC-0250：电源拓扑要求使用电源元件 往往朝着最低的功率水平。这自然而然会产生治理 无依赖电源时对硬件平台的执行状态执行的操作 有效。

执行状态

此功率元素会尽可能映射到硬件平台的 执行代码的能力。它支持 3 种功率级别：

  • 活跃
  • 正在暂停
  • “Inactive”（无效）

当硬件平台正常运行时，此元素预计为 处于 Active 功率级。当处于 Inactive 电源级别时，硬件 平台应处于挂起状态或主动尝试 过渡到挂起状态。仅限设备不感知电量的部件 此时应运行与电源无关。请参阅限制设备 按执行状态”部分，详细了解 这种设计模式。如需详细了解何时暂停，请参阅暂停/恢复 以及挂起的触发方式

Suspending 功率等级介于 Inactive 和 Active 的功率之间 级别。此电源级别旨在分隔只有 在硬件平台运行时，以及可能需要 在硬件平台在挂起状态和 运行状态（两个方向）。请参阅 Storage 示例 以了解这种区别的适用情形。

设计模式

防止暂停

为防止硬件平台挂起，组件可以构建一个 具有明确自信的力量元素 Execution State上的依赖项。

假设某款产品具有媒体播放器功能。产品所有者想要 媒体播放，以防止硬件平台挂起，从而 支持连续播放音乐。为了支持此功能， 可以创建对 Execution State 的断言依赖项，以防止 SAG 触发挂起过渡。

防止通过执行状态挂起 图表

在上图中，媒体播放器组件有一个名为 播放。播放功率元素对 Active 有断言依赖 Execution State 的电量。当需要开始播放媒体时，媒体 玩家组件将请求租借 Playback 的 Active 电量 以防止硬件平台挂起待租期结束后 媒体播放器组件无需 而无需担心硬件平台意外挂起

按执行状态限制设备

产品可以采用的一种强有力的模式是限制设备的功率 按硬件平台的执行状态划分级别它可用于将 外围设备功耗降低到硬件平台挂起状态。如 硬件平台转换为挂起状态，驱动程序可以关闭其设备 或更改其配置此设置可能适用于想要 在硬件平台挂起时关闭特定功能或子系统 以降低功耗。

音频示例

考虑选用高功耗音频硬件的产品。仅限产品所有者 希望在硬件平台唤醒时激活音频硬件。通过 产品所有者可以使用具有 机会性依赖 Execution State。

按执行状态限制设备 图表

在上图中，音频驱动程序（图中称为音频）的功率为 一个称为“Power”的元素音频驱动程序对 Active 的功率等级为 Execution State。音频驱动程序可以监控 向 Power Broker 请求租借，从而满足这些依赖项需求。时间 Execution State 转换为 Active（电源时音频驱动程序的租约） 将得到满足此时，音频驱动程序可以运行 需要激活音频硬件。反之，当 Execution State 想要 从 Active 降低其功率电平，那么音频驱动程序的电源租用就变成了 不满意。此时，音频驱动程序可以运行逻辑来停用 音频硬件，然后再通知 Power Broker 其电源元件已掉电 其功率水平。

处理唤醒中断

硬件平台暂停后，可由外部 刺激因素。这种外部刺激通常以 CPU 中断的形式出现 由其中一个外围组件抬起。为了正确处理唤醒 中断时，预计会出现以下情况：

  • 司机的唤醒矢量已在暂停前某个时间点编程。
  • 处理中断时： <ph type="x-smartling-placeholder">
      </ph>
    1. 如果驱动程序在端口上等待中断，则其中断处理程序 由内核调度。
    2. IHT 或其通知的其他组件可以创建 硬件平台暂停。
    3. 驱动程序与硬件和/或其他组件进行通信， 处理中断所需的资源在此期间，其他组件 。
    4. 中断处理完成后，驱动程序会调用 zx_interrupt_ack。
。

在处理中断时，SAG 可以在内核启动之后的任何时间运行 恢复在硬件平台转换为 暂停。

存储示例

以根据以下条件限制设备：中的音频示例 执行状态 。存储期间 硬件可以遵循与通常关闭时类似的音频模式 硬件平台挂起时，硬件平台也会关闭， 平台过渡到挂起或恢复状态，以服务唤醒中断。 如果当前被调出的组件需要接通电源，则可能会导致问题。 并在暂停前执行清理操作。由于 断电操作是不确定的，这种简化的设计 不足。

要解决这一问题，一种方法是允许存储驱动程序在运行时 状态。

增加存储空间 图表

在上图中，名为“存储”的存储驱动程序有两倍电耗 元素：

  • 权力依赖于机会性依赖（执行状态、挂起）。 当另一个功率元素提高 Execution State 的功率水平时，将满足此依赖关系。只要存储驱动程序在电源上保持租用 执行状态加电至 Suspending，执行状态无法丢弃其 功率级别。为使存储驱动程序能够监视 应关闭。
  • 唤醒请求对（执行状态、 暂停）。此依赖项会强制 Execution State 提高其功率 。存储驱动程序在收到 存储空间请求。必须执行此操作，存储硬件才能启动 即使系统的其他部分断电也没关系

处理系统级转换

启动

SAG 首次启动后，只有在系统 已完成启动过程在这种启动状态下，Execution State 功率元素预计为 Active 功率电平，以反映 硬件平台正在活跃运行， 暂停。

在此期间，其他组件可以创建依赖项和租期， 影响 Execution State；不过，Execution State 将始终位于 启动完成前，电池电量还剩 Active。为了退出启动状态， 必须通知 SAG 托管的 FIDL 服务启动已完成。这个 当应用的较高层 其电力需求，例如由会话触发。

暂停/恢复

当 Execution State 电平处于以下状态时，将请求挂起转换 Inactive，最低功率等级。在开始暂停过渡之前，SAG 将告知注册的监听器即将进行挂起。正确 处理自身、Power Broker 和中断处理之间的潜在争用 驱动程序，SAG 需要满足以下要求：

  • 如果唤醒中断 已确认。这样可以防止出现 SAG 在中断处理程序之前运行的竞态 有机会请求租用并确认中断。
  • 在暂停期间，SAG 不得更改 Execution State 的功率等级 请求正在处理中。当 SAG 从挂起状态恢复时， Execution State 应始终为 Inactive。依赖于 Execution State将转换至并维持在适当的电量水平 暂停。SAG“锁定”力量 Execution State 级别，以确保通过延迟处理电源 Power Broker 请求的级别更改。
  • 驱动程序或中断处理程序必须先获得租用，然后对其执行 ACK 操作。 中断。

当硬件平台恢复执行时，SAG 将收到 表示挂起请求结果的 Suspender 设备。SAG 将 然后向已注册的监听器告知挂起请求的结果。那时 监听器可以请求租期来阻止硬件平台暂停。 如需了解详情，请参阅防止暂停。

在转换发生之前，挂起请求也有可能失败。 这可能是由待处理中断所导致，该中断会立即唤醒 硬件平台或 Fuchsia Suspend HAL 或内核中的其他错误。当 挂起请求失败，SAG 会通知监听器失败并等待监听器 确认通知此设置允许使用产品级组件 来请求租借和更改系统配置 但最终会失败的挂起请求

如果在播放期间没有监听器提高 Execution State 的功率电平，请执行以下操作： 则 SAG 会记录此故障。这种情况可能会发生 监听器的崩溃次数或 产品体验。

暂停/恢复 图表

关闭

当系统中运行的组件请求关闭或重新启动时， 组件管理器开始根据功能图终止组件。 这会导致硬件平台无法运行的组件 会在 SAG 之前终止。这会导致 SAG 在关停过程中错误地触发暂停。

为了解决这个问题，负责协调关停工作的组件 （shutdown-shim 和/或 power-manager）必须持有将 Execution State 保持在 Suspending 功率水平的租约。自 shutdown-shim 起 power-manager 是在启用“确认点击”机制之前 重新启动，这样可以防止错误的暂停。

实现

添加此功能需要从关键 在完全实现之前对子系统进行测试。可以细分为 执行下列步骤：

  1. 基本挂起支持 <ph type="x-smartling-placeholder">
      </ph>
    • 在 Execution State 变为 Inactive 时触发挂起
    • 接收简历时发送监听器通知。
    • 连接使系统保持唤醒状态的恢复通知的监听器。
  2. 当 SAG 接口变为能感知型时，将所有关键子系统连接到 SAG 接口。
  3. 优化挂起时间。
    • 公开存在来自内核的中断和/或其他唤醒条件 和/或 Fuchsia Suspend HAL。
    • 使用内核/Fuchsia Suspend HAL 信号来延迟触发挂起 预期会失败的请求
  4. 持续集成其他挂起感知型子系统。

性能

对系统性能的总体影响很大程度上取决于 Power Broker。SAG 的大多数客户会在通话期间进行一次性通话 通过初始化来设置依赖项，未来互动是间接的， 由 Power Broker 负责提供支持。监听 SAG 事件的客户端 会直接影响系统性能，因为它们必须确认对 恢复和暂停失败通知。我们应该密切监控延迟时间 指标，以确保恢复和挂起失败 及时处理。最后，触发 挂起由 Fuchsia Suspend HAL 报告。我们应该监控 确保暂停操作在所有产品中及时完成。 这包括监控撤消暂停对延迟时间和性能的影响 请求。

安全注意事项

RFC-0250：电源拓扑建立的电源框架定义了 一种用于电源拓扑的安全模型。SAG 通过 协议功能访问此协议将允许其他能量元素 依赖 SAG 的能量元素。最终，SAG 的安全依赖于 组件框架提供的用于路由协议的保证 功能。

SAG 具有基于 Fuchsia Suspend HAL 和 Power 的协议功能依赖项 经纪人。这些组件如果与预期行为有任何偏差，都可能导致 SAG 实现中的不当行为。SAG 需要考虑到缺失和 行为不当的依赖项，以降低负面级联的可能性 效果。

注册监听器的客户端可能会遭到滥用。恶意 组件可能通过不确认 。您可以通过使用 响应超时。

隐私注意事项

我们预计 SAG 不会收集任何个人身份信息； 不过，Google 会收集并公开因挂起/恢复行为而产生的数据 和 Inspect。这些数据会汇总到 供产品所有者和 Fuchsia 工程师进行分析。这个 在植入过程中需要接受隐私权审核。

测试

SAG 将由一系列集成测试和端到端测试进行测试。 集成测试将确保 SAG 在内部状态之间转换并发送 正确挂起请求

客户端可以使用一组测试支持库来测试其实现， 使用了 Power Broker 和 SAG，但移除了 Fuchsia Suspend HAL。此测试支持 库将允许客户端调用 SAG 中的特定状态，以确保客户端 组件才能正确响应这些更改。这包括确保 并适当处理由功率等级转换触发的效果。答 针对依赖 SAG 电源元素的组件的完整测试套件， 包括以下场景：

  • 无电源框架
  • 初始启动状态下的 SAG 和锁定的电量
  • 电池电量为 Execution State，电量为 Active
  • 电池电量为 Execution State，电量为 Suspending
  • 电池电量为 Execution State，电量为 Inactive
  • （如果适用）在关键操作期间不得暂停

文档

您将需要提供大量文档来解释 SAG 在系统中的作用， 配置（包括产品所有者的期望）、API 模式以及 测试支持库文档应包含示例和最佳 有关操作 SAG 电源元素并正确使用其 API 的实践。 示例应包含设计 格式部分。

本文档应是更多 API 文档的一部分， 框架及其概念。

缺点、替代方案和未知问题

实施此方案的缺点基于 框架。

触发挂起的信号是分散的。任何组件都不能 保证此 API 会遭到暂停，除非商品所有者 来强制实施此模式这使得系统的行为 且含义模糊。例如，当某个组件 在 Execution State 具有租赁关系的租期被撤消后，如果存在以下情况，SAG 可能不会中止： 其他组件都有租期组件只知道触发了挂起 方法是向 SAG 注册监听器，这会增加复杂性。

RFC-0230: Suspend-To-Idle in Fuchsia 中记录了以下内容：

如果用户空间提供了恢复延迟要求，Fucsia 应 都一样如果未提供恢复延迟时间，Fucsia 应输入 挂起到空闲，尽可能缩短恢复延迟时间。

此 RFC 未考虑此要求，因为只有一个挂起状态 平台当前支持的平台类型。

我们尚未找出所有可能存在的电源控制模式， 因此，此设计可能需要随着这些 模式。这包括但不限于恢复延迟时间 考虑、支持更多挂起状态等。这些设计变更将 根据需要编入后续 RFC。

先验技术和参考资料