在 Linux 中测量系统调用开销答案

【问题标题】：Measuring syscall overhead in Linux在 Linux 中测量系统调用开销
【发布时间】：2020-11-03 04:22:32
【问题描述】：

我一直在寻找一种合适的方法来衡量 Linux 操作系统中各种系统调用的成本。过去已经提出了许多与此主题相关的问题，但没有一个详细描述如何准确测量它。大多数答案武断地声称系统调用的成本是 1-2us 或几百个周期，如果它缓存在 CPU 上。

我能想到的衡量系统调用成本的简单方法是在系统调用中使用 rdtscp 指令，例如 getpid()。然而，这不足以准确测量 open()、read() 或 write() 调用的成本。我确实可以修改内核并在这些函数中插入特定的计时器代码并对其进行测量，但这需要对内核进行更改，而我不想这样做。我想知道是否有更简单的解决方案可以让我从用户空间本身来衡量它。

更新：7 月 14 日：经过大量搜索，我找到了 RedHat 的 libmicro 基准套件。 https://github.com/redhat-performance/libMicro

但是，这是不久前创建的，我想知道它现在有多好。当然，它不使用 rdtscp，这会增加一些测量误差。此基准创建中是否还缺少其他任何内容？

【问题讨论】：

您提到了两件不同的事情：1. 与函数调用相比，将操作实现为系统调用的成本（系统调用开销），以及 2. 整个系统调用的成本（例如读/写调用）。你对哪个感兴趣？
@那个人，实际上都是。在读/写系统调用方面 - 我更感兴趣的是软件开销，而不是花在读取磁盘上的时间。
经过大量搜索 - 我找到了 github.com/redhat-performance/libMicro 有什么想法吗？
请注意，Meltdown / Spectre 缓解措施相对于像getpid 这样的快速系统调用的成本会增加显着开销（如果您实际上为它调用内核而不是使用用户空间中的 VDSO）或返回 -ENOSYS 的无效 syscall。请参阅Fastest Linux system call 2018 年之前的答案需要大量盐分；往返内核的大部分成本（不在那里做任何工作）是用于清除分支预测的微代码。也导致返回用户空间后一段时间性能变慢
“相对于快速系统调用的成本增加了显着的开销”这是我有兴趣衡量的。我知道人们一直在说“重大”开销，但我自己无法衡量。我的想法是测量有无缓解措施，看看差异，找出缓解措施的成本。

标签： linux performance linux-kernel system-calls benchmarking

【解决方案1】：

strace 和perf 通常用于跟踪和测量此类（内核）操作。更具体地说，perf 可用于生成火焰图，使您能够查看详细的内核函数调用。不过要记住/proc/sys/kernel/perf_event_paranoid中需要调整适当的权限。

我建议您将系统调用放在一个循环中，因为精确测量一个系统调用的成本以及可能影响内核线程的延迟/异步工作要么很难在用户空间中测量，要么只是不准确（在非定制内核）。

其他信息：

strace 工作在微秒级。一些 POSIX 时钟（参见clock_gettime）可以达到 100 ns 的粒度。超出此限制，rdtscp 是 AFAIK 最准确的之一（应该关心参考频率）。至于perf，它利用了硬件性能计数器和内核事件。您可能需要配置内核，以便perf 可以生成和正确跟踪跟踪点。 perf 可以跟踪一个特定的进程或整个系统。

【讨论】：

谢谢！我为这个问题添加了一个额外的更新。对此有什么想法吗？
尽管必须小心避免频率缩放 - 在任何仍然相关的 CPU 上，TSC 以固定的参考频率滴答。这不一定与最大非涡轮频率相同（例如，在 4GHz i7-6700k 上为 4008 MHz，或者在某些 Ice Lake CPU 上更显着不同）。 (see this)。因此，避免空闲/涡轮增压不足以使用 TSC = 核心时钟。不过，您可能确实希望以某种方式保持核心时钟频率恒定，以进行可重复的测量。即做一个预热延迟循环，让 CPU 在计时区域之前加速。
@PeterCordes 确实如此。很好的一点！感谢您提供此信息。
@PeterCordes 同意。感谢您的信息。