chrt -p查不到实时优先级，是因为进程未启用sched_fifo或sched_rr策略；仅当ps显示cls为ff/rr且rtprio为1–99时，实时优先级才有效，rtprio=0是已进入实时类的特殊占位符。
chrt 命令查不到进程的实时优先级？先确认进程是否真在实时调度类
直接用 chrt -p <pid></pid> 查不到有效值，或者显示 sched_other，大概率是因为该进程根本没运行在 SCHED_FIFO 或 SCHED_RR 调度策略下。Linux 默认所有普通用户进程都走 SCHED_OTHER（CFS），它没有“实时优先级”概念——所谓“实时优先级”仅对实时调度类有意义。
验证方法：
- 先用
ps -o pid,tid,cls,pri,rtprio,comm -p <pid></pid>看rtprio列和cls列：若cls是TS（即 SCHED_OTHER），rtprio恒为-或0，此时谈实时优先级无意义 -
chrt -p <pid></pid>输出中若含sched_other，说明该进程未启用实时调度 - 只有
cls显示FF（SCHED_FIFO）或RR（SCHED_RR）时，rtprio数值才真实有效（范围 1–99）
chrt -p 显示 rtprio 为 0，但进程确实在 SCHED_FIFO 下？这是正常行为
当 chrt -p <pid></pid> 输出类似 sched_fifo (1), rtprio 0，别急着认为失败——这恰恰说明进程已成功切换到 SCHED_FIFO，只是内核把它的实时优先级设为了最低（0）。但注意：Linux 内核实际只接受 1–99 的非零值作为有效实时优先级；rtprio=0 是一个特殊占位符，表示“已进入实时类，但优先级由调度器内部逻辑隐式管理”，常见于某些内核线程或特定驱动上下文。
真正可被用户设置并生效的值必须是 1–99：
- 启动新进程时：
chrt -f 50 ./myapp→ 实时优先级 50，策略 SCHED_FIFO - 调整已有进程：
chrt -f 80 <pid></pid>→ 必须保证当前用户有cap_sys_nice权限，否则报错Operation not permitted - 查看结果务必配合
ps -o pid,cls,rtprio,comm，因为chrt -p有时会省略细节
普通用户执行 chrt 失败提示 Permission denied？权限和 cgroup 限制都要查
即使加了 sudo，仍可能遇到 chrt: failed to set pid 1234's policy: Operation not permitted。这不是 sudo 没用，而是更深层限制：
- 用户需具备
cap_sys_nice能力（通常 root 默认拥有；普通用户需显式授予权限，如sudo setcap cap_sys_nice+ep /usr/bin/chrt） - systemd 系统中，服务进程受
TasksMax和CPUAccounting影响，但更关键的是RestrictRealtime=yes（默认开启）——它会禁止任何进程进入实时调度类，无论权限多高 - 检查 systemd 限制：
systemctl show --property=RestrictRealtime <service-name></service-name>；临时关闭需改 service 文件加RestrictRealtime=no并重载 - cgroups v2 下，若进程所在 cgroup 的
cpu.max或cpu.weight被严格限制，也可能间接阻止实时策略生效
实时优先级不是越高越好：SCHED_FIFO 进程会饿死其他任务
把 chrt -f 99 给一个 CPU 密集型程序，等于给它开了“无限时间片通行证”。只要它不主动让出 CPU（比如 sleep、阻塞 I/O、调用 sched_yield()），同 CPU 上的所有其他进程（包括 sshd、kthreadd）都会被完全抢占——系统可能卡死，连 Ctrl+C 都无法响应。
安全实践建议：
- 优先选
SCHED_RR（chrt -r）而非SCHED_FIFO，它带时间片轮转，天然防饿死 - 实时优先级尽量压低：能用 10 解决问题，就别设 50；多数嵌入式/音视频场景 10–30 足够
- 永远在测试环境验证：用
taskset -c 0 chrt -f 50 yes > /dev/null &模拟高优负载，观察系统响应性 -
/proc/<pid>/status</pid>中的CapBnd:字段可确认该进程是否真的持有cap_sys_nice，避免权限误判
实时调度是把双刃剑，chrt 只是刀柄，握法不对，划伤的是整个系统。
