Linux 实时内核调不出效果?先按这条链路查

很多人第一次上 PREEMPT_RT，都会遇到一个落差：

补丁打了，内核也换了，为什么系统还是抖？

这并不少见。

因为实时内核不是“装上就自动变稳”的东西。它解决的是内核底层可抢占性、调度延迟和时序响应能力问题。但如果系统里还有这些问题：

• 线程优先级乱

• IRQ 没迁走

• 关键线程没绑核

• 驱动中断路径太重

• 锁竞争严重

• 网络、存储、USB 干扰大

• 后台内核线程还在关键 CPU 上跑

那么 PREEMPT_RT 的收益很容易被吃掉。

所以这篇真正要回答的是：

为什么明明上了实时内核，系统还是没稳，以及到底该怎么查。

一句话讲明白：

Linux 实时内核调不出效果，最常见的原因不是补丁没生效，而是关键线程路径上的中断、调度、锁、CPU 干扰、驱动慢路径还没清掉。最稳的排查方法，不是先调参数，而是顺着关键线程，把“唤醒、调度、执行”这条链路一段段拆开。

一、先确认你到底在测什么

很多人一上来就说：

实时内核没效果。

但这句话经常不准确。

常见情况有三类：

1. cyclictest 没明显改善

    说明系统底座时延还没压住。

2. cyclictest 变好了，但业务线程还是抖

    说明实时内核改善了底层调度，但业务路径里还有问题。

3. 空载效果不错，一上现场负载就变差

    通常说明干扰源没有隔离干净。

先确认当前内核：

uname -a

查看当前正在运行的内核版本：

uname -r

第一步不要笼统判断“RT 没效果”，而要先明确：是底座时延没下来，还是业务链路没调顺。

二、先盯关键线程

实时问题最稳的入口不是全局，而是关键线程。

先回答三个问题：

• 它什么时候本来应该运行？

• 它实际什么时候开始运行？

• 它慢在“没醒”“醒了没调度上去”，还是“跑起来以后推进慢”？

这一步可以把问题分成三类：

1. 没按时醒

优先查定时器、中断延迟、长不可抢占路径、驱动唤醒路径。

2. 醒了但没及时上 CPU

优先查调度策略、线程优先级、IRQ 线程优先级。

3. 上了 CPU 但执行慢

优先查 CPU 负载、锁竞争、驱动慢路径、DMA、cache、内存分配、日志和 I/O。

查看关键线程调度策略：

chrt -p <PID>

查看线程在哪些 CPU 上运行：

ps -eLo pid,tid,psr,cls,rtprio,pri,comm | grep <进程名>

查看某个进程的线程：

ps -T -p <PID>

实时排查最怕一开始就全局调参数。应该先找出关键线程到底卡在哪一段。

三、先查中断，而不是先看 CPU 利用率

CPU 总体利用率不高，不代表关键线程不会被中断拖慢。

如果看到这些现象：

• 偶发尖峰

• 周期线程慢一拍

• 网络或设备一忙就变差

• cyclictest 最大值明显偏大

先看中断。

查看中断分布：

cat /proc/interrupts

持续观察：

watch -n 1 cat /proc/interrupts

重点看：

• 哪些 IRQ 最活跃

• 网卡、存储、USB 中断打在哪些 CPU 上

• 关键 CPU 上是否压了高频中断

• IRQ 线程是否和业务线程抢同一个 CPU

RT 内核下，很多中断会线程化，可以看 IRQ 线程：

ps -eLo pid,tid,psr,cls,rtprio,pri,comm | grep -E '[i]rq/[0-9]+'

查看 IRQ 亲和性：

cat /proc/irq/<IRQ号>/smp_affinity_list

把某个 IRQ 迁到 CPU2：

echo 2 > /proc/irq/<IRQ号>/smp_affinity_list

很多“上了 RT 还是抖”的项目，第一根导火索往往就在这里：关键线程前面还有太多中断工作没让开。

四、再查调度和优先级关系

如果关键线程已经醒了，但没有及时推进，就要查调度关系。

常见问题包括：

• 关键线程优先级不够高

• 太多线程都在高优先级区

• IRQ 线程优先级压过业务线程

• 同一优先级挤了太多关键线程

• SCHED_FIFO / SCHED_RR 使用不合理

