/proc/[pid]/schedstat的第二个字段（等待时间）包含抢占延迟但未单独剥离，需结合运行时间与切换次数分析；getdelays可分离纯调度延迟；perf sched能追踪真实抢占事件链；内核抢占关闭（preempt_count>0）常导致“应抢未抢”。
直接看 /proc/[pid]/schedstat 能拿到基础抢占延迟线索
进程的调度统计里没有“抢占延迟”这个直白字段，但 /proc/[pid]/schedstat 提供了三个关键数值：运行时间、等待时间、上下文切换次数。其中「等待时间」（第二个字段）是进程就绪但未被调度执行的时间总和，它**包含抢占延迟，但不单独剥离**。实际中，高等待时间 + 低运行时间 + 频繁切换，往往暗示抢占频繁或调度受阻。
示例：cat /proc/1234/schedstat
输出类似：1234567890 987654321 4567
→ 第二个数 987654321 单位是纳秒，即该进程累计在就绪队列中等待调度的总时长。
- 必须开启内核配置
CONFIG_SCHEDSTATS=y，否则该文件为空或不存在 - 只对
SCHED_NORMAL进程有意义；实时进程（SCHED_FIFO/SCHED_RR）走另一套路径，这里的数据不可靠 - 该值是累加值，不是瞬时延迟，需配合采样间隔做差分分析
getdelays 是唯一能分离出「调度延迟」的用户态工具
getdelays 通过内核的 delay accounting（CONFIG_TASK_DELAY_ACCT=y）机制，把进程等待拆成更细的维度，其中 CPU 行的 delay total 就是纯调度延迟——即进程就绪后，因调度器未及时选中它而产生的延迟总和，**已排除 I/O、swap、reclaim 等其他阻塞原因**。
用法：./getdelays -d -p 1234
关注输出中 CPU 行的 delay total 和 delay average 字段。
- 若
delay average持续 > 1ms，说明存在明显调度压力或配置不合理 - 对比
count（调度次数）和delay total，可估算每次调度平均卡顿多久 - 注意：该工具不自带，需从 kernel source 的
tools/accounting/getdelays/下编译，依赖 netlink socket
用 perf sched 抓真实抢占事件链
想确认「谁在抢谁」「为什么此刻被抢占」，得用 perf 记录调度事件流。perf sched record -a sleep 5 可捕获 5 秒内所有调度动作，再用 perf sched latency 或 perf sched map 分析。
-
perf sched latency列出每个进程的最大单次调度延迟（含抢占延迟），排序后一眼看出问题进程 -
perf sched map显示 CPU 核心上任务切换热图，密集切换点大概率对应抢占热点 - 关键事件如
sched:sched_switch、sched:sched_wakeup、sched:sched_migrate_task都带prev_state和next_pid，可还原抢占上下文 - 注意：
perf开销不小，生产环境慎用长时间采集；优先用-e 'sched:sched_switch' -C 0锁定单核减负
别忽略内核抢占开关状态这个隐藏开关
很多「看起来该抢占却没抢」的问题，根源不在调度器逻辑，而在内核抢占被临时关闭。检查当前线程是否处于不可抢占区域，最直接的方式是读 /proc/[pid]/stack 并搜 preempt_count 值，或看调用栈里有没有 spin_lock、rcu_read_lock、irq_enter 等标记。
-
preempt_count> 0 表示当前线程禁止被抢占，哪怕TIF_NEED_RESCHED已置位也无效 - 常见于驱动中持有自旋锁过久、中断下半部（softirq）处理太长、RCU 读侧临界区嵌套过深
- 用
cat /proc/sys/kernel/preempt_count看全局计数？不行——该值 per-CPU 且不导出，只能通过 stack 或 ftrace 动态观测
真正影响分时进程响应的，往往不是 CFS 算法本身，而是这些「看不见的停顿」。查延迟不能只盯着调度队列，得一路跟到内核态执行现场。
