RT-Thread随SCHED_OTHER线程增多运行变慢的技术问询

这个问题其实涉及到Linux调度器的工作机制，以及RT-Thread程序在多线程竞争环境下的表现，我来帮你拆解下核心原因：

核心原因分析 #

1. CFS调度器的负载与上下文切换开销 #

你后台运行的30个./aa线程用的是Linux默认的SCHED_OTHER调度策略，背后是CFS（完全公平调度器）在管理。当系统里这类线程数量暴增时：

• 调度器要维护更多的线程调度队列，频繁进行时间片计算和跨核负载均衡操作——这些操作本身就会占用CPU资源，直接挤占了./test的运行时间。
• 哪怕你的机器有48核，30个线程看似能分散到不同核心，但调度器的全局调度逻辑（比如为了均衡负载把线程从一个核迁移到另一个核）会带来额外开销，导致./test的执行被莫名延迟。

2. 缓存污染与CPU资源抢占 #

大量后台线程会疯狂访问CPU的L1/L2/L3缓存，很容易把./test正在使用的缓存数据冲掉。当./test被调度回来继续执行时，需要重新把数据加载到缓存里，这额外的内存访问耗时就会反映在你的测试结果中（比如那个跳到354ms的峰值）。
另外，CFS的公平调度逻辑会把CPU时间片分给所有SCHED_OTHER线程，线程数量越多，./test能拿到的连续时间片就越细碎，执行过程中被打断的次数变多，累加起来整体耗时自然就上去了。

3. RT-Thread线程与Linux调度器的交互逻辑 #

如果你的./test是基于Linux移植版的RT-Thread程序，那它的线程默认大概率也是用SCHED_OTHER策略（除非你手动设置了实时优先级）。这种情况下，它和后台的./aa线程处于同一调度级别，线程数量越多，资源竞争就越激烈，./test的运行自然会变慢。
哪怕你给RT-Thread线程设置了更高的nice值（优先级），CFS依然会分配一定时间给低优先级线程，还是会打断./test的连续执行，影响整体耗时。

验证与优化建议 #

验证方法 #

• 用top或htop查看系统的上下文切换次数（cs列），对比后台线程运行前后的数值，你会发现切换次数大幅上升；
• 用perf stat ./test统计./test执行时的缓存命中率、上下文切换次数，能直接定位到瓶颈所在。

优化方向 #

• 如果./test对实时性要求高，可以把它的线程调度策略改成SCHED_FIFO或SCHED_RR（实时调度策略），并设置合适的优先级——这样它能优先抢占CPU资源，基本不受SCHED_OTHER线程的干扰；
• 限制后台./aa线程的CPU亲和性（比如用taskset命令绑定到特定几个核心），让它们别去抢占./test所在核心的资源；
• 优化./test的代码逻辑，提升缓存命中率，减少不必要的内存访问，降低对系统调度波动的敏感度。

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