Linux 用户态与内核态切换的真实成本

一次 write() 系统调用在现代 x86-64 linux 上耗时 300–800 ns，约 60% 开销来自态切换本身，比用户态调用高 1–2 个数量级。

系统调用一次到底多贵？

不是“慢”，而是有明确的纳秒级开销：现代 x86-64 Linux 上一次 write() 系统调用，典型成本在 300–800 ns（不含实际 I/O），其中约 60% 花在态切换本身——保存用户寄存器、切换栈、验证参数、恢复上下文。这比纯用户态函数调用高 1–2 个数量级。

实操建议：

• 用 strace -T ./your_program 直接看每个系统调用耗时，-T 显示真实时间，不是估算
• 对比 write(fd, buf, 1) 和 write(fd, buf, 4096)：小量高频写会把切换开销放大数倍，而批量写几乎不增加切换次数
• 别信“一次系统调用无所谓”——高并发服务里每秒几万次切换，CPU 时间就悄悄被吃掉 5–10%

mmap 为什么能绕过切换？

mmap() 把文件直接映射进用户地址空间后，读写就像操作普通内存，不再触发 read()/write() 切换。但代价是：首次映射仍需一次系统调用，且页错误（page fault）时内核要介入加载数据——这不是“无切换”，而是把切换延迟到真正访问时，并可能合并多次访问。

容易踩的坑：

• 映射大文件后没 msync() 就退出，修改可能丢失（尤其 MAP_PRIVATE）
• MAP_POPULATE 参数看似预加载能避免页错误，但会阻塞映射过程，反而拉长首次响应时间
• 小文件用 mmap 反而更慢：映射/解映射开销 > 节省的切换收益

为什么 strace 会让程序变慢十倍？

strace 不是“只看不碰”，它通过 ptrace() 强制每个系统调用都陷入内核并通知 tracer 进程——相当于每次切换后多加一次完整上下文切换 + IPC 开销。真实开销常达原生的 5–15 倍，尤其对高频调用如 gettimeofday() 或 epoll_wait()。

替代方案更轻量：

• 查系统调用频次用 perf stat -e 'syscalls:sys_enter_*' ./app（开销低至 1–2%）
• 定位热点系统调用用 perf record -e 'syscalls:sys_enter_write' -g ./app && perf report
• 调试权限或路径问题，优先用 ls -l /proc//fd 看 fd 状态，而非全程 strace

内核态耗时高 ≠ 切换太多

看到 top 中 %sy（内核态 CPU 使用率）飙升，第一反应不该是“减少系统调用”，而要区分：是切换太频繁（cs 高），还是单次内核工作太重（比如加密、压缩、复杂路由）？

快速判断方法：

• 运行 vmstat 1，观察 cs（context switch）列：持续 > 50k/s 才算高频切换
• 用 pidstat -w 1 看具体进程的 cswch/s（自愿切换）和 nvcswch/s（非自愿切换）：前者多说明频繁等资源（如锁、I/O），后者多才真可能是调度压力大
• %sy 高 + bi/bo（块设备 I/O）也高 → 大概率是磁盘驱动在内核里忙，不是你的代码切多了

真实成本藏在组合效应里：一次 sendfile() 看似一个系统调用，但它内部可能触发页锁定、DMA 设置、中断处理——这些都在内核态完成，却不额外增加“切换次数”。优化时盯住的是最终延迟和吞吐，不是单纯数 strace 输出的行数。