实时组调度
0. 警告
调整这些设置可能导致系统不稳定,这些旋钮只有 root 用户才能操作,并且假设 root 用户知道自己在做什么。
最值得注意的是:
- 在 sched_rt_period_us 中使用非常小的值可能导致系统不稳定,当周期小于可用的 hrtimer 分辨率或者处理预算刷新本身所需的时间时。
- 在 sched_rt_runtime_us 中使用非常小的值可能导致系统不稳定,当运行时间非常短时,系统难以取得进展(注意:迁移线程和 kstopmachine 都是实时进程)。
1. 概述
1.1 问题
实时调度关乎确定性,一个组必须能够依赖于固定的带宽(例如 CPU 时间)。为了调度多个实时任务组,每个组必须被分配一个固定的 CPU 时间份额。如果没有最小保证,实时组显然会不足。模糊的上限是无用的,因为它是不可靠的。这让我们只剩下了单一的固定份额。
1.2 解决方案
通过指定在给定周期内可以花费多少时间来划分 CPU 时间。我们为每个实时组分配这个“运行时间”,其他实时组将不被允许使用。
未分配给实时组的时间将用于运行普通优先级任务(SCHED_OTHER)。未使用的分配运行时间也将被 SCHED_OTHER 使用。
让我们考虑一个例子:一个固定帧率的实时渲染器必须每秒传输 25 帧,这意味着每帧的周期为 0.04 秒。现在假设它还需要播放一些音乐并响应输入,留下大约 80% 的 CPU 时间用于图形。然后我们可以给这个组分配一个运行时间为 0.8 * 0.04 秒 = 0.032 秒。
这样,图形组将有一个 0.04 秒的周期,限制为 0.032 秒的运行时间。现在,如果音频线程需要每 0.005 秒重新填充 DMA 缓冲区,但只需要大约 3% 的 CPU 时间来完成,它可以使用 0.03 * 0.005 秒 = 0.00015 秒。因此,这个组可以被安排为周期为 0.005 秒,运行时间为 0.00015 秒。
剩余的 CPU 时间将用于用户输入和其他任务。因为实时任务已经明确分配了他们执行任务所需的 CPU 时间,图形或音频中的缓冲区不足可以被消除。
注意:上述示例尚未完全实现。我们仍然缺少一个 EDF 调度器来使非均匀周期可用。
2. 接口
2.1 系统范围的设置
系统范围的设置在 /proc 虚拟文件系统下配置:
- /proc/sys/kernel/sched_rt_period_us:
相当于 100% CPU 带宽的调度周期 - /proc/sys/kernel/sched_rt_runtime_us:实时调度可以使用的时间的全局限制。即使没有启用 CONFIG_RT_GROUP_SCHED,这也将限制分配给实时进程的时间。启用 CONFIG_RT_GROUP_SCHED 后,它表示所有实时组可用的总带宽。
- 时间以微秒为单位,因为接口是 s32。这给出了从 1 微秒到约 35 分钟的操作范围。
- sched_rt_period_us 取值范围为 1 到 INT_MAX。
- sched_rt_runtime_us 取值范围为 -1 到 (INT_MAX - 1)。
- -1 的运行时间指定为 runtime == period,即没有限制。
2.2 默认行为
sched_rt_period_us 的默认值为 1000000 或 1 秒,sched_rt_runtime_us 的默认值为 950000 或 0.95 秒。这样就留出了 0.05 秒供 SCHED_OTHER(非实时任务)使用。选择这些默认值是为了防止失控的实时任务锁定机器,而是留下一点时间来恢复。通过将运行时间设置为 -1,您可以恢复旧的行为。
默认情况下,所有带宽都分配给根组,新组从 /proc/sys/kernel/sched_rt_period_us 获取周期,并且运行时间为 0。如果要将带宽分配给另一个组,可以减少根组的带宽,并将差异的一部分或全部分配给另一个组。
实时组调度意味着您必须在组接受实时任务之前为其分配总 CPU 带宽的一部分。因此,即使用户有运行具有实时优先级的进程的权限,直到您这样做,您将无法以 root 以外的任何用户身份运行实时任务!
2.3 任务分组的基础
启用 CONFIG_RT_GROUP_SCHED 允许您明确地为任务组分配真正的 CPU 带宽。
这使用 cgroup 虚拟文件系统和 "<cgroup>/cpu.rt_runtime_us
" 来控制为每个控制组保留的 CPU 时间。
有关使用控制组的更多信息,您应该阅读《控制组》。
为了保持可调度的配置,组设置会根据以下限制进行检查:
Sum_{i} runtime_{i} / global_period <= global_runtime / global_period
目前,这可以简化为以下内容(但请参阅未来计划):
Sum_{i} runtime_{i} <= global_runtime
3. 未来计划
正在进行工作,使每个组的调度周期("<cgroup>/cpu.rt_period_us
")也可以配置。
对周期的约束是子组必须具有小于或等于其父组的周期。但实际上,这还不是很有用,因为它容易出现饥饿现象,没有截止日期调度。
考虑两个兄弟组 A 和 B;它们都有 50% 的带宽,但 A 的周期是 B 的两倍。
- 组 A:周期=100000 微秒,运行时间=50000 微秒
这将在每 0.1 秒内运行 0.05 秒 - 组 B:周期=50000 微秒,运行时间=25000 微秒
这将在每 0.1 秒内运行 0.025 秒两次(或每 0.05 秒一次)。
这意味着当前在组 A 中的一个 while (1) 循环将运行整个组 B 的周期,并且可能会使组 B 的任务饥饿(假设它们的优先级较低)整个周期。
下一个项目将是 SCHED_EDF(最早截止日期优先调度),将完全的截止日期调度引入 Linux 内核。对上述组进行截止日期调度,并将周期结束视为截止日期,将确保它们都获得其分配的时间。
实施 SCHED_EDF 可能需要一段时间才能完成。优先级继承是最大的挑战,因为当前的 Linux PI 基础设施是针对有限的静态优先级级别 0-99。使用截止日期调度,您需要进行截止日期继承(因为优先级与截止日期差(截止日期 - 现在)成反比)。
这意味着整个 PI 机制都必须重新设计 - 这是我们拥有的最复杂的代码之一。