查看线程优先级：

ps -eLo pid,tid,cls,rtprio,pri,psr,comm

查看关键进程：

ps -eLo pid,tid,cls,rtprio,pri,psr,comm | grep <进程名>

设置实时优先级，例如 SCHED_FIFO 80：

chrt -f -p 80 <PID>

启动程序时直接指定：

chrt -f 80 ./your_app

这里不要只看“关键线程优先级高不高”，还要看：

• 谁比它先跑？

• 为什么先跑？

• 这个顺序是不是你想要的？

如果优先级关系错了，实时补丁再好也救不了业务时序。

五、锁和共享资源最容易漏掉

很多系统已经做了：

• 上 PREEMPT_RT

• 提优先级

• 绑 CPU

• 迁 IRQ

但关键线程还是偶发超时。

这时候常见根因是关键线程卡在锁上。

重点查：

• 高优先级线程是否在等低优先级线程持有的锁

• 持锁时间是否过长

• 锁里有没有 I/O、日志、大循环

• 实时线程和后台线程是否共用重锁

• 有没有优先级反转

用 perf lock 观察锁竞争：

perf lock record -a -- sleep 10perf lock report

也可以看调度延迟：

perf sched record -- sleep 10perf sched latency

PREEMPT_RT 能改善调度，但不能自动修好错误的锁设计。

六、绑核了，不代表 CPU 就干净了

任务绑核很常见：

taskset -c 3 <PID>

启动时绑定：

taskset -c 3 ./your_app

查看绑定结果：

taskset -p <PID>

但绑核不等于这个 CPU 就干净。

关键 CPU 上可能还有：

• 周期 tick

• RCU 回调

• housekeeping 工作

• 内核线程

• 没迁干净的 IRQ

• irqbalance 自动迁移中断

查看启动参数：

cat /proc/cmdline

关注是否配置：

isolcpus=3 nohz_full=3 rcu_nocbs=3

查看 irqbalance：

systemctl status irqbalance

临时停止：

systemctl stop irqbalance

查看某个 CPU 上正在跑什么，例如 CPU3：

ps -eLo pid,tid,psr,cls,rtprio,pri,comm | awk '$3==3'

这里的关键不是“线程绑了吗”，而是“这个 CPU 真的干净了吗”。

七、驱动是最容易低估的杀伤点

很多项目不是 PREEMPT_RT 没效果，而是驱动把效果吃掉了。

典型问题包括：

• ISR 太重

• DMA 完成路径太长

• 唤醒路径绕太多

• 驱动锁太重

• 驱动里动态分配内存

• 高频日志塞在热路径里

这类问题有一个共同特征：

设备一忙，系统就抖。

如果发现：

• 关掉某个设备后系统立刻变稳

• 某个驱动一活跃，尖峰就上来

• 周期线程超时总和某类硬件事件同步出现

那就不要只盯调度器，大概率是驱动路径在拖后腿。

常用观察命令：

watch -n 1 cat /proc/interruptsdmesg -T

实时系统里，驱动热路径最应该警惕：大量打印、长时间关中断、长时间持锁、动态内存分配、同步 I/O 和大块数据搬运。

八、网络和 NAPI 干扰很容易吃掉实时收益

Linux 实时系统里，网络路径特别容易成为噪声源。

尤其是系统同时跑：

• EtherCAT

• 普通 TCP/UDP

• SSH

• 日志上传

• 远程访问

• 数据采集

常见现象是：

• 空载很好

• 一有网络流量就变差

• cyclictest 最大值明显抬高

• 关键线程和网卡 IRQ 共核时特别明显

查看网卡中断：

cat /proc/interrupts | grep -i ethcat /proc/interrupts | grep -i enp

查看网卡队列：

ls /sys/class/net/<网卡名>/queues/

查看网卡统计：

ethtool -S <网卡名>

查看网卡通道：

ethtool -l <网卡名>

调整网卡队列数量，例如设置为 1：

ethtool -L <网卡名> combined 1

如果普通网络流量和实时业务共用 CPU，很容易误判成 RT 内核没效果。实际上是网络干扰还在破坏关键路径。

九、不要只看空载，一定要看压力下变化

很多系统空载下都很好看。真正拉开差距的是：

• CPU 负载上来

• 网络流量上来

