Linux调度器QoS框架的实现路线图：解决用户空间辅助调度的挑战

Linux Plumbers Conference

引言与背景 [00:00:00]

Linux调度器面临的挑战 [00:00:40]

• 现代工作负载和系统对调度器提出了更高要求：
  • 服务器不再只运行一种工作负载。
  • Android和桌面等通用交互式系统日益增多。
  • 相同的工作负载在性能和功耗方面具有不同能力的硬件和架构上运行。
• 历史偏向吞吐量：
  • Linux调度器历史上主要受服务器市场贡献，导致对吞吐量有一定偏向。
  • 交互性变得越来越重要，用户对此多有抱怨，但平衡二者非常困难。
• 应用编写方式的局限性：
  • 应用程序编写方式“老旧”，常假定自己是系统的唯一用户，导致可能创建过多线程，对系统不友好。
  • POSIX标准未能及时更新，以指导开发者更好地编写适应多样化硬件和工作负载的应用程序。

单一调度器应对多样化需求 [00:01:51]

• 演讲者认为，无需引入全新的调度器，通过提供更多信息，现有调度器可以做出更智能的决策。
• Sched QoS中间件库被视为解决此问题的关键工具。
• 重点在于如何获取这些额外信息，并提出了一系列建议，大部分属于中间件层，但也涉及内核问题。

  

QoS实现路线图 [00:02:40]

• 实现完整的用户空间辅助调度QoS框架需要同时解决以下多个问题：
  1. QoS管道框架: 调度器需要公开哪些QoS接口，以及如何将其与更高层次的QoS封装，以供最终应用程序用户使用。
  2. 多模式唤醒与负载均衡: 唤醒路径和负载均衡决策需要具备多模式，因为任务放置决策现在可能受到用户选择的影响。
  3. 简易采纳/部署: 重写整个用户空间不切实际且耗时。需要一种简单机制，无需应用程序选择加入即可应用QoS。
  4. 调度器默认值: QoS并非改进调度器行为的替代方案。需要审视默认值，并根据不同系统/期望进行调整。
  5. 通用性能继承支持: 缺乏此支持，其有效性可能会受到严重影响，因为性能和优先级反转问题在实践中很常见。
  6. 访问控制: 管理员、应用程序和用户之间的控制和优先级机制。用户可能想要某些东西，应用程序可能请求某些东西，而管理员可能想要强制执行其他东西。

     

QoS管道与映射 [00:04:17]

QoS接口与应用描述 [00:04:22]

• 重点应放在如何以可移植和可扩展的方式通用描述应用程序，而不是关注内核接口本身。
• 借鉴行业现有解决方案：苹果提供了简单的QoS API/类别，允许用户描述其工作负载，并获得了良好反馈。
• 目标是抽象化内核细节，通过一个中间件（如skitts中间件）将高级应用描述映射到内核。

QoS类别及其内核实现映射 [00:05:50]

• 基于苹果模型的四种QoS类别：
  • 用户交互 (User Interactive): 需要立即响应的任务（例如，8毫秒的切片时间，DVFS响应乘数为8）。
  • 用户发起 (User Initiated): 重要但可接受轻微延迟的任务（例如，10毫秒的切片时间，DVFS响应乘数为4）。
  • 实用工具 (Utility): 轻量级后台任务，可接受长延迟但需避免过度延迟（例如，16毫秒的切片时间，批量策略，DVFS响应乘数为2）。
  • 后台 (Background): 不关心延迟的任务（例如，20毫秒的切片时间，批量策略，DVFS响应乘数为1）。
• 默认行为： 未指定QoS的任务应默认运行为“实用工具”，以减少系统噪音，更容易为重要任务提供QoS保障。
• 映射机制:
  • runtime：管理EEVDF中的切片大小，控制任务延迟。
  • policy_SCHED_BATCH：用于控制唤醒抢占，防止后台任务不必要地抢占重要任务。
  • sched_max：用于性能层级管理，适用于电源管理和热量控制。
  • ramp_multiplier：一个新元素，用于管理DVFS（动态电压和频率缩放）响应时间，使CPU频率更快提升或降低，以满足性能需求。

    

