SYSCALL/SYSRET 指令如何跨 x86 CPU 执行？答案

【问题标题】：How do SYSCALL/SYSRET instructions perform across x86 CPUs?SYSCALL/SYSRET 指令如何跨 x86 CPU 执行？
【发布时间】：2013-08-09 12:58:51
【问题描述】：

SYSCALL 和 SYSRET（以及它们的 32 位 Intel 对应的 SYSENTER 和 SYSEXIT）通常被描述为在 x86 处理器中进入和退出监督模式的“通常更快”的方式比调用门或软件中断，但这种说法背后的确切数字在很大程度上仍然没有记录。特别是，我能找到的所有 Intel 或 AMD 优化指南都没有提到这些指令。所以：

SYSCALL 和 SYSRET 在最近的 Intel 64 微体系结构中占用多少个周期（估计）？这可能可以通过直接实验来衡量，但有很多不同的 CPU 需要测试。

根据这个数字的数量级，可能会有更详细的问题：

它们是否会导致完整的管道停顿或任何其他类型的停顿？
如果有的话，它们如何与分支预测（例如返回堆栈缓冲区）和获取逻辑进行交互？
延迟、数据依赖、序列化呢？
&tc.

假设用户空间端使用 64 位代码，没有额外的地址空间切换（写入 CR3），甚至匹配 SYSCALL 和 SYSRET 对（如果重要）。

【问题讨论】：

lkml.org/lkml/2002/12/9/13 - 这是带有基准的原始发布。这些天来这些数字会有所不同，我猜。 Agner Fog 的延迟/吞吐量表也应该让您有所了解。
@FrankH。我希望这些数字会有相当大的变化： P4 的管道对上下文切换的友好程度远低于例如 P4 的管道。珊迪大桥。当Bachmann and Walfield 报告两个系统调用的 250 左右时，getpid() 的 600 左右的周期看起来令人怀疑。遗憾的是，Agner Fog 没有测量SYS* 指令。
我说我确实希望它们会有所不同 - 上面的参考资料已经有 11 年的历史了。有点和相当之间的区别我会留给旁观者的眼睛:)从这个意义上说，我只是给出了链接，因为它描述了完成的基准那时 - 这意味着你可以在当前的 CPU 上重复它，现在，如果你喜欢/如果你有它们可用的话。不过，不知道最近有人这样做过。
2010 年有一篇关于实际系统调用成本的论文：cs.cmu.edu/~chensm/Big_Data_reading_group/papers/…“FlexSC：具有无异常系统调用的灵活系统调用调度”。他们表明系统调用对 IPC 有负面影响。
（关于跨 SYSCALL 的分支预测的观点与我在 2013 年的想象相比，与安全性相关性更高......）

标签： performance x86 kernel system-calls

【解决方案1】：

我也很好奇，所以我编写了一些基本的裸机代码来对其进行基准测试：只是一个循环调用 syscall 1000000 次的循环，而 syscall 处理程序只运行 sysret 而没有别的。在我的 Ryzen 7 3700X 上，调用+返回平均需要 78 个周期。

显然，这是一个人为的基准测试，因为真正的系统调用处理程序可能需要执行一些操作，例如切换堆栈和执行 Spectre 缓解措施。但它给出了数量级的概念，比缓存未命中要少。

【讨论】：

确实，Spectre / Meltdown 缓解措施将 Linux 下无效系统调用的开销增加了一个数量级。（Skylake 上约 100 至约 700 个循环）-Fastest Linux system call。裸 syscall / sysret 没有 swapgs 并且加载应该更快。