一次上下文切换在 CPU、汇编、内核调度、FPU、信号、返回路径上到底发生了什么。
1. 一般我们以为的上下文切换，其实还是有差别的
在工程实践中，“上下文切换”还是有一些差别的。很多人把“从 A 进程跑到 B 进程”当成上下文切换，也有人把“系统调用进入内核”也算进去。
但如果从实现角度拆开，会发现上下文切换其实有三个层次：
硬件上下文切换：寄存器、特权级、栈指针等最底层状态改变
调度上下文切换：内核从一个 task_struct 切换到另一个 task_struct
语义上下文切换：用户态/内核态之间的执行语义发生变化
真正“完整”的上下文切换，必须满足这三条。
而最常见的误判是：
系统调用进入内核并返回，不等于任务切换。
它只是一种“特权级切换”，没有改变调度对象。所以 perf stat -e context-switches 统计的并不是你想象中的“系统调用开销”。
2. CPU 硬件层面的上下文切换：它并不知道“进程”
CPU 本身不知道“进程”是什么，它只知道：
当前指令地址 RIP/EIP
寄存器文件内容
当前特权级（CPL / EL）
当前栈指针 RSP/SP
当前段寄存器/页表基址等（部分由硬件自动维护）
因此，“上下文切换”在硬件层面只是状态变化。真正的“进程切换”是软件（操作系统）构建的一套约定与执行路径。
3. 从用户态到内核态：上下文切换的第一道门
3.1 x86-64 的 syscall 入口
x86-64 的 syscall 不是普通的函数调用，而是一个特殊指令。它触发 CPU 做三件事：
切换特权级：CPL 从 3 -> 0
切换栈：RSP 变成 TSS 指定的内核栈
跳转：RIP 跳到 MSR_LSTAR 指定的地址（内核 syscall 入口）
关键是：
CPU 不会保存通用寄存器。因此内核必须在入口处尽快保存用户态寄存器。
这也是 entry_64.S 里汇编看起来“非常冗长”的原因：它的第一件事就是把用户态寄存器保存到内核栈（pt_regs）中。
3.2 pt_regs：内核对用户态寄存器的镜像
Linux 通过 struct pt_regs 记录一份用户态寄存器快照，它不仅用于：
更重要的是，它构成了“用户态上下文”的内核镜像。
这也是为什么 pt_regs 的布局极其敏感：它是一种 ABI（内核内部 ABI），任何改变都会影响到大量子系统。
4. 内核栈、thread_info、current：你以为是“方便”，其实是必须
4.1 内核栈的设计：为什么只有 8KB/16KB？
内核栈必须足够小，原因并不是“节省内存”。而是因为内核栈必须放在 CPU 缓存里，并且避免：
栈溢出导致安全漏洞
大栈导致上下文切换成本上升
多核系统中栈压缩带来的维护复杂性
所以 Linux 选择了一个“最小可用”的栈，并强制要求内核代码避免递归和大数组。
4.2 thread_info 为什么从栈底移除？
早期 Linux 的 thread_info 结构放在内核栈底部，通过 current_thread_info() 快速获得 current 指针。
但这带来了一个严重问题：内核栈越小，thread_info 的空间越紧，而 thread_info 还要存很多东西（flags、preempt_count、addr_limit 等）。
因此后来 Linux 将 thread_info 的大部分内容移出栈，改成：
current 仍可通过栈基址快速获取
但其他线程信息不再占用内核栈空间
这是一个典型的“工程妥协”：为了性能保持快速访问，同时避免栈空间被占满。
5. 调度：上下文切换的核心控制点
真正的任务切换从哪里开始？很多人以为是 schedule()，但事实更复杂。
5.1 调度的触发条件：preempt 和 need_resched
任务切换不由 schedule() 单独触发，而是由：
need_resched 标记
preempt_count 允许的前提
决定的。
比如：
这就是为什么你看到的“某些系统调用非常慢”，并不一定是 syscall 本身慢，而可能是中断触发的调度延迟。
5.2 schedule() 的真实含义
__schedule() 的真正作用不是“切换任务”，而是：
找到下一个要运行的 task_struct
处理各种调度策略、优先级、CPU 亲和性等
调整 runqueue
调用 context_switch() 执行真正的寄存器切换
因此 schedule() 只是一个“调度决策”接口，真正的上下文切换发生在 context_switch() 里。
6. switch_to：最核心但最不直观的函数
switch_to() 看起来像函数，但它不是普通函数。它的核心是：
保存当前任务的寄存器
恢复下一个任务的寄存器
通过汇编完成跨任务跳转
它之所以不直观，是因为它必须满足：
兼容不同 CPU 架构
兼容不同寄存器集
兼容抢占、调试、FPU 等复杂条件
因此它被实现成一段极度“低级”的汇编，并被强制内联（inline）以保证性能。
7. FPU / SIMD：上下文切换的隐形成本
你可能会惊讶：真正让上下文切换变慢的，并不是寄存器保存本身，而是 FPU 状态。
7.1 eager save vs lazy save
Linux 不会在每次切换时都保存 FPU 状态，而是采用“懒保存”：
这能节省大量开销，但带来一个问题：
如果你在内核中使用 FPU（一般不允许），会破坏用户态的 FPU 上下文。
因此内核对 FPU 的使用非常严格，必须在切换前处理好。
7.2 XSAVE/XRSTOR 的代价
现代 x86 的 FPU 状态包含：
而 XSAVE/XRSTOR 需要保存/恢复全部状态，代价非常大。
因此：
频繁切换带来的开销会成倍增长
这也是为什么高性能场景尽量避免频繁切换
8. 从内核态返回用户态：ret_to_user 的意义
上下文切换完成后，CPU 并不是立刻回到用户态。内核必须确保：
用户态寄存器已恢复
栈指针正确
特权级正确
中断状态正确
信号处理、ptrace、调试等条件都处理完
这就是 ret_to_user() 的作用。
8.1 为什么返回用户态比进入内核复杂？
因为返回用户态涉及的东西更多：
可能要处理 pending signal
可能要处理 resched
可能要处理 debug trap
可能要恢复 FPU 状态
因此 ret_to_user() 是一个非常关键的“出口”，也是很多 bug 的集中地。
9. x86 vs ARM64：两种不同的实现哲学
9.1 x86 的“硬件帮你做很多事”
x86 的中断/系统调用路径由硬件自动压栈，并且：
自动保存 RIP/CS/RFLAGS
自动切换栈
自动处理特权级切换
因此 x86 的内核入口看起来更“简单”。
代价是：
硬件压栈结构固定，内核必须适应
一些寄存器保存必须由软件补齐
9.2 ARM64 的“软件全权负责”
ARM64 的异常入口不自动压栈，必须由软件保存全部寄存器。
这意味着：
入口代码更长
但灵活性更强
内核可以决定保存哪些寄存器、什么时候保存
从可维护性角度看，ARM64 的实现更“干净”，但更复杂。
10. 你在工具里看到的“上下文切换”统计，真正意味着什么？
10.1 perf stat -e context-switches
统计的是：
例如：
都可能导致 context-switches 增加。
10.2 为什么上下文切换次数少，系统不一定快？
因为真正耗时的是：
FPU 状态保存/恢复
TLB flush（在某些场景）
缓存失效（最关键）
调度决策本身的复杂度
因此你会看到：
上下文切换次数少，但仍然卡或者切换次数多，但仍然流畅
这取决于负载的“局部性”和“资源竞争”。
11. 上下文切换为什么慢，是必须慢吗？
上下文切换本质上是一个“从 A 的世界切换到 B 的世界”的过程：
A 的寄存器要保存
B 的寄存器要恢复
缓存要重新填充
TLB 可能要刷新
FPU 状态可能要切换
调度策略要做决策
信号、抢占、debug 需要处理
这不是一个“可以优化到很快”的过程，而是一个必须付出代价的机制。
真正的性能优化不是“减少上下文切换”，而是：
降低切换的必要性（更长的运行片段）
提高局部性（减少缓存失效）
降低 FPU 状态切换频率
合理设计调度策略
10个月宝宝每天需要喝多少奶粉？