用户交互性与周期性需求 [00:11:00]

• 为了更好的可移植性，应用程序应告知调度器其工作“周期 (PERIOD)”。
• 例如，一个游戏可以声明其帧率（例如240Hz，对应4毫秒周期），调度器可据此更积极地调度。
• 如果应用程序周期较长（例如30Hz，对应33毫秒），调度器可将其视为不那么紧急的任务。
• 此“周期”信息可传递给内核，让调度器在用户空间之外进行更智能的决策，如提升任务的climman或进行其他优化，以提供更好的性能保证。
• 强调这是关于“软实时”的性能QoS，而非严格的硬实时。

  

统一任务放置决策树 [00:20:01]

当前唤醒路径的局限性 [00:20:07]

• 当前的唤醒路径（任务放置决策）主要基于负载、能耗、NUMA等因素。
• 现有机制缺乏对延迟的考量，例如EEVDF侧重于负载分配，而非延迟最优。
• 缺少统一的决策树，未能有效整合内存亲和性、缓存感知调度等多样化需求。

改进方向 [00:22:21]

• 每任务周期性负载均衡/推送回调机制:
  • 当前的周期性负载均衡在某些情况下有效，但对于交互性需求不足，因为它基于CPU间的全局负载，而非任务的优先级。
  • 借鉴实时（RT）和截止日期（deadline）调度器中的每任务推送算法。
  • 在调度器中引入每任务推送回调机制，当任务从运行状态变为可运行状态时，检查是否应迁移到其他CPU，以确保更快执行。
• 统一唤醒与负载均衡函数:
  • 唤醒路径和负载均衡应使用完全相同的CPU选择函数和算法，确保决策的一致性，避免冲突。
  • 负载均衡需考虑负载、能耗、延迟等多维因素，而非仅负载。
• 短切片优先的CPU选择:
  • 当任务唤醒时，如果它拥有最短的切片，应优先选择空闲CPU或当前运行着更长切片任务的CPU，从而抢占并快速运行。
  • 通过传播短切片任务而不是堆叠它们，可以提高公平性和响应速度。
• 用户估计的任务利用率:
  • 允许用户空间（通过SC_attribute）设置任务的运行时长和截止日期，提供CPU带宽信息。
  • 内核可以直接使用这些信息来确定正确的频率点或计算容量，而无需依赖自身的估算，从而加快响应速度并更准确地满足截止日期。
• CPU利用率跟踪的改进:
  • 调度器当前假设所有任务都是相同的，但任务可能受CPU、内存或IO限制。
  • 应跟踪任务的配置文件和行为，以更好地估算CPU利用率。
  • 例如，内存绑定任务在小型CPU上可能与大型CPU具有相同性能，避免在大型CPU上运行导致不必要的停顿周期。
• TLDR; 需要统一路径的重构，以便未来能够实现更智能的调度决策。 ![统一任务放置决策树以优化任务放置][121]

简易采纳与部署 [00:27:49]

API采纳的挑战 [00:28:00]

• 引入新的API需要很长的采纳周期，在Android等生态系统中，从引入到实际广泛使用可能需要12-18个月，甚至2-3年。
• 应用程序开发者需要修改代码，系统集成商需要更新相关软件，这大大增加了推广的难度和时间。

零API采纳机制：基于配置的提示 [00:28:33]

• 机制思想: 创建一种无需应用程序直接调用API即可描述QoS需求的机制，称之为“基于配置的提示 (config based hinting)”。
• 实现方式:
  • 通过一个配置文件（例如，针对Chrome）描述应用程序的QoS需求、任务角色和周期。
  • 利用netlink接口监听新任务的创建和名称更改事件。
  • 用户空间中的一个轻量级监听器可以根据配置文件匹配这些事件，并对任务进行相应的QoS标记。
