Linux PREEMPT_RT中SCHED_OTHER性能优于SCHED_FIFO的原因探究

1. 同优先级内核RT线程抢占 #

你给测试程序设置了SCHED_FIFO最高优先级99，但PREEMPT_RT内核中部分系统线程（比如看门狗线程、高精度定时器相关线程）同样会被配置为SCHED_FIFO优先级99。当这些内核线程被唤醒并在隔离的core3上运行时，会触发同优先级抢占——SCHED_FIFO调度策略下，同优先级任务遵循先来先服务规则，若内核线程先抢占CPU，你的测试程序必须等待其执行完毕才能继续，这就是那次上下文切换和50ms级最大延迟的直接原因。

而SCHED_OTHER属于普通调度类（优先级远低于RT类），结合isolcpus=3的配置，内核不会将高优先级RT线程调度到运行普通任务的隔离核上，因此你的SCHED_OTHER程序能独占core3，无上下文切换，延迟表现稳定。

2. 隔离核参数配置不完整 #

仅设置isolcpus=3和irqaffinity=0-2无法实现core3的完全隔离：

• 未开启nohz_full=3：core3仍会触发周期性时钟中断，可能唤醒内核线程；
• 未配置rcu_nocbs=3：RCU回调仍会在core3上执行，导致内核线程被调度到该核；
  这些未处理的内核活动会干扰SCHED_FIFO任务的连续执行，但对SCHED_OTHER任务的影响极小——因为CFS调度器会自动避开这些内核活动的干扰。

3. 任务亲和性未严格绑定 #

如果你的测试程序没有通过代码调用sched_setaffinity显式绑定到core3：

• SCHED_FIFO作为RT任务，可能被调度到非隔离的0-2核，这些核承担irq处理任务，极易被打断产生大延迟；
• SCHED_OTHER任务则受isolcpus限制只能在0-2核运行，CFS调度器会尽量保证其执行连续性，反而延迟表现更优。

• 检查系统RT线程：执行ps -eLo pri,cls,pid,cmd，筛选cls=FF（SCHED_FIFO）且pri=99的线程，确认是否有内核线程在core3上运行；
• 完善内核参数：在启动参数中添加nohz_full=3 rcu_nocbs=3，彻底隔离core3的内核级活动；
• 强制CPU绑定：在测试程序中添加代码，调用sched_setaffinity将进程严格绑定到core3；
• 调整RT优先级：将测试程序的SCHED_FIFO优先级降至98（低于系统最高RT优先级），避免与内核RT线程发生同优先级竞争。

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