CFS调度器基于vruntime选择进程：红黑树中vruntime最小者优先运行，新进程vruntime设为队列最小值避免插队；实时进程绕过CFS；多核负载均衡有延迟阈值；绑定CPU或NO_HZ_FULL会改变调度行为。
linux 的 CFS 调度器怎么选进程运行？
CFS（Completely Fair Scheduler）是 Linux 默认的进程调度器，它不按“时间片轮转”硬切，而是基于虚拟运行时间 vruntime 做公平调度。每个可运行进程被放入红黑树，vruntime 最小的那个（即“最该被调度”的）总在树最左端，调度器每次从那里取任务。
-
vruntime是按进程实际 CPU 使用时间加权计算的，权重由nice值决定：nice 越低（优先级越高），权重越大，vruntime增长越慢，更容易被选中 - 新进程的
vruntime默认设为当前运行队列的最小vruntime，避免“插队”但也不至于太滞后 - 如果你用
chrt -f 50启动实时进程，它会绕过 CFS，走SCHED_FIFO调度类，此时 CFS 完全不参与——这点常被误认为“CPU 被占满”，其实是调度类切换导致的
多核下进程为什么会“卡”在一个 CPU 上？
Linux 默认启用负载均衡，但不是每毫秒都搬进程。内核按一定周期（如 1–4 ms）检查各 CPU 的运行队列长度和 vruntime 差异，只在差异超过阈值时才迁移任务。这意味着：
- 短时突发负载可能让某个 CPU 持续忙 10 ms，而其他核空闲——这不是 bug，是延迟优化策略
-
taskset -c 0,1 ./a.out或numactl --cpunodebind=0会显式绑定 CPU，此时即使其他核空闲，进程也不会被迁走 - 如果看到
top中某进程的%CPU长期接近 100% 且只跑在单核，先用ps -o pid,psr,comm -p $PID确认是否被绑核，而不是直接怀疑调度器失灵
如何判断是不是调度延迟导致响应变慢？
真正的调度延迟（scheduling latency）往往藏在上下文切换开销或抢占失效里，而不是“没轮到”。常用排查点：
- 查看
/proc/sys/kernel/sched_latency_ns（默认 ~6 ms）和/proc/sys/kernel/sched_min_granularity_ns（默认 ~0.75 ms）：粒度越小，调度越频繁，但上下文切换开销越大 - 用
perf sched latency -s max抓最长调度延迟事件，若出现 >5 ms 的“R → R”（就绪态到运行态）延迟，再结合perf record -e 'sched:sched_switch'看是否被高优先级中断或软中断阻塞 - 注意：启用了
NO_HZ_FULL（即“无滴答”模式）的 CPU，如果跑的是独占型实时任务，内核会停掉该核的定时器，此时sched_latency_ns参数完全不生效
多核调度的复杂性不在算法本身，而在它必须同时应对 NUMA 内存访问代价、中断亲和性、cgroup 资源限制、以及用户空间对 CPU 绑定的隐式依赖——这些因素一旦叠加，vruntime 就只是个起点，不是全部答案。