SF.*_*SF. 5 scheduling real-time
我意识到sched_rt_period_us并且sched_rt_runtime_us旨在防止在 RT 任务失控的情况下冻结系统。我想知道，是否可以使用较小的值sched_rt_period_us来确保任务顺利运行。
我有一个简单的工作，每次调用所需的 CPU 时间不超过一毫秒左右 - 例如，通过 GPIO 引脚驱动步进电机。不过，我希望达到每秒不少于 100 个周期，持续。这不超过 CPU 时间的 10% - 扣除抢占和调度程序开销。
我读过“sched_rt_period_us 中的非常小的值会导致系统不稳定” 1，但没有说明“非常小的值”在哪个数量级上很重要。如果我设置sched_rt_period_us为 10000 并sched_yield()及时返回控制权 ( )，我能否可靠地指望调用我的程序之间的延迟不超过 0.01 秒？
底层 CPU 可能是 850MHz ARM，具有除上述控制之外的许多其他任务，但它们都不是实时的，甚至不需要“感觉响应”，但与默认值sched_rt_period_us和sched_rt_runtime_us（1 秒中的 95%）不同，我不能允许 RT 任务一次休眠整整 0.05 秒。
与这个问题相关的东西并不多，但我确实找到了这个线程。它是 2009 年的版本，它是关于 2.6.X Linux 内核的，但看起来很合适。
该线程的标题，主题：有关 sched-rt 组分配上限的问题：sched_rt_runtime_us - msg#01766。
摘抄
我写了一个小测试程序：
(a) 分叉两个线程，一个 SCHED_FIFO 和一个 SCHED_OTHER（该线程被重新分配为 -20），并将它们都绑定到特定的核心。
(b) 在紧密循环中运行两个线程（两个线程的迭代次数相同），直到 SCHED_FIFO 线程终止。
(c) 根据 SCHED_FIFO 线程的固定迭代次数计算常规 SCHED_OTHER 线程的已完成迭代次数。然后它会据此计算百分比。
我针对不同的 sched_rt_runtime_us 值（200 毫秒到 700 毫秒）运行上述工作负载，将 sched_rt_period_us 保持在 1000 毫秒不变。我还通过减小 sched_rt_period_us 的值（从而增加调度粒度）进行了一些实验，而行为没有明显变化。
我的观察结果以表格形式列出：
reg 线程已完成迭代次数 / sched_rt_runtime_us / RT 线程迭代次数的比率（以 % 为单位） sched_rt_runtime_us
- 0.2 100 %（常规线程完成其所有迭代）。
- 0.3 73%
- 0.4 45%
- 0.5 17%
- 0.6 0 %（SCHED_OTHER 线程完全受到限制。从未运行过）
- 0.7 0%