实时组调度 【ChatGPT】

实时组调度

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 机制都必须重新设计 - 这是我们拥有的最复杂的代码之一。

posted @ 2023-12-11 21:50  摩斯电码  阅读(25)  评论(0)  编辑  收藏  举报