Linux 4.14内核：仅含实时与普通任务时，实时任务是否持续占CPU？

实时任务是否会持续占用CPU？ #

从你贴的pick_next_task代码逻辑来看，调度器会按优先级从高到低遍历调度类，实时调度类（rt_sched_class）的优先级高于普通CFS调度类，所以每次调度都会优先尝试选择实时任务。但实时任务并非一定会持续霸占CPU，分两种调度策略讨论：

• SCHED_FIFO：如果没有更高优先级的实时任务，该任务会一直运行，直到主动调用schedule()放弃CPU，或者被信号打断。
• SCHED_RR：这类任务有固定时间片，时间片用完后会被移到同优先级实时队列的尾部；如果系统中只有这一个实时任务，调度器还是会再次选中它，但带宽控制机制会限制它的总运行时间。

另外，Linux实时调度内置了带宽控制机制，哪怕只有一个实时任务，也不能无限制占用CPU，这正是sysctl_sched_rt_period和配套的sysctl_sched_rt_runtime的作用所在。

sysctl_sched_rt_period在rt_sched_class中的作用位置（4.14.255内核） #

实时调度的带宽控制逻辑集中在kernel/sched/rt.c文件里，sysctl_sched_rt_period的作用路径如下：

1. 当你通过sysctl修改该参数时，内核会调用sysctl_sched_rt_handler函数，更新每个CPU对应rt_bandwidth结构中的rt_period值。
2. 实时任务运行过程中，调度器会通过rt_check_bandwidth函数，检查当前周期内所有实时任务的累计运行时间是否超过rt_runtime（默认是rt_period的95%）。
3. 如果累计运行时间超限，rt_throttle函数会把超限的实时任务移到rt_overloaded队列，此时rt_sched_class->pick_next_task就不会再选中它，直到下一个周期到来（由sched_rt_period_timer定时器触发周期重置，恢复任务的可调度状态）。
4. 在rt_sched_class的enqueue_task、task_tick等核心方法中，都会间接触发带宽检查逻辑，确保实时任务的运行时间被严格限制在周期允许范围内。

本质上，sysctl_sched_rt_period定义了带宽控制的时间窗口，配合rt_runtime限制每个窗口内实时任务的总CPU使用时间，避免实时任务完全抢占普通任务的执行资源。

内容的提问来源于stack exchange，提问作者Yanel