• 存储活跃

• 多任务并发

• 设备中断频繁

常用 cyclictest 基准测试：

cyclictest -p 95 -m -n -i 1000 -l 100000

绑定到指定 CPU，例如 CPU3：

taskset -c 3 cyclictest -p 95 -m -n -i 1000 -l 100000

加压力测试：

stress-ng --cpu 4 --io 2 --vm 2 --vm-bytes 512M --timeout 60s

同时观察实时延迟：

taskset -c 3 cyclictest -p 95 -m -n -i 1000 -D 60s

如果空载好、压力下差，通常说明干扰源没有隔离干净。

如果空载和压力下都差，那更可能是系统基础路径本身就没收住。

十、工具落地：把“看什么”变成“怎么看”

1. 用 cyclictest 看系统底座时延

cyclictest -p 95 -m -n -i 1000 -D 60s

绑定关键 CPU：

taskset -c 3 cyclictest -p 95 -m -n -i 1000 -D 60s

重点看：

• Avg：平均延迟

• Max：最大延迟

• 压力前后最大值变化

实时系统里，Max 往往比平均值更重要。

2. 用 ftrace 抓线程唤醒和调度延迟

挂载 tracefs：

mount -t tracefs nodev /sys/kernel/tracingcd /sys/kernel/tracing

清空旧数据并打开调度事件：

echo > traceecho 1 > events/sched/sched_wakeup/enableecho 1 > events/sched/sched_switch/enable

开始抓取：

echo 1 > tracing_on

复现问题后停止：

echo 0 > tracing_oncat trace

重点看：

• 关键线程什么时候被唤醒

• 唤醒后多久才真正运行

• 中间是谁占用了 CPU

• 是否被 IRQ 线程或其他实时线程挡住

3. 用 perf 看调度和锁

记录调度行为：

perf sched record -- sleep 10perf sched latency

记录锁竞争：

perf lock record -a -- sleep 10perf lock report

重点看：

• 哪些线程等待时间长

• 哪些锁竞争最严重

• 是否有低优先级线程长期持锁

• 是否有实时线程被锁拖住

十一、最实用的排查顺序

如果只想要一套现场排查顺序，可以按这个来：

盯关键线程

先判断问题是没醒、没调度上去，还是上 CPU 后执行慢。

看中断

重点看高频 IRQ、IRQ 分布、网卡/存储/USB 干扰，确认 IRQ 是否打在关键 CPU 上。

看调度和优先级

确认谁挡在关键线程前面，IRQ 线程和业务线程顺序是否正确。

看锁和共享资源

确认高优先级线程是不是在等锁，是否存在优先级反转，临界区是否太大。

看 CPU 是否真的干净

确认任务绑核、IRQ 绑核、irqbalance、isolcpus、nohz_full、rcu_nocbs。

看驱动、DMA、内存和网络路径

重点排查驱动慢路径、DMA 完成路径、网络 NAPI、日志、I/O 和动态内存分配。

这套顺序的核心不是“所有参数都调一遍”，而是顺着关键线程主路径，一层层往前追。

十二、什么时候说明 PREEMPT_RT 已经起作用了？

很多时候，PREEMPT_RT 不是完全没效果，而是已经把底座改善了，但上层干扰还在。

常见信号包括：

• cyclictest 比普通内核好

• 空载更稳

• 最大延迟下降

• 线程更容易按优先级推进

• 但业务场景下仍然有尖峰

这说明实时内核已经在起作用，只是系统还没有被彻底调顺。

换句话说：

RT 内核是基础，不是终点。

最后总结

Linux 实时内核调不出效果，最常见的原因不是补丁白打了，而是关键线程路径上的中断、调度、锁、CPU 干扰、驱动慢路径还没清干净。

最稳的排查方法，是顺着关键线程把链路拆成三段：

• 它有没有按时醒？

• 醒了有没有及时调度上 CPU？

• 上 CPU 后为什么执行慢？

然后按顺序看：

• 关键线程

• 中断分布

• 调度和优先级

• 锁和共享资源

• CPU 隔离和后台噪声

• 驱动、DMA、网络和存储路径

PREEMPT_RT 能提供更好的底层时序能力，但真正稳定的实时系统，靠的是内核、线程、IRQ、CPU、驱动和业务路径一起调顺。