进程上下文管理的核心是精确保存并恢复CPU寄存器、程序计数器、虚拟地址空间（页表基址）、内核栈及进程环境资源，通过switch_mm_irqs_off和switch_to两阶段完成切换，确保进程无缝续执行。
进程上下文管理的核心，是让操作系统在多个进程间快速、安全地交出 CPU 控制权，同时保证每个进程“醒来”时能无缝接续——就像暂停播放的视频，再点播放时从同一帧继续。这背后不是简单跳转，而是对寄存器、内存映射、文件资源等状态的精确快照与还原。
上下文到底保存什么
上下文不是抽象概念，而是可落地的数据集合：
- CPU 寄存器和程序计数器（PC）：记录指令执行到哪一步、栈在哪、临时计算结果存在哪；这是切换后能“接着算”的基础
- 虚拟地址空间信息：主要是页表基址（如 ARM64 的 TTBR0_EL1 或 x86 的 CR3），决定进程看到的内存布局；切换进程必须换页表，否则会访问错的内存
- 内核态栈与线程本地存储：进程在内核中运行时使用的栈空间，以及信号处理、fpu 状态等运行时上下文
- 打开的文件描述符、当前工作目录、umask、资源限制等：这些属于进程级环境，虽不参与 CPU 切换瞬间，但被保存在 task_struct 中，确保恢复后行为一致
切换过程分两步走：地址空间 + 执行状态
Linux 内核实际执行时，把上下文切换拆成两个关键阶段：
- switch_mm_irqs_off()：先切换 mm_struct，更新 MMU 页表基址。这一步开销大，尤其当 TLB 缓存失效时，后续访存会触发大量缺页异常
- switch_to()：汇编级操作，保存当前寄存器（sp、pc、x19–x28 等），加载目标寄存器，完成真正控制流跳转。它不直接操作内存，但依赖前一步已就位的地址空间
两者不可颠倒：必须先让新进程的虚拟内存“就绪”，再让它开始执行，否则第一条指令就可能访问非法地址。
为什么进程切换比线程慢
根本差异在于地址空间是否共享：
- 同一进程内的线程共用一个 mm_struct，切换时跳过 switch_mm，只做 switch_to，省掉页表切换和 TLB 刷新开销
- 进程切换必然触发 MMU 重配置，伴随 TLB flush、缓存行失效（cache line invalidation），现代 CPU 上一次完整进程切换常耗时 1–5 微秒，而线程切换通常低于 100 纳秒
- 频繁 fork() 或创建短命进程（如 CGI 模式），极易成为性能瓶颈；改用线程池或协程模型，能显著降低上下文切换频次与代价
可观测与调优的关键点
判断上下文切换是否成为瓶颈，不能只看总数，要看场景和代价：
- 用 pidstat -w 或 vmstat 1 观察每秒 cs（context switch）值；持续高于 10k–20k 可能需关注
- 结合 perf record -e sched:sched_switch 追踪谁在频繁切换、为何阻塞（如锁争用、IO 等待）
- 避免无谓切换：减少不必要的系统调用（如高频 gettimeofday）、用非阻塞 IO 替代轮询、合理设置线程数而非盲目加进程
- 底层优化可行项：启用 HugePages 减少 TLB miss；调整调度策略（如 SCHED_FIFO 用于实时任务）；关闭 NUMA balancing 若业务绑定固定 CPU
