ps -L -eo psr,%cpu,pid,tid,comm可查看各线程实时CPU分布与负载，psr为调度核号，%cpu为平均占用率；/proc/sched_debug提供内核调度器原始统计；perf sched latency用于精确测量调度延迟。
直接看每个CPU上正在运行的任务分布用 ps -L -eo psr,%cpu,pid,tid,comm
这个命令能告诉你「此刻哪个线程跑在哪个核上、占了多少CPU」，psr 列就是它被调度到的 CPU 编号（从 0 开始）。%cpu 是该线程最近一段时间的平均占用率，不是瞬时值，但足够定位热点线程。
-
-L表示显示线程级信息（LWP），否则只看到进程，漏掉高负载的子线程 -
-eo控制输出字段顺序，psr必须显式指定，否则默认不显示调度位置 - 结果里
psr值反复出现在同一核（比如全是 3），说明调度不均衡，可能受taskset或 cgroups 限制 - 注意：该输出是快照，不带时间序列；如需持续观察，可配合
watch -n 0.5，但别低于 0.5 秒，否则干扰调度本身
查内核级调度统计细节用 cat /proc/sched_debug
这是 Linux 调度器的原始调试接口，包含每个 CPU 的运行队列长度、切换次数、平均等待时间、当前运行任务等。它不友好，但不可替代——比如你想确认是不是 rt_throttling 在限频，或者某个 FIFO 任务长期霸占 CPU，就得翻这里。
- 关键字段：
nr_switches（该 CPU 切换次数）、nr_voluntary_switches（主动让出）、nr_involuntary_switches（被抢占） - 每个
runnable tasks块下会列出当前就绪队列里的任务，含se.exec_max（单次最长执行时间）、se.statistics.wait_sum（总等待时间） - ⚠️ 不要长期打开：频繁读取会触发内核调试路径，轻微增加开销；生产环境建议只在问题复现时抓一次
- 搜索特定 PID：用
grep -A 10 -B 5 "pid 12345" /proc/sched_debug，避免人工扫屏
监控调度延迟用 perf sched latency
当怀疑存在调度延迟（比如实时任务响应变慢、GC 暂停异常长），perf sched 是唯一能定量测量「任务从就绪到真正开始执行之间延迟」的工具。它基于内核 tracepoint，精度到微秒级。
- 先采集：
perf sched record -a sleep 5（记录全系统 5 秒内的调度事件） - 再分析：
perf sched latency输出每个任务的最大/平均延迟、延迟直方图 - 常见陷阱：默认只捕获普通优先级任务；如需包含实时线程，得加
--all-cpus并确保 perf 权限足够（通常需 root） - 注意：
perf版本太老（perf --version 确认
为什么不用 top 或 htop 看调度？
它们只显示「结果」——某个线程当前占了多少 CPU 时间，不反映「过程」：是否频繁迁移、是否被饥饿、是否因锁或中断阻塞。比如一个线程 %cpu 显示 90%，但它可能 80% 时间在 wait_event_interruptible 里休眠，实际只跑了 10%；这种假象只有 /proc/sched_debug 或 perf sched 能拆解。
分时调度数据的本质是时间片分配与上下文切换行为，不是单纯的占用百分比。抓错层次，就只能看到水面，看不见水下的队列和延迟。
