我一直在使用 netmap 估计最近宣布的英特尔错误对我的数据包处理应用程序的影响。到目前为止，我已经测量到每个 poll() 系统调用处理大约 50 个数据包，但这个数字不包括 gettimeofday() 调用。我还测量了我每秒可以从不存在的文件描述符(这是系统调用可以做的最便宜的事情)读取 1650 万次。我的数据包处理速率是每秒176万个数据包，或者按系统调用计算，每秒03.52万个系统调用。这意味着如果系统调用惩罚加倍，性能下降将是 0.0352/16.5 = 0.21333%，这几乎不是我应该担心的。
但是，我的应用程序可能会经常使用 gettimeofday() 系统调用。我的理解是，这些不是真正的系统调用，而是作为虚拟系统调用实现的，如 What are vdso and vsyscall? 中所述。
现在，我的问题是，对最近宣布的 Intel 错误(也可能会影响 ARM 并且可能不会影响 AMD)的修复会减慢 gettimeofday() 系统调用的速度吗？或者 gettimeofday() 是一种完全不同的动物，因为它被实现为一种不同类型的虚拟系统调用？
最佳答案
一般来说，没有。
当前的补丁将诸如 vDSO 页面之类的内容映射到用户空间中，并且只会更改剩余的绝大多数内核页面的行为，这些页面将不再映射到用户空间中。
在大多数架构上，gettimeofday() 被实现为纯粹的用户空间调用，并且从不进入内核，不包括 KPTI 暗示的 TLB 刷新或 CR3 开关，因此您不应该看到性能影响。
异常(exception)情况包括不使用 vDSO 机制的异常内核或硬件配置，例如，如果您没有常量 rdtsc，或者您已通过引导参数明确禁用 rdtsc 计时。您可能已经知道是否是这种情况，因为这意味着 gettimeofday 需要 100-200ns 而不是 15-20ns，因为它已经在进行内核调用。
关于linux-kernel - 由于修复了最近宣布的英特尔错误，gettimeofday() 会变慢吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48086421/