system call是否涉及context switch？维基词条表述矛盾答疑

你觉得两段表述矛盾，本质是两个基础认知出现了偏差，拆解开就完全通顺：

• 第一个错误认知：内核不是一个独立的、和用户进程并列的“另一个进程”。内核是常驻内存、运行在CPU最高特权级的代码集合，所有进程的地址空间里都固定映射了同一份内核代码段，内核代码永远是替当前正在CPU上运行的执行流服务的，本身不是调度器管理的独立调度实体，根本不存在“切到内核进程”这种说法。
• 第二个错误认知：把特权级切换和进程上下文切换混为一谈，这两个操作的成本、逻辑、触发场景完全不一样：
  • 特权级切换是系统调用的标准动作：不管是早期靠软中断触发，还是现代CPU靠syscall/sysenter这类专用快速指令触发，本质都是CPU按照硬件预设规则，从低特权级的用户态（x86架构下的ring3）跳转到高特权级的内核态（对应ring0）执行。这个过程只会把用户态的必要寄存器值临时保存到当前进程专属的内核栈上，页表还是沿用当前进程的（内核地址部分是所有进程共享映射的），调度器完全不介入，执行完内核逻辑直接把保存的寄存器恢复，跳回用户态继续跑原进程的代码，全程没有更换执行主体。
  • 进程上下文切换才是维基百科末尾提到的“切换到其他进程”的操作：这个动作必须由内核调度器主动触发，会把当前进程的全量执行状态（所有寄存器值、栈状态、页表基址、执行进度等）全部存到该进程对应的进程控制块里，再把之前存好的另一个就绪进程的状态加载到CPU上，把CPU使用权完全交给另一个独立进程，这个操作的成本比单纯的特权级切换高几个数量级。

维基百科两段表述的对应解释 #

词条开头提到的“interrupt会将控制权转交给kernel”，描述的就是上面说的特权级切换动作：CPU响应系统调用请求后，暂停执行用户态的应用代码，跳转到当前进程地址空间里映射的内核代码段入口，执行高特权级的内核逻辑——这个跳转只是权限和执行流位置的变化，执行主体还是发起调用的原进程。
词条末尾提到的“system call通常不需要执行切换到其他进程的context switch”，说的是绝大多数系统调用的执行全程都不会触发调度器介入，不会把CPU切给别的进程，内核逻辑跑完就直接回到原进程用户态，整个系统调用是在原进程的执行上下文里完成的。

补充一个容易混淆的边界情况：如果系统调用执行过程中遇到需要等待的慢速事件（比如读磁盘、等网络包），内核会主动把当前进程挂起，触发一次进程上下文切换让CPU先跑别的就绪进程，等事件完成再切回来。但这是系统调用内部的阻塞逻辑触发的可选操作，不是系统调用本身的必须流程，所以词条才会用“通常不需要”的表述。

内容的提问来源于stack exchange，提问作者Solver