Here are some complementary resources/papers:

1. Performance of eBPF LSM Hooks: https://dl.acm.org/doi/10.1145/3672197.3673431 (Analyzes the overhead introduced by LSM/tracing hooks on the kernel).

2. Performance of eBPF Maps: https://dl.acm.org/doi/10.1145/3672197.3673430 (Useful context for the htab_map_hash bottleneck shown in the perf report).

3. Network eBPF performance: https://blog.apnic.net/2026/03/25/demystifying-performance-o... (Great broader context on eBPF overhead).

• snaveen

  today at 5:14 PM

  Thank you for these references! I wasn't aware of these papers.

• tanelpoder

  today at 5:59 PM

  [dead]

Last month I wrote a tool called "brr" - eBPF Runtime Reporter and Profiler. It displays a bpftop-like eBPF program summary, but you can also zoom into any program to see its source code lines (if available) and profile the eBPF program activity and any kernel code activity called/caused by the eBPF program for the full picture of where your eBPF program time/latency is spent.

I wrote it mostly with Codex for my own use, but just pushed the latest release to GitHub (with screenshots) in case anyone else is interested:

https://github.com/tanelpoder/brr

In addition to cycles, I suggest gathering TLB miss rates. eBPF isn't magical and any maps of significant size may pollute your virtual address translation caches. The last time someone asked me to profile eBPF at work, over 90% of the cycle time was attributable to page table walks, and this also had severe collateral impact on the applications.

• snaveen

  today at 5:43 PM

  Thank you for the additional insights.

Lob and Mob.

[flagged]