• 优势:
  • 降低开发者门槛: 应用程序开发者无需修改代码，只需提供配置文件。
  • 加速采纳: 新的QoS功能可以更快地投入使用。
  • 简化内核实验: 内核开发者可以更容易地迭代和实验新的QoS提示或映射改进，无需等待应用程序更新。
  • 独立更新: 配置文件可独立于应用程序二进制文件进行更新。

    

API仍可能需要，但应尽量避免 [00:30:59]

• 对于周期性参数等动态变化的需求（例如，游戏中的帧率设置），静态配置可能不够灵活。
• 此时，可能需要提供一些API，允许应用程序动态调整QoS提示，但应尽量减少API的使用。
• 应用开发者视角: 应用程序开发者主要关注其自身应用范围内的性能权衡，而无需考虑整个系统。
• 系统管理员视角: 系统管理员应拥有覆盖应用程序QoS设置的权限，以防止应用程序滥用QoS请求，确保系统整体健康。
• 这种分层控制（应用内权衡，系统管理员覆盖）有助于简化问题空间，减少内核接口的复杂性。

调度器默认值 [00:37:40]

历史包袱与吞吐量偏向 [00:37:49]

• 调度器的默认值历史偏向于吞吐量，这对于交互式系统来说可能不是最优的。
• 每次尝试更改这些默认值以优化某一特定方面时，都可能在其他方面引入新的问题。

针对不同系统/期望的默认值调整 [00:38:00]

• 引入“旋钮”机制: 需要一个可调整的runtime旋钮来改变调度器的默认行为，而不是使用完全独立的调度器。
• 吞吐量系统:
  • 如果统一唤醒路径变得昂贵，可以利用内核特性（skit features）禁用某些功能，以保持吞吐量性能。
  • 默认切片大小应设置得较长。
• 交互式系统:
  • chart_tick 对于交互式系统非常重要，它确保精确的时间切片，有助于获得可预测的延迟。
  • 负载均衡器中的backoff机制应被保护并默认禁用。
  • 默认切片大小应设置得较短（例如3毫秒）。
• QoS框架的有效性:
  • 为了使QoS真正有效，默认情况下需要降低非重要任务的噪音级别，这意味着默认性能可能会“变差”。
  • 通过基于配置的提示，用户可以明确指定哪些任务重要，哪些不重要。
  • 这样，调度器就能提供所需的延迟和性能，同时维护整个系统的健康（性能、功耗、散热）。
• 教育与调试: 需要提高用户和开发者对调度器默认值的认识，提供调试工具，帮助他们识别问题并进行正确的调整。

  

通用性能继承支持 [00:41:45]

代理执行 [00:42:56]

• 优先级反转（PI）问题: 代理执行（Proxy Execution）是解决内核级别优先级反转（PI）问题的第一步。
• 用户空间采纳: 需要用户空间采纳通用的性能继承机制，否则即使解决了其他调度问题，仍可能出现任务失败（如丢帧）的边缘情况。
• 必要性: 只有当所有相关组件都到位并协同工作时，QoS框架才能真正有效。

Qualcomm开源的用户资源管理器 (User Resource Manager) [00:41:45]

• Qualcomm已开源了一个名为“用户资源管理器 (User Resource Manager)”的工具。
• 该工具利用cgroups、clumps、CPU频率和调度策略等现有内核接口。
• 它包含一个分类器引擎，可根据不同的用例（如多摄像头、音频路径）应用相应的配置片段。
• 该工具可作为QoS框架实施的起点，值得借鉴。

访问控制 [00:43:37]

管理员与应用/用户控制的优先机制 [00:43:39]

• 控制层次: 需要引入控制机制，允许管理员拥有最终决定权。
• 示例 (Android): 在Android中，前台应用程序可能被允许使用“用户交互”QoS，而后台应用程序的相同请求可能会被拒绝。
• 重要性: 访问控制对于防止应用程序滥用QoS请求至关重要。

防止滥用 [00:44:00]

• 访问控制机制可以保护系统免受恶意或编写不佳的应用程序的滥用。
• 通过基于配置的提示，系统管理员对QoS的控制权更大，而非完全依赖于开发者的善意。
• 明确定义控制和决策的层次结构对于整个系统的有效运作至关重要。