CPU 怎么做到一边刷网页一边跑编译从内核视角拆解任务切换的两种上下文我做后端性能调优有些年头了每次遇到系统响应变慢、吞吐量上不去第一件事就是去看上下文切换。很多人对“上下文切换”的理解停留在字面不就是把 CPU 从任务 A 换到任务 B 嘛。可真要追下去——具体切了什么、哪些操作是致命的、为什么某些场景下切换开销高得离谱——能讲清楚的人并不多。这篇文章我想从一个内核开发者的视角把 CPU 任务切换这件事彻底拆开。标题里说的“两种上下文”我指的是寄存器上下文和内存上下文。前者是硬件状态后者是地址空间状态两者合并起来才构成一次完整的任务切换。整篇文章会落到 Linux 内核的实际代码路径上从schedule()到__switch_to()一步步交代清楚。适合正在看内核源码的人、做嵌入式开发的朋友也适合搞性能分析、老被“上下文切换过高”困扰的运维同学。1. 先搞清楚任务切换到底在“切”什么1.1 一个生活化的类比多人共用一台电脑你先想象一个场景三个人合用一台电脑每个人有自己的工作目录、打开的浏览器标签页和编辑器草稿。为了公平规定每人只能用 10 分钟。张三用完了李四要上来接着用——这时候你至少要做两件事第一把张三当前的工作状态完整保存下来光标在哪、文件改到哪了、浏览器开了哪些页面全得记住不然张三下次回来没法接着干。第二把李四的工作环境恢复出来他上次留下的那些窗口、草稿、目录得重新摆好。CPU 切任务也是完全一样的逻辑。每个进程在使用 CPU 的时候会在寄存器里留下大量“临时状态”比如当前执行到哪条指令PC 指针、栈顶在哪SP 指针、各种中间计算结果通用寄存器。而进程要能正常工作还必须拥有一个完整的虚拟地址空间——页表、内存映射、代码段数据段的位置这些构成了它的“工作目录”。任务切换就是把上一任进程的“工作状态”存档再把下一任进程的“工作环境”完整恢复。前者的核心是寄存器上下文后者的核心是内存上下文。1.2 两种上下文各包含什么先说寄存器上下文。你 CPU 里的通用寄存器x86_64 下就是 RAX、RBX、RCX、RDX、RSI、RDI、RBP、RSP、R8~R15、指令指针 RIP、标志寄存器 RFLAGS再加上段寄存器、控制寄存器 CR3都属于硬件状态。这些寄存器里的数值是进程“瞬间快照”的全部意义——只要完整保存和恢复它们进程就能像没被打断过一样继续跑。再说内存上下文。每个进程有自己独立的虚拟地址空间这是由页表决定的。x86 架构下页表基地址放在 CR3 寄存器里ARM 架构下对应 TTBR0/TTBR1。切换进程时CR3 要换成新进程的页表基址旧进程的页表不能继续用。这意味着整个虚拟地址空间的映射关系都变了CPU 访问任何内存都要走一套全新的翻译流程。这里有个非常关键的细节寄存器上下文属于“硬件状态”内存上下文属于“地址空间状态”。前者只管恢复计算现场后者管恢复“这个进程看到的世界长什么样”。两者缺一不可。注意CR3 寄存器既有寄存器上下文属性它是寄存器的一份子又决定了内存上下文页表基址。所以在内核源码里切换 CR3 往往被划到 mm 切换部分而不是纯寄存器保存部分。后面讲流程的时候你就能看到这个区别。2. 内核视角的切换流程从schedule()到__switch_to()2.1 触发切换的时机主动让出与被动抢占任务切换不是 CPU 自己“想换就换”而是内核在特定时机主动做出的决策。理解这一点才算入了内核的门。触发时机大体分三类主动让出进程自己调用sleep()、等待 I/O、加锁阻塞或者调用sched_yield()明确告诉内核“我暂时不干了”。这时候进程进入睡眠状态内核必然会选一个新的任务来跑。时间片到期进程的时间片用完了即使它还不想让出 CPU内核也会强制把它的运行资格挂起换下一个进程。这保证了一个进程无法长期霸占 CPU。高优先级抢占外部中断唤醒了一个高优先级任务比如实时线程或者新就绪的任务优先级更高内核会在最近的调度点抢占当前任务。无论哪种时机最终都会走到一个统一入口——schedule()函数。我用一个实际例子说明你在终端里敲cat file.txt磁盘 I/O 还没返回时cat进程就阻塞在read()系统调用上。内核在系统调用的返回路径上发现当前任务需要等待于是调用schedule()切到别的进程运行。等磁盘数据到达、中断唤醒cat之后它才重新进入就绪队列。2.2 从schedule()到context_switch()的调用链schedule()是切换的入口但真正的切换动作由context_switch()完成。我把核心步骤拆成一张表方便你对照源码看阶段函数/宏核心动作调度决策schedule()→__schedule()选出 next 任务关抢占切换地址空间context_switch()→switch_mm_irqs_off()CR3 写入新进程页表处理 TLB切换寄存器现场context_switch()→switch_to()当前进程寄存器保存到内核栈恢复 next 寄存器善后处理finish_task_switch()释放旧任务的锁更新统计重新开抢占以上是 Linux 内核主路径的简化模型。两个进程 A 和 B 切换最终控制流是A 的内核栈 → CPU 寄存器 → B 的内核栈这个跳跃不是函数调用而是直接改写栈指针和指令指针。在调试内核时最直观的感受是switch_to()执行完之后当前代码路径的“身份”就变了。你在这个函数里看到的是 A 的寄存器被压栈出来的时候执行流已经站在 B 的代码里了。2.3__switch_to()到底做了什么寄存器的打包与解包__switch_to()是架构相关的汇编级函数它是切换寄存器现场的执行者。x86_64 上内核通过arch/x86/kernel/switch_to_64.S或 C 包装加内嵌汇编来切换栈、保存标记。我先说说task_struct里那个关键的thread字段。每个进程在创建时内核都会为它分配一个thread_struct里面存放的就是首次切换时需要恢复的寄存器初始状态比如新进程第一次运行要执行什么函数、用户栈在哪。switch_to()做的事情可以用一句话概括“把当前 CPU 寄存器倒进当前进程的thread_struct再把下一个进程thread_struct里的寄存器的值倒进 CPU。”我在 32 位 ARM 平台上调过这段路径当时的__switch_to汇编就是典型的保存-切换-恢复三段式// 保存当前寄存器旧进程 stmfd sp!, {r4 - r12, lr} // 压栈 str sp, [r0, #THREAD_SP] // 栈指针存入旧进程 thread 结构 // 切换到新进程 ldr sp, [r1, #THREAD_SP] // 从新进程 thread 结构取出栈指针 // 恢复新进程寄存器 ldmfd sp!, {r4 - r12, lr} // 弹栈注意这段话是伪代码真实内核会用switch_to宏加异常返回机制来实现但原理完全一致。核心要点是保存现场和恢复现场是围绕每个进程自己的内核栈进行的。旧进程的新一轮寄存器快照压进旧进程内核栈新进程的寄存器快照从新进程内核栈弹出。CPU 的寄存器是共享的但每个进程的内核栈是独占的。实操心得跟踪这段代码时别在switch_to()里面设断点设了也没用——执行完这条指令你看到的进程已经变了。我当年调试任务切换是在switch_to()前后分别打印current-pid看到变化的那一刻才算真正理解了“切换”的含义。3. 内存上下文的切换容易被忽略的重头戏3.1 页表切换CR3 写入的连锁反应寄存器切换是显式的、直观的但很多人低估了内存上下文切换的开销。现代 CPU 访问内存依赖虚拟地址翻译翻译的依据就是页表。你的项目就算只改一个字节CPU 也要先走“虚拟地址 → 页表 → 物理地址”的路径。为了加速这个翻译CPU 内部有 TLBTranslation Lookaside Buffer缓存最近的翻译结果。切换进程时CR3 要写入新进程的页表基址。问题来了TLB 里缓存的是旧进程的翻译结果这些结果在新进程的上下文里是完全无效的。如果不清掉CPU 可能把 A 进程的虚拟地址翻译成 B 进程的物理地址这是灾难性的。传统做法是切换 CR3 时全量刷新 TLBx86 的mov cr3操作会让非全局 TLB 项全部失效。代价很明显新进程跑起来后的相当一段时间TLB 是冷的每次访存都可能缺页翻译性能断崖式下降。这也解释了为什么上下文切换频率高的系统整体性能会明显变差——大量时间花在“恢复地址翻译缓存”上了。3.2 PCIDx86与 ASIDARM减少 TLB 冲刷的硬件方案为了解决“一切换就要全刷 TLB”的痛点x86 引入了 PCIDProcess Context IdentifierARM 也有类似的 ASIDAddress Space Identifier。思路都是在 TLB 条目上打标签标明这个翻译属于哪个地址空间。切换进程时如果 TLB 里同时保留了多个进程的翻译条目CPU 通过比对 PCID/ASID 来判定命中与否不需要全量清空。我拿 x86_64 的实践举例内核激活 PCID 后CR3 切写时带上新进程的 PCIDTLB 中旧进程条目留着不清理。下次切回旧进程时它的 TLB 条目可能还有效地址翻译直接命中省去了一次翻译开销。但这带来一个容易被忽视的问题不同 PCID 的 TLB 条目共存可能挤占 TLB 容量。PCID 用 12 位最多 4096 个标识如果系统里活跃进程很多TLB 塞满了不同进程的条目相互挤占命中率反而下降。所以内核在switch_mm_irqs_off()里会根据实际情况判断全量刷新 TLB 还是保留部分条目。这恰恰是很多人调优时忽略的变量。注意PCID/ASID 是硬件特性不是所有平台都支持。做嵌入式开发的朋友要注意目标 CPU 是否具备 ARM 的 ASID 支持没有的话内存上下文切换的代价就是硬性的 TLB 全清对实时性指标影响很大。3.3 内核线程的特殊性不换地址空间的切换前面说的内存上下文切换并不适用于所有情况。内核线程比如 kworker、kthreadd是特殊的存在它们没有自己的用户态地址空间只在内核态运行task_struct里的mm字段是 NULL。按常理切换到一个内核线程时CR3 应该怎么处理答案是继承上一个用户进程的地址空间。在 Linux 中内核线程运行时使用“借用的”mm也就是上一次发生切换的用户进程的页表。这样做的好处非常明显虽然任务切换了但地址空间可能不需要动CR3 可以保持不变TLB 不用因为内存上下文切换受影响。于是我们能看到一个有趣的现象从进程 A 切到内核线程 K再从 K 切回 A如果中间没有切到其他用户进程整个过程中内存上下文一次都没变只有寄存器上下文做了两次保存和恢复。我在测系统调用延迟时发现很多“任务切换开销高”的误判其实是把“内核线程频繁切换”和“用户进程切换”混在一起了。前者的开销远小于后者因为省掉了 TLB 的损失。所以分析性能数据时先判断切换对象里有没有大量内核线程这个细节能避免很多误诊。4. 用户态与内核态模式切换不等于任务切换4.1 系统调用/中断只切栈不切任务初学者最容易把两个概念搞混用户态到内核态的切换模式切换和任务切换上下文切换。我单独把这个问题拉出来讲是因为混淆这两个概念会让你的性能分析报告彻底失真。模式切换发生在一个任务内部。比如进程调用read()系统调用CPU 从用户态陷入内核态会经历这样几个步骤特权级从 Ring 3 切到 Ring 0栈从用户栈切到内核栈相关寄存器尤其是栈指针和指令指针要重新定位但没有进程层面的“换人”发生。系统调用执行完了CPU 回到用户态还是同一个进程接着跑。那为什么模式切换也被很多人戏称“半个上下文切换”因为它的开销也来自保存和恢复现场。Linux 在进入内核态时会把用户态寄存器存到内核栈pt_regs结构里返回时将pt_regs恢复回去。成本几十纳秒到几百纳秒不等比真正的任务切换微秒级起便宜一个量级。4.2 区分两种“切换”的实操判断法给你一个我常用的判断方法不靠文档靠现象如果切换前后的current进程PID 没有变只是特权级变了这是模式切换。如果切换前后的 PID变了哪怕是从进程 A 切到一个内核线程也是任务切换。排查时用perf或者内核 tracepoint 能直接看到sched:sched_switch事件的prev_pid和next_pid一眼辨认。我见过有人拿着vmstat的cs列跟老板汇报“上下文切换单核每秒几十万”但实际上cs列统计的是内核态入口数量其中包含大量系统调用和中断进入并不全是任务切换。这个误读很典型数值看着吓人实际可能只是高并发系统调用。注意事项分析/proc/stat里的ctxt或vmstat的cs先算一下每秒系统调用数。如果二者量级接近那这个“上下文切换”主要是模式切换而非任务切换。任务切换要单独看sched:sched_switch或pidstat -w输出。5. 实战如何观测和排查上下文切换开销5.1 三条常用观测路径直接给命令和解释你可以照着在自己的机器上跑。下面这些工具过去几年帮我在生产环境里定位了不止一次问题。第一看全局趋势用vmstat 1输出里的cs列是每秒上下文切换次数in列是中断次数。如果一个系统cs长期高于in两三倍以上基本可以确定任务切换频繁。第二按进程看用pidstat -w 1cswch/s是自愿切换进程主动让出nvcswch/s是非自愿切换时间片到期或抢占。如果nvcswch/s异常偏高排第一的通常是抢占了太多 CPU 的进程或者 CPU 核数严重不足。第三要精细分析切换路径用perf sched record配合perf sched timehist看单次调度延迟和切换耗时。这个命令能还原每次切换的时间分布帮你判断是调度器决策慢还是取决于上下文切换本身的硬开销。5.2 开销过高的典型场景与调优思路我在这里总结几个我在生产环境里实际踩过的坑和对应的解法有些可能和你预想的“加大 CPU”这种外行思路完全不同。现象可能原因排查/调优方向cs 高但系统负载不高大量短生命周期线程频繁创建销毁改用线程池减少线程数nvcswch/s 高CPU 使用率却不饱和线程数超过 CPU 核数数倍调整线程池大小接近核数切换耗时波动大内存上下文切换导致 TLB 抖动启用 PCID/ASID绑定 CPU 亲核单核 cs 极高且伴随高中断网络软中断频繁唤醒进程开启 RPS/RFS调中断亲和性还有一个容易被忽视的点锁竞争严重时上下文切换会像雪崩一样爆发。多个线程抢同一把锁抢不到就休眠等锁释放又被唤醒内核来回切换。这种场景光靠调调度器参数是没用的得从锁粒度、锁类型下手比如用rwlock、seqlock替代互斥量或者改成无锁结构。5.3 我自己常用的几个内核参数与技巧kernel.sched_autogroup_enabled默认开启。它会自动把同终端下的进程分到同一个调度组平均分配 CPU。生产环境里如果你希望每个进程被独立调度有时要关掉它但大多数场景保持默认就好。kernel.sched_min_granularity_ns调小这个值可以让调度器更频繁切换但代价是开销增加。追求吞吐量的服务器一般调大追求交互响应的桌面调小。绑定 CPU 亲和性taskset或sched_setaffinity把一组高频协作的线程绑到固定几个核上能显著减少“跨核迁移 TLB 刷新”的额外开销。我测过一些场景仅这一项就能把切换相关的延迟降低 20%~30%。实操心得生产环境改动调度器参数我坚持“一次只改一个变量、灰度一批机器”的原则。调度器参数牵一发动全身改完要盯至少几天的vmstat、负载和延迟分位数不能看完十分钟就下结论。在项目日志调整过后我通常还会多留一份sched:sched_switch的 trace 数据做对照。原因很简单调优是个反复实验的过程没有基准数据后面讨论任何“是否有效”都是空话。6. 关于“两种上下文”的最终理解所谓两种上下文最后落到代码上就是这两个动作保存/恢复寄存器switch_to和切换地址空间switch_mm。一个管“继续算”一个管“看到什么”。理解了这两个动作你再回去看调度器代码、看性能报告中的上下文切换数值、看内核线程是否有 mm会清晰得多。Linux 内核里的很多设计——比如schedule()的调用时机、task_struct里thread结构的内存布局、PCID 和 ASID 的引入——全都是围绕这两个核心动作展开的。我个人看代码时的体会是任务切换看起来是“调度器选下一个任务”的决策问题实际上更像“如何最小化两个状态切换代价”的工程问题。寄存器上下文切换再快扛不住内存上下文切换的 TLB 冷启动内存上下文切换做得再好也绕不开寄存器保存恢复这条必经之路。真正的高手做优化时注意力往往不放在让switch_to更快而是想办法减少切换发生的次数——把活干完比切换得更快更重要。最后分享一个我的小习惯拿到一份系统响应慢的排查请求我总会先看一眼/proc/pressure/cpuPSI 数据里的 CPU 压力值再结合pidstat -w判断是调度延迟还是切换本身成了瓶颈。CPU 压力高说明任务排队等 CPU要减负载切换开销高说明调度过于频繁要降频率或改亲和性。这两个方向完全不同错过一个排查就会绕远路。
