HN Debrief

How Do I Profile eBPF Code?

  • Infrastructure
  • Performance
  • Open Source
  • Developer Tools

The post is a hands-on guide to profiling eBPF code. It focuses on the awkward part of eBPF performance work: your program runs inside the kernel, calls helpers, touches maps, and can spend time in surrounding kernel paths that a naive profile will hide. The article shows how to use Linux profiling tools to break that apart and identify where cycles are really going.

If you run eBPF in production, profile it like any other systems code instead of assuming the verifier or JIT makes it cheap. In practice that means measuring map access patterns, translation-cache pressure, and kernel work triggered by the program, not just staring at aggregate CPU time.

Discussion mood

Positive and practical. People treated the post as a useful starting point, then immediately pushed toward deeper measurement of map overhead, memory effects, and better tooling.

Key insights

  1. 01

    TLB misses can dominate eBPF cost

    Large eBPF maps can blow out the Translation Lookaside Buffer and turn map access into page table walks. One commenter said a real workload spent over 90 percent of cycles there, with spillover slowdown for the applications sharing the machine. That is a much nastier failure mode than just a few extra helper calls.

    When an eBPF profile looks inexplicably expensive, add Translation Lookaside Buffer miss and page-walk counters to the run. If maps are the culprit, change map size, layout, or access locality before tuning instruction-level code.

      Attribution:
    • jeffbee #1
  2. 02

    A profiler that follows kernel work too

    The "brr" tool goes past a bpftop-style summary and tries to show source lines alongside time spent in both the eBPF program and the kernel code it causes to run. That framing matches the real profiling problem here, because eBPF often shifts cost into adjacent kernel paths that generic per-process views miss.

    If your current tooling stops at per-program counters, look for a profiler that attributes downstream kernel time as well. That is the difference between proving your BPF instructions are cheap and proving the whole feature is cheap.

      Attribution:
    • tanelpoder #1
  3. 03

    Recent papers quantify the common bottlenecks

    The linked papers put hard numbers on overhead from BPF LSM hooks and BPF map operations, and the APNIC writeup extends that to network workloads. Together they give you a better baseline for what costs are structural to the mechanism versus specific to your implementation choices.

    Use published measurements as a sanity check before spending weeks on local tuning. If your bottleneck matches known map or hook costs, redesigning where and how you attach BPF may beat low-level optimization.

      Attribution:
    • okzgn #1

In plain english

bpftop ↩
A top-like monitoring view for eBPF activity that summarizes running BPF programs and their resource usage.
eBPF ↩
extended Berkeley Packet Filter, a Linux technology for running sandboxed programs inside the kernel for networking, observability, security, and other low-level tasks.
helper ↩
A kernel-provided function that an eBPF program can call to perform operations it cannot do directly.
kernel ↩
The core part of the operating system that manages hardware, memory, and low-level system services.
LSM ↩
Linux Security Module, a kernel framework for hooking security checks so security policies or programs can inspect operations.
map ↩
An eBPF data structure used to store and share state, often acting like a key-value store between BPF programs and user space.

Reference links

Research papers

Tools

Background articles