如何精准剖析 eBPF 代码性能？
How Do I Profile eBPF Code?
在运行或编写 eBPF 工作负载时，量化其性能影响至关重要。本文演示了如何测量文件打开操作这一核心系统函数的性能开销。通过构建极简的 C 语言测试工具，利用 syscall 直接调用并排除缓存干扰，我们对比了开启 eBPF hook 前后的 p50/p99 延迟数据。配合 perf 工具开启 JIT 符号解析，我们能清晰定位到 bpf_lsm_file_open 等关键路径上的性能瓶颈。这种方法不仅能识别热点，还能指导具体的代码优化，如算法改进或缓存策略调整，从而在热路径上显著降低系统开销。
这证明该路径处于热点区域，意味着每一次从内存分配到 CPU 周期的削减，都将对系统性能产生显著影响。
- okzgn
这里有一些补充资源/论文：
1. eBPF LSM Hooks 的性能：https://dl.acm.org/doi/10.1145/3672197.3673431（分析了 LSM/追踪钩子给内核引入的开销）。
2. eBPF Maps 的性能：https://dl.acm.org/doi/10.1145/3672197.3673430（对于 perf 报告中显示的 htab_map_hash 瓶颈很有参考价值）。
3. 网络 eBPF 性能：https://blog.apnic.net/2026/03/25/demystifying-performance-o...（关于 eBPF 开销的更广泛背景，非常棒）。
- tanelpoder
上个月我写了一个叫 "brr" 的工具——eBPF 运行时报告器和性能分析器。它展示了一个类似 bpftop 的 eBPF 程序摘要，但你还可以深入查看任意程序，看到其源代码行（如果有的话），并对 eBPF 程序的活动以及该 eBPF 程序调用或引发的任何内核代码活动进行分析，从而全面了解你的 eBPF 程序的时间和延迟都花在了哪里。
我主要是用 Codex 为自己写的，但刚刚把最新版本推到了 GitHub（附带截图），以防万一有人感兴趣：
- jeffbee
除了 CPU 周期，我建议还要收集 TLB 缺失率。eBPF 不是魔法，任何规模较大的 map 都可能污染你的虚拟地址转换缓存。上次有人让我在工作中分析 eBPF 性能时，超过 90% 的周期时间都归因于页表遍历，这对应用程序也造成了严重的连带影响。