LWN：各种BPF实现的性能对比！

关注了就能看到更多这么棒的文章哦～

Comparing BPF performance between implementations

By Daroc Alden
June 5, 2024
LSFMM+BPF
Gemini-1.5-flash translation
https://lwn.net/Articles/976317/

Alan Jowett 在 2024 年的 Linux 存储、文件系统、内存管理和 BPF 峰会 上进行了第二场远程演讲，在其中比较了不同 BPF 运行时的性能。他展示了 MIT 许可的 BPF 微基准测试套件 的结果，他一直在开发这个套件。该基准测试套件尚未提供所有平台之间良好的直接比较，因此结果应该谨慎对待。它们似乎表明，不同实现之间存在一些显著差异，尤其是对于不同类型的 BPF 映射（maps）。

这些基准测试测量了一些不同的指标，包括实际执行各种测试程序所花费的时间，以及从内核切换到 BPF 虚拟机的开销，以及调用辅助函数的性能。Jowett 说，以平台中立、可重复的方式测量这些指标非常重要。该基准测试套件使用 libbpf 加载 BPF 程序，libbpf 使用“编译一次，随处运行”（CO-RE）在不同的支持平台上运行相同的 ELF 文件。

基准测试套件中包含了几种不同类型的 BPF 程序，包括一个空（无操作）程序、一些执行各种辅助函数的程序，以及测试 BPF 映射性能的程序，包括 trie 和哈希表映射。在多个 CPU 内核上并行进行测量，以使测试并发映射的性能更有意义。

eBPF for Windows 项目使用基准测试套件作为其日常持续集成 (CI) 设置的一部分，以跟踪性能回归。CI 还在 Linux 上运行相同的测试，但他表示，由于基础设施问题，这些测试不能很好地进行比较——CI 使用的 GitHub 运行程序无法指定特定的 Linux 内核版本。他还指出，由于 Windows 使用 BPF 的提前编译 (AOT)，而不是像 Linux 那样使用即时编译 (JIT)，因此会存在一些差异。

尽管如此，Jowett 认为，从这些基准测试中可以吸取一些有价值的经验教训。他说，AOT 编译的性能优于 JIT 编译，JIT 编译的性能又优于解释执行。Alexei Starovoitov 对此说法提出了质疑；他说，在 Windows 上测试的 JIT（鉴于 Linux 基础设施问题，这是 Jowett 进行比较的依据）相当笨拙，不足以对 Linux 的 JIT 做出概括。Jowett 承认了这一点，并指出了 Windows JIT 无法改进的一些方法。

Jowett 还展示了一些测量结果，证明最长前缀匹配 trie 映射的更新速度比哈希表更快，并且 Windows 在匹配 Linux 的 最近最少使用 (LRU) 表 的性能方面遇到了困难。他指出，维护表中键的年龄的全局一致性“代价高昂”。

然而，由于 Jowett 在测量 Linux 性能方面遇到的困难，因此很难说 eBPF for Windows 和 Linux BPF 实现的比较情况如何。也许当这个问题得到解决时，这项工作将成为一个有用的工具，可以突出潜在的性能改进。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～