How to Profile eBPF Code and Measure Performance Overhead
How Do I Profile eBPF Code?
I demonstrate a practical method for measuring the performance impact of eBPF workloads using a custom C test harness and the perf tool. By pinning execution to a specific CPU and analyzing kernel cycles, we can isolate bottlenecks in file open operations. This approach allows us to pinpoint exactly where optimizations are needed in the eBPF code path.
This turned out to be in a hot path, which meant every allocation-to-CPU cycle shaving will make a significant impact on the performance of the system.
- okzgn
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).
- tanelpoder
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:
- jeffbee
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.