我一直在估计最近公布的英特尔错误对我使用netmap的数据包处理应用程序的影响。到目前为止，我测量到每个poll()系统调用处理大约 50 个数据包，但这个数字不包括gettimeofday()调用。我还测量到每秒可以读取 1650 万次不存在的文件描述符（这是系统调用可以做的最便宜的事情）。我的数据包处理速率是每秒 176 万个数据包，或者就系统调用而言，每秒 03.52 万个系统调用。这意味着如果系统调用惩罚加倍，性能下降将是 0.0352 / 16.5 = 0.21333%，这几乎不是我应该担心的。
但是，我的应用程序可能会gettimeofday()经常使用系统调用。我的理解是，这些不是真正的系统调用，而是作为虚拟系统调用实现的，如什么是 vdso 和 vsyscall？.
现在，我的问题是，对最近宣布的 Intel 错误（也可能会影响 ARM，可能不会影响 AMD）的修复是否会减慢gettimeofday()系统调用速度？还是gettimeofday()因为被实现为不同类型的虚拟系统调用而导致完全不同的动物？
一般来说，没有。
当前的补丁保留了用户空间中映射的 vDSO 页面之类的内容，并且仅更改了剩余的绝大多数内核页面的行为，这些页面将不再映射到用户空间中。
在大多数架构上，gettimeofday()它是作为纯用户空间调用实现的，并且永远不会进入内核，不包括 KPTI 所暗示的 TLB 刷新或 CR3 开关，因此您不应该看到性能影响。
例外情况包括不使用 vDSO 机制的不寻常的内核或硬件配置，例如，如果您没有常量rdtsc或者您rdtsc通过引导参数明确禁用计时。您可能已经知道是否是这种情况，因为这意味着gettimeofday需要 100-200ns 而不是 15-20ns，因为它已经在进行内核调用。
好问题，VDSO 页面是映射到用户空间的内核内存。如果您单步进入gettimeofday()，您会看到callVDSO 页面，其中一些代码使用rdtsc并使用从另一个数据页面读取的比例因子缩放结果。
但是这些页面应该可以从用户空间读取，因此 Linux 可以毫无风险地保持它们的映射。Meltdown 漏洞是页表/TLB 条目中的 U/S 位（用户/主管）不会阻止非特权加载（以及进一步的相关指令）在微架构上发生，从而导致微架构状态发生变化，然后可以读取与缓存计时。