eBPF 通过 Memoization 降低 90% CPU 成本
Dropping eBPF CPU Cost by About 90% with Memoization (Not AI Gen)
我和哥哥在从头设计 eBPF 安全代理时，一直追求极致速度，但最近发现 Memoization 能带来更大突破。经过性能分析，我们发现最耗时的并非策略执行，而是为每个文件打开操作重新计算适用策略。由于我们的策略基于路径，eBPF 利用 LSM hook 在文件打开时触发，需要重建路径并遍历父级 dentry，导致大量重复计算，尤其是数据库频繁访问同一文件时。为此，我们引入基于 inode 的缓存机制，将 mount namespace ID、mount ID 和 inode 号作为缓存键，存储策略位掩码索引和状态。这一改动使内核 CPU 成本下降了约 90%。在基准测试中，打开同一文件 20 万次，内核周期从 280 亿降至 30.3 亿。虽然硬链接等边缘情况需要特殊处理，但整体效果显著。现在，我们的代码已开源，欢迎在 GitHub 上查看。
我们最终发现，保护机制中最昂贵的部分并不是执行策略，而是判断哪个策略适用于当前文件打开。
HN 评论区
26- salviati
Memoization 是用内存换计算时间：你通过牺牲一些内存将 CPU 成本降低了 90%。作者只测量了其中一项，看起来并没有测量另一项。
这是一个需要纳入考量的重要细节。我确信这种优化是合理的，且额外占用的内存并不大，但我认为正如某些承重模型所说，应该“测量而非假设”。
- danudey
对这篇文章感到非常困惑。Memoization 对 eBPF 领域来说是新东西吗？作者是不是刚了解到它，就想拿来用？
实际上，这篇文章讲的是在 eBPF 和 Linux 文件系统语义的限制下，如何正确地缓存 path:policy 映射。如果你在这个背景下阅读文章，而不是纠结于“eBPF 中的 Memoization 有什么新奇有趣之处”，你会发现它有趣得多。
我可能会把标题定为“在 eBPF 中计算文件系统路径的缓存键”之类的，因为那才是被解决的那个酷炫又有趣的问题。
- Allybag
看起来这 90% 的性能提升是指每次都打开完全相同的文件，这似乎是一个不太标准的用例，也是最能从这种缓存中受益的场景。在一个从未重复打开同一文件的例子中，这预计会比之前稍慢，因为你做的是同样的事情，但还要往缓存里写数据。
所以你可以把标题写成“性能成本降低 90%！”或者“适度增加性能成本”，两者在技术上都是正确的，但我认为这两个描述都不能合理地概括这一变化。