一年前我接手一个在线服务时遇到过一件怪事机器负载不高CPU 总占用也只有 30% 上下可接口的 P99 延迟动不动就飙到几百毫秒。查了半天网络、数据库、锁最后才发现问题出在 Linux 调度器身上——某个 CPU 密集型的后台任务把核心占死了前端线程虽然优先级高但就是轮不到它跑。从那次之后我才意识到调度器不是内核源码里一个不起眼的角落而是理解整个系统行为的关键入口。这篇文章就围绕 Linux 调度器的基础展开适合两类读者一类是刚接触内核、想搞明白“进程到底是怎么被安排到 CPU 上执行”的人另一类是已经在写应用、但经常被 CPU 占用率高但服务卡顿这类现象困扰的后端开发者。我不会把源码逐行贴出来讲而是把调度器的设计动机、核心数据结构、主要调度类、调度时机、负载均衡和排查手段串起来让你读完能建立起一个完整的地图之后再去看内核源码就不会迷路。1. 调度器先搞清楚这几个基本问题1.1 一台只有一个 CPU 的机器凭什么能同时运行一堆程序很多人对操作系统的第一印象是“多任务并行”但物理上单核 CPU 同一时刻只能执行一条指令流。所谓的“同时运行”本质上是操作系统把时间切成无数小片轮流分给各个进程。这个“轮流分时间”的工作就是调度器干的。你可以把 CPU 想象成一个做菜的厨师进程就是排队的订单。调度器不是“多做几个锅”的硬件升级而是决定下一步做哪个菜、做多长时间、中途能不能被其他订单插队的管理者。如果某个订单做得太久了其他订单就会饿肚子如果频繁更换菜品光洗锅切菜就耗掉大量时间出菜效率反而变低。调度器的所有设计本质上都在权衡这两个矛盾。从用户角度看我们希望每个程序都能及时响应从系统角度看我们希望 CPU 的利用率尽量高、吞吐量尽量大。这两个目标经常冲突——低延迟需要频繁切换频繁切换又带来上下文切换开销降低吞吐。Linux 调度器的演进史就是一部如何在公平、实时、吞吐、功耗之间反复找平衡点的历史。1.2 调度器管什么不归它管什么先明确边界。调度器只负责一个问题CPU 资源的分配——具体地说就是决定处理器上“下一个执行哪个任务、执行多久、何时被抢占”。它不负责内存页面的换入换出那是内存管理子系统的事也不负责磁盘请求的排队那是块设备层的 IO 调度器的事。虽然名字里都有“调度”但它们解决的问题域完全不一样千万别混。还要区分两个层面一个是进程级的 CPU 调度也就是主线调度器跑在 SMP 多核环境下负责把任务分到各个 CPU 的 runqueue 上另一个是内核里的软中断、硬中断处理顺序比如 softirq 的触发时机虽然也和延迟有关但属于另一个机制。很多人在排查延迟时把两者混在一起后面容易误判。可以参考这么一组简单的类比调度器管的是“谁来用 CPU”而锁管的是“谁能用这份共享数据”内存管理器管的是“数据放在哪一层”。一个进程即使被调度器选中、拿到了 CPU如果它在等锁、等 IO、等内存它照样没法推进。所以在看调度问题时先确认进程到底是“在跑”还是“在等”。1.3 调度器设计的几条硬约束Linux 调度器在设计和演进中始终受到几条硬约束的拉扯公平性所有相同优先级的进程应该获得大致相等的 CPU 时间不能有人被饿死。但“公平”本身怎么定义就有讲究是按执行时间公平还是按权重公平。响应延迟交互式进程比如你敲键盘时的终端、拖动窗口的 GUI需要低延迟用户可不想因为后台正在编译而感觉系统“卡住”。吞吐量全局来看系统每秒能完成的作业数要尽量高。切换太频繁会导致大量时间耗费在保存和恢复现场上吞吐自然下降。实时性某些任务需要在规定时间内完成比如音频播放、自动驾驶控制。这类任务的调度策略跟普通进程完全不同宁可牺牲公平性也要保证截止时间。有意思的是这四个目标没法同时最优。比如要极致的吞吐就应该让一个进程长时间占住 CPU 直到做完可这样响应延迟就很差。要极致的公平每个进程都切得很频繁上下文切换开销又把吞吐拖垮。Linux 的调度器不是去“解决”这个矛盾而是通过分层的调度策略让不同需求的任务各得其所实时任务走实时调度类普通交互任务走 CFS后台批处理任务可以压低优先级。2. 调度器的核心数据结构与基本概念2.1 task_struct进程在调度器眼里的“身份证”内核里每一个进程、线程本质上都是一个task_struct它挂了进程所有的元信息PID、父子关系、打开的文件、内存描述符、信号处理、时间统计……调度器只关心其中一小部分但这一小部分是理解整个调度系统的抓手。在调度相关字段里比较关键的有policy表示调度策略比如SCHED_NORMAL、SCHED_BATCH、SCHED_IDLE、SCHED_FIFO、SCHED_RR、SCHED_DEADLINE。这东西决定进程挂在哪个调度类上。prio、static_prio、normal_prio、rt_priority这几个优先级字段容易把人绕晕。简单理解static_prio就是你用nice命令设置的基础优先级rt_priority是实时任务的实时优先级prio是最终生效的动态优先级。普通进程的prio会因为交互性和睡眠状态被动态调整实时进程则直接用rt_priority参与排队。se、rt、dl这是嵌入到task_struct里的调度实体。CFS 用的是sched_entityse实时调度类用的是sched_rt_entityrtdeadline 调度类用的是sched_dl_entitydl。同一个进程在不同调度框架下挂载的数据结构不同。你可以把task_struct想象成医院里每个病人的病历夹调度器不看你的姓名年龄只看你的“病情分诊等级”和“排队序号”两张卡片然后决定下一个叫谁进诊室。2.2 runqueue每个 CPU 手里的一副牌调度器不是全局一个队列而是每个 CPU 都有自己的 runqueue。这个设计在多核时代非常重要如果所有任务都扔到一个大池子里每次选任务还要考虑锁竞争和跨核迁移代价极高。per-CPU 的 runqueue 让每个核都能快速找到自己要跑的下一个任务。在较新的内核里struct rq就是 per-CPU 的运行队列里面嵌着多个子队列cfs_rq普通进程的红黑树队列所有SCHED_NORMAL/BATCH/IDLE进程在这里排队。rt_rq实时调度类用的优先级数组队列SCHED_FIFO/RR进程在这里。dl_rqdeadline 调度类的队列按截止时间排序。stop用于 CPU 热插拔等特殊场景的最高优先级队列。选择下一个任务时调度器按优先级顺序查这些子队列先看有没有stop任务再看 deadline、实时最后才轮到 CFS。也就是说只要系统里有可运行的实时任务普通进程哪怕优先级调得再高也只能在实时任务睡眠的间隙被调度到。后面讲调度类时还会细说。2.3 优先级、nice 值和权重决定谁先吃Linux 里最常被用户接触的优先级调整手段是nice。它的取值范围是 -20 到 19默认 0。数值越小优先级越高但这里的“高”不是绝对的先来后到而是影响 CFS 的权重计算。在 CFS 中nice 值被映射成一个权重值weight。内核里有一张查表数组sched_prio_to_weight每个 nice 值对应一个权重。大致规律是 nice 每降低 1权重约增加 25%。也就是说nice-20的进程比nice0的进程权重要高出很多倍但并不是说前者就一定先运行——确切地说是它“攒虚拟时间”更慢因而更容易被选中。这里要纠正一个常见的误区nice不会让你的进程“占用更高”而是让它在与其他进程竞争时更有优势。如果 CPU 只有一个进程在跑nice怎么调都不影响它运行只有当多个进程抢 CPU 时权重才起作用。它有点像餐厅里的“会员积分”积分高的客人在繁忙时段能优先入座但餐厅空着时谁进去都有位置。2.4 上下文切换的成本调度为什么不能太频繁调度器每次切换进程都要执行一次上下文切换context switch保存当前进程的 CPU 寄存器、程序计数器、栈指针加载下一个进程的现场。更深层的代价在 cache 和 TLB——换进来的进程大概率没有热数据和热页表cache miss 和 TLB miss 会让接下来的指令执行变得很慢。所以调度不是免费的一笔切换成本大概在微秒量级但随体系结构、进程大小、cache 状态波动很大。实际中一个进程如果只跑几百微秒就被切走那切换开销占比可能高得离谱。这也就是为什么 CFS 设置了一个“最小调度粒度”sched_min_granularity_ns默认 0.75ms 左右防止系统在负载高时把时间片切得太碎。我经常跟团队里的同学说一句话不要试图通过疯狂提高进程优先级来解决问题先搞清楚它是不是真的有 CPU 可跑、切换是不是过于频繁。优先级调得再高如果系统中有大量实时任务或者上下文切换每秒几十万次应用照样能被拖垮。3. 从 O(n) 到 CFS主线调度器演进3.1 O(n) 时代为什么不行老内核2.4 及以前用的调度器结构很简单一个全局的 runqueue所有可运行进程排成链表。每次要选“下一个任务”调度器就遍历整个链表挨个计算每个进程的优先级、最近运行时间、交互程度打一个分取最高者。这个方案在进程数少时没问题但进程一多就爆炸选一个任务的时间复杂度是 O(n)n 是整个系统可运行进程的数量。设想一台服务器上跑了 500 个线程每次调度都要扫 500 个节点这不仅让调度本身变慢还因为全局锁的存在导致多核扩展性极差。那个年代的内核在 SMP 机器上表现糟糕很大原因就在这。用排队打饭来类比O(n) 调度器就像食堂阿姨每打一个菜之前先跑到队伍尾部把所有人从头到尾看一遍再选出“看起来最饿”的那个人来打饭。队伍越长阿姨越慢整个食堂的效率就越低。3.2 O(1) 调度器的设计思路与局限2.6 内核引入了 O(1) 调度器核心思路是把进程按优先级分桶并且用两个数组互相切换。每个优先级有一个链表系统维护一个 bitmap每一位表示对应优先级的链表里有没有可运行进程。选下一个任务时只要从 bitmap 里找到第一个置位的位置再取对应链表的头部即可复杂度降为 O(1)。O(1) 调度器把时间片也画得很细高优先级进程时间片长低优先级的短。运行完时间片的进程从 active 数组移到 expired 数组等 active 数组全空了两个数组再整体交换。这保证了每个优先级的进程都能推进不容易饿死。但 O(1) 有个著名的毛病对交互式进程的“睡眠补偿”逻辑过于复杂并且容易误判。一个进程如果频繁睡眠比如等待键盘输入调度器会认为它是交互式的动态调高它的优先级可如果一个进程故意“睡一下再醒”也能骗到高优先级从而霸占 CPU。这导致桌面交互体验时好时坏而且那段启发式代码里充满 magic number维护起来极其痛苦。3.3 CFS 的“完全公平”到底是怎么算的Linunx 2.6.23 引入了 CFSCompletely Fair Scheduler完全公平调度器设计哲学和 O(1) 完全不同。它不再维护“时间片 优先级数组”而是试图模拟一个理想的多任务 CPU假设系统里有 n 个可运行进程那么在一个调度周期内每个进程应该各获得 1/n 的 CPU 时间。但现实没法做到如此精确地“同时”运行多个进程CFS 就用一个虚拟时钟来逼近理想状态。每个进程维护一个vruntime虚拟运行时间它按实际运行时间累加累加速度与进程权重成反比。权重高的进程vruntime涨得慢权重低的涨得快。CFS 每次选下一个进程时就选vruntime最小的那个——也就是“当前被亏待得最厉害”的进程。数据结构上用红黑树来组织每个进程作为一个节点按vruntime排序最左节点就是最小者。插入、删除、查找都是 O(log n)比 O(n) 的链表扫描高效太多同时也弱化了优先级数组那种生硬的“分桶”感觉而是用一条连续的“公平”标尺把所有普通进程放在一起排序。这里的调度周期不是固定值它与进程数和系统配置有关目标延迟sched_latency_ns默认 6ms除以进程数得到每个进程的理论时间片但不能小于最小粒度。举例说明如果系统只有 2 个普通进程CFS 大概会把 6ms 分成 3ms3ms但如果有 100 个进程每个分 60 微秒就太小了于是 CFS 会拉长周期保证每个进程至少能跑一个最小粒度。这就是为什么负载越高进程轮转一圈的时间越长。3.4 调度类所有调度策略的统一框架当前内核的调度不是单一算法而是一组“调度类”的组合。每个调度类负责一类策略调度器在每个 CPU 上通过sched_class的优先级顺序调用它们。从高到低依次是调度类覆盖的策略适用场景stop_sched_class停止调度CPU 热插拔、migration 等内部操作dl_sched_classSCHED_DEADLINE有硬实时截止时间的任务如音视频处理rt_sched_classSCHED_FIFO / SCHED_RR实时任务需要确定性的响应时间fair_sched_classSCHED_NORMAL / SCHED_BATCH / SCHED_IDLE普通进程、后台批处理、空闲优先级idle_sched_classidle 线程每个 CPU 上无事可做时跑的空转线程普通进程的nice只是影响fair_sched_class内部的权重不会让它跳到rt_sched_class。想进入实时调度类要么用chrt工具要么通过sched_setscheduler系统调用显式设置。实时调度类用的是严格的优先级抢占同一个优先级下SCHED_FIFO只有等任务主动让出 CPU 才切换SCHED_RR则加了时间片轮转避免一个任务永久占住核心。这套分层结构的优点在于不同性质的任务用不同的规则互不干扰。普通负载再高只要实时任务就绪就必须让路。代价则是如果你不小心把一个 CPU 密集型的程序设成了SCHED_FIFO而且优先级很高它可以轻易地让整个系统的普通进程寸步难行——这是非常常见的线上事故。4. 调度时机与调度流程拆解4.1 一次调度发生在什么时刻很多初学者以为调度器是一个“后台线程”每隔一段时间跑一次选个进程出来。实际上调度是事件驱动的它在一些特定时机被触发进程主动让出 CPU比如调用sleep()、等待 IO、获取互斥锁阻塞。这时进程会直接调用schedule()告诉调度器“我现在不跑了换人”。时钟中断唤醒调度每个 CPU 都有周期性的 tick通常 1ms 到 4ms 一次由CONFIG_HZ决定。tick 处理完后会检查当前进程运行时间是否超出“应得份额”如果超了就设置一个重新调度的标记need_resched。中断/系统调用返回用户态时即使内核里发生了抢占标记也不会立刻切换而是等到安全时机——最常见的是从内核态返回用户态的前夕。此时检查need_resched如果置位就调用schedule()。唤醒进程时比如一个进程等待的 IO 完成了内核唤醒它唤醒路径可能会考虑是否需要抢占当前正在运行的进程。可以看到调度并不是“随便某个指令之间”就能发生的。内核在任意时刻都可能处于各种临界区必须保证切换时数据一致性所以真正的切换往往被推迟到“安全点”。理解这一点你就能明白为什么网络包到了、IO 完成了你的进程可能还是会延迟一小会儿才被唤醒——中间还隔着一个调度安全的检查点。4.2 CFS 一次完整选路过程把一次典型的 CFS 抢占流程串起来大致是这样的硬件时钟中断触发进入内核的 tick 处理。tick 里调用scheduler_tick()进而调到 CFS 的task_tick_fair()。CFS 更新当前进程的vruntime并检查它是不是已经运行了“足够长”的时间是否需要被其他进程抢占。如果判定需要抢占就往当前进程的thread_info里设置TIF_NEED_RESCHED标记。中断处理结束返回用户态的前夕内核看到need_resched调用schedule()。schedule()找到当前 CPU 对应的rq调用pick_next_task()按调度类优先级依次询问谁能提供下一个任务。CFS 的pick_next_task_fair()找到当前cfs_rq红黑树的最左节点也就是vruntime最小的调度实体。执行真正的上下文切换保存旧进程现场、恢复新进程现场然后返回用户态继续跑新进程。这里面最容易被忽略的一步是第 4 步到第 5 步的“延迟”。need_resched只是打了个标记真正的切换要等中断返回路径检查。如果这个中断发生在内核态且内核没有开启完全内核抢占那么切换点还会再往后拖。因此你看到的“调度延迟”其实由两部分组成排队延迟轮不到它和切换延迟标记到真正切换之间的时间差。4.3 preempt_count 和内核抢占模型为什么内核不能在任何指令边界都响应need_resched因为内核里存在大量临界区——比如正在操作链表、正在持有自旋锁、正在修改某个核心数据结构。如果这时突然切走当前进程新进程可能再次进入同一个临界区带来锁的持有者被“冻结”、死锁甚至数据损坏。内核用preempt_count来跟踪当前是否在临界区。当它大于 0 时调度器即便看到need_resched也不会马上切换只记录“欠着一次抢占”等preempt_count归零后再处理。这就是为什么有些版本的 Linux 支持“内核抢占”但依然强调只在安全点切换。用现实例子来解释你不能在医生缝合到一半时把他拽走去给另一个病人做手术。他手里的器械和操作对象都处于中间状态强行换人会出医疗事故。操作系统也一样只有在“手术台状态稳定”的点才允许换人。5. 多核时代的负载均衡5.1 per-CPU runqueue 的问题多核下如果每个 CPU 各自维护 runqueue 并自行其是很容易出现严重的不均衡一个核上有 50 个进程排队另一个核却空空如也。这不只是资源浪费还会造成延迟抖大。所以内核还需要一个额外的机制把任务在多个 CPU 之间挪动这就是负载均衡。负载均衡的复杂度在于不能只看“队列长度”。有些进程刚在一个核上跑完cache 和 TLB 还是热的如果被迁移到另一个核冷 cache 会导致运行效率下降。所以在做负载均衡时内核要在“均衡度”和“迁移成本”之间博弈。一个跑了几毫秒就被迁走的进程可能比不迁移更慢。5.2 三类负载均衡路径现代内核的负载均衡主要发生在三个时机周期性均衡periodic每个 CPU 在 tick 中断里周期性检查自己的负载尝试从最忙的 CPU 拉任务过来。这种均衡动作比较保守频率不高防止频繁迁移。空闲均衡idle当某个 CPU 进入 idle 状态、没有任务可跑时它会扫描其他 CPU 的 runqueue看看有没有可迁移的任务。这是“闲核主动找活干”的过程。唤醒均衡wake affine当一个进程被唤醒时调度器会判断这个进程之前跑在哪个核、那个核现在忙不忙。如果“老家”核负载不重就把它唤醒到原核利用 cache 亲和性如果原核已经很忙就找个更闲的核。内核还有一个 domain 的概念把 CPU 按物理拓扑超线程、多核、NUMA 节点分成层级。负载均衡先看同一个物理核内的两个超线程再看同一个 L3 缓存域内的核再看整个 NUMA 节点逐级进行。这里每个 level 的迁移成本不同决策参数也不同。5.3 为什么会出现“一核有难多核围观”实际工作中最常遇到的不均衡现象是top显示某个 CPU 跑到 100%其他核很闲。常见原因有三个进程绑核用taskset或sched_setaffinity把进程限定在某个 CPU 上负载均衡无法把它迁走。中断绑核网卡的中断IRQ如果不做 irqbalance可能全部涌到一个 CPU 上导致该核被软中断打满普通进程挤不进去。cpuset 限制cgroup 的 cpuset 子系统把任务限定在一个子集内均衡器只能在允许的范围内搬任务。排查这类问题先用pidstat -t看每个线程在哪个 CPU 上再用cat /proc/interrupts看中断分布最后确认有没有 cpuset 限制。很多时候问题不是调度器的均衡算法不行而是配置把调度器的双手绑住了。6. 排查调度问题的一些实操经验6.1 先判断进程是不是真的“没被调度”遇到“应用卡死”的第一反应不该是调优先级而是先确认进程处于什么状态。用top看状态列R表示正在运行或可运行D表示不可中断睡眠通常等磁盘 IOS表示可中断睡眠等事件。如果大量线程是D状态问题在 IO 而不是调度。再配合pidstat -d看线程的 CPU 使用率如果某个线程 CPU 占用接近 0 但状态频繁切换那可能是锁竞争或唤醒延迟问题。调度器只是保证它“有资格跑”不保证它“能马上跑”——排队和睡眠是两回事。6.2 查看调度参数和实时优先级查看某个进程用的调度策略直接执行chrt -p 12345输出会显示SCHED_NORMAL、SCHED_FIFO等。如果是实时任务还能看到优先级。修改策略用chrt -f -p 80 12345 # 设为 FIFO优先级 80 chrt -r -p 99 12345 # 设为 RR优先级 99普通进程调 nice 值nice -n -5 ./myapp # 启动时设置 renice -n -5 -p 12345 # 运行时调整注意普通用户只能调高 nice 值降低优先级只有 root 能调低 nice 值或设置实时策略。这样设计是为了防止普通用户把自己的进程排到系统关键任务前面。6.3 三个典型调度问题的排查记录问题一后台任务拖垮前端响应某次线上问题机器 CPU 使用率 90%但服务延迟飙升。排查后发现是一个日志压缩任务以高优先级在跑把大量 CPU 吃掉了。解决办法不是立刻杀掉任务而是用renice把它降到最低优先级或者用cgroup的cpu.shares限定它最多只能用一部分 CPU。这里有个经验不要给后台离线任务设默认优先级把所有批处理任务统一放到低优先级“车道”能避免绝大多数干扰。问题二实时任务把系统搞“冻结”有同学在一个工控项目里把采集线程设成了SCHED_FIFO优先级 99。结果某天采集线程里因为一个死循环拼命烧 CPU所有普通进程——包括 sshd、监控 agent——全都被饿死机器看着像“死机”只能断电重启。这是典型的“实时任务事故”。教训有两条一是实时任务的代码质量必须更高二是永远不要让普通任务依赖与被实时任务抢占设置实时优先级前用cgroup的cpu.rt_runtime_us限制实时任务总 CPU 配额。问题三唤醒延迟导致接口偶发变慢服务 P99 高但平均延迟正常典型的“尾部延迟”问题。用perf sched等工具抓调度事件发现有线程从睡眠到被唤醒耗时几毫秒到几十毫秒不等。进一步查原来是某个 CPU 上有高优先级的中断风暴唤醒唤醒路径经常被抢占。后来把网卡中断分散到多个 CPU 并绑核后P99 明显下降。6.4 常用参数与速查表调度器相关内核参数存在/proc/sys/kernel下常用的有参数默认值含义sched_latency_ns6000000 (6ms)CFS 目标调度延迟决定调度周期sched_min_granularity_ns750000 (0.75ms)CFS 最小调度粒度sched_wakeup_granularity_ns1000000 (1ms)唤醒进程后是否需要抢占当前任务的最小差值sched_rt_period_us1000000 (1s)实时任务 CPU 配额周期sched_rt_runtime_us950000 (0.95s)每个周期内实时任务最多可占用的 CPU 时间知道这些参数后你可以解释很多现象。比如sched_wakeup_granularity_ns设得太大则唤醒的进程即便vruntime很小也不一定立刻抢占当前进程交互延迟会升高设得太小频繁抢占又导致切换川大。cgroup 的 CPU 子系统也是调度器的“前端控制面板”。cpu.shares控制 CFS 权重比例cpu.cfs_quota_us控制周期内最多可用的 CPU 时间。比如限制某个容器最多用 2.5 个核echo 250000 /sys/fs/cgroup/cpu/myapp/cpu.cfs_quota_us echo 100000 /sys/fs/cgroup/cpu/myapp/cpu.cfs_period_us这在共享机器上比调 nice 更精准因为 nice 是“相对优先级”cgroup 配额是“绝对上限”。7. 最后说几个我一直留着的“心法”调度器这块内容短期内不会让你直接写出更快运行的代码——你改业务逻辑往往比调调度参数收益更大。但它能帮你解释很多奇怪现象为什么机器负载不高但服务卡顿为什么某个进程在top里一直 R 但就是跑得慢为什么多核机器上总有一个核特别忙。我的习惯是每次遇到“莫名其妙”的性能问题先花两分钟跑一遍调度相关的检查——chrt -p看策略、taskset看绑核、perf sched看调度延迟、cat /proc/loadavg结合top看可运行队列长度。大部分时候这并不能直接解决业务问题但它能快速排除调度层面的嫌疑。真正的排查高手不是懂得所有深奥难懂的算法细节而是能用最短的时间把“不可能的原因”逐个划掉。如果你刚接触这块建议先别急着扣源码。先把 CFS 的vruntime、红黑树、调度类、负载均衡这四个概念在脑子里画成图然后去/proc/schedstat和perf sched里观察真实的调度行为。纸上得来终觉浅调度器这种和硬件行为强相关的东西永远是“眼见为实”。我见过太多人把源码背得滚瓜烂熟一遇到线上问题还是不知从哪下手反倒是那些天天和pidstat、perf打交道的人定位问题快得惊人。工具用熟了再去回看源码整个系统就像在你面前摊开一样。