gettimeofday() 是否会因修复最近宣布的 Intel 错误而变慢？
Will gettimeofday() be slowed due to the fix to the recently announced Intel bug?
我一直在使用 netmap 估计最近宣布的 Intel 错误对我的数据包处理应用程序的影响。到目前为止，我测得每个 poll() 系统调用处理大约 50 个数据包，但这个数字不包括 gettimeofday() 调用。我还测量到我每秒可以从一个不存在的文件描述符中读取 1650 万次（这是系统调用可以做的最便宜的事情）。我的数据包处理速率是每秒 176 万个数据包，或者以系统调用计算，每秒 0.352 万个系统调用。这意味着如果系统调用惩罚加倍，性能降低将是 0.0352 / 16.5 = 0.21333%，这几乎不是我应该担心的事情。
但是，我的应用程序可能会经常使用 gettimeofday() 系统调用。我的理解是，这些不是真正的系统调用，而是作为虚拟系统调用实现的，如 What are vdso and vsyscall?.
中所述
现在，我的问题是，对最近宣布的 Intel 错误（可能也会影响 ARM，但可能不会影响 AMD）的修复是否会减慢 gettimeofday() 系统调用？还是 gettimeofday() 由于被实现为不同类型的虚拟系统调用而成为完全不同的动物？
好问题，VDSO 页面 是 内核内存映射到用户 space。如果您单步进入 gettimeofday()，您会在 VDSO 页面中看到一个 call，其中一些代码使用 rdtsc 并使用从另一个数据页面读取的缩放因子缩放结果。
但是这些页面应该可以从用户-space读取，所以Linux可以毫无风险地保持它们的映射。 Meltdown 漏洞是 page-table / TLB 条目中的 U/S 位 (user/supervisor) 不会阻止非特权加载（以及进一步的相关指令）在微体系结构上发生，从而产生变化然后可以使用缓存定时读取的微体系结构状态。
一般不会。
当前的补丁保留了映射到用户 space 中的 vDSO 页面之类的内容，并且仅更改了其余绝大多数仅内核页面的行为，这些页面将不再映射到用户 space.
在大多数体系结构中，gettimeofday() 实现为纯用户space 调用，从不进入内核，不包括 KPTI 暗示的 TLB 刷新或 CR3 开关，因此您应该'看到性能影响。
例外情况包括不使用 vDSO 机制的异常内核或硬件配置，例如，如果您没有常量 rdtsc 或者如果您通过引导参数。您可能已经知道情况是否如此，因为这意味着 gettimeofday 将花费 100-200ns 而不是 15-20ns，因为它已经在进行内核调用。
我一直在使用 netmap 估计最近宣布的 Intel 错误对我的数据包处理应用程序的影响。到目前为止，我测得每个 poll() 系统调用处理大约 50 个数据包，但这个数字不包括 gettimeofday() 调用。我还测量到我每秒可以从一个不存在的文件描述符中读取 1650 万次（这是系统调用可以做的最便宜的事情）。我的数据包处理速率是每秒 176 万个数据包，或者以系统调用计算，每秒 0.352 万个系统调用。这意味着如果系统调用惩罚加倍，性能降低将是 0.0352 / 16.5 = 0.21333%，这几乎不是我应该担心的事情。
但是，我的应用程序可能会经常使用 gettimeofday() 系统调用。我的理解是，这些不是真正的系统调用，而是作为虚拟系统调用实现的，如 What are vdso and vsyscall?.
现在，我的问题是，对最近宣布的 Intel 错误（可能也会影响 ARM，但可能不会影响 AMD）的修复是否会减慢 gettimeofday() 系统调用？还是 gettimeofday() 由于被实现为不同类型的虚拟系统调用而成为完全不同的动物？
好问题，VDSO 页面 是 内核内存映射到用户 space。如果您单步进入 gettimeofday()，您会在 VDSO 页面中看到一个 call，其中一些代码使用 rdtsc 并使用从另一个数据页面读取的缩放因子缩放结果。
但是这些页面应该可以从用户-space读取，所以Linux可以毫无风险地保持它们的映射。 Meltdown 漏洞是 page-table / TLB 条目中的 U/S 位 (user/supervisor) 不会阻止非特权加载（以及进一步的相关指令）在微体系结构上发生，从而产生变化然后可以使用缓存定时读取的微体系结构状态。
一般不会。
当前的补丁保留了映射到用户 space 中的 vDSO 页面之类的内容，并且仅更改了其余绝大多数仅内核页面的行为，这些页面将不再映射到用户 space.
在大多数体系结构中，gettimeofday() 实现为纯用户space 调用，从不进入内核，不包括 KPTI 暗示的 TLB 刷新或 CR3 开关，因此您应该'看到性能影响。
例外情况包括不使用 vDSO 机制的异常内核或硬件配置，例如，如果您没有常量 rdtsc 或者如果您通过引导参数。您可能已经知道情况是否如此，因为这意味着 gettimeofday 将花费 100-200ns 而不是 15-20ns，因为它已经在进行内核调用。