Como fazer profiling de código eBPF: um guia prático

O eBPF virou peça central em observabilidade, segurança e performance no Linux, e com a adoção crescente também no Brasil surge uma pergunta prática: como medir o custo real de um programa eBPF que você anexou ao kernel? Um post do desenvolvedor Naveen Srinivasan detalha um método reproduzível para responder isso, usando como exemplo a medição do overhead de um hook em operações de abertura de arquivo (file open).

O harness de medição em C

O ponto de partida é um programa em C enxuto, com o mínimo de dependências, cujo objetivo é medir o tempo de abertura de arquivo de forma controlada. Segundo o autor, algumas escolhas de design reduzem ruído nas medições:

• O código chama diretamente syscall(SYS_openat, ...) em vez do wrapper openat() da libc, para eliminar camadas intermediárias.
• Usa clock_gettime(CLOCK_MONOTONIC, ...), que roda via VDSO e não gera syscall.
• Faz pré-alocação, prefault e mlock da memória antes do loop, evitando page faults durante a medição.
• Reabre sempre o mesmo arquivo em condições de cache quente, minimizando variabilidade de disco e filesystem.
• Descarta os primeiros 10% das amostras como período de aquecimento (warmup).

O resultado é uma lista de tempos de abertura que permite calcular p50 e p99, comparando o cenário antes e depois de anexar o hook eBPF.

Preparando o ambiente para o perf

Para que o perf consiga resolver os símbolos dos programas BPF (em vez de mostrar endereços desconhecidos), o autor habilita a exposição dos símbolos JIT:

sudo sysctl -w net.core.bpf_jit_enable=1
sudo sysctl -w net.core.bpf_jit_kallsyms=1

Em seguida, é possível verificar se os símbolos aparecem consultando bpftool prog show e o /proc/kallsyms. No exemplo, como a medição é de hooks LSM, o autor filtra por termos como security, path, file e open. Vale notar um detalhe comum em ambientes reais: como o post usa um kernel customizado, o perf não está no path padrão, sendo referenciado por uma variável (PERF=/usr/lib/linux-tools/6.8.0-134-generic/perf).

Medindo com e sem o hook

O primeiro passo é a linha de base: rodar o benchmark sem o código eBPF ativo. Para reduzir ruído de escalonamento, o autor combina dois utilitários:

sudo taskset -c 3 chrt -f 99 ./bench /etc/hostname 100000 > /tmp/samples.txt

O taskset -c 3 fixa a execução na CPU 3, reduzindo migração entre núcleos, e o chrt -f 99 dá prioridade de CPU altíssima ao benchmark. Com o hook ativo, entra o perf record:

sudo $PERF record -g --call-graph fp -e cycles:k -F 997 -o ~/perf.data -- \
  taskset -c 3 chrt -f 99 ./bench /etc/hostname 200000 > /tmp/samples.txt

O autor explica cada flag: -g grava as call stacks, --call-graph fp desenrola as pilhas via frame pointers, -e cycles:k amostra ciclos de CPU apenas em modo kernel (o que inclui syscall, VFS, LSM e execução eBPF, mas não o trabalho do benchmark em userspace) e -F 997 pede 997 amostras por segundo, com frequência não redonda de propósito para evitar alinhamento periódico.

Lendo o resultado

Os dados são ordenados com perf report --sort comm,dso,symbol e podem ser transformados em flamegraph (o post usa a ferramenta Inferno). No exemplo, a árvore de chamadas mostra que a maior parte do tempo se concentra em bpf_lsm_file_open e suas tail calls, descendo por funções como enforce_access_policy, path_check_callback e chegando a bpf_probe_read_kernel, que sozinha respondia por cerca de 30% do caminho quente.

O autor deixa claro que o foco do post é o método, não os números absolutos: o overhead depende inteiramente do que o seu hook faz, então a ideia é ensinar como obter as próprias medições. Com o caminho quente identificado, as otimizações podem ser tão simples quanto cachear um valor ou trocar por um algoritmo melhor.

Por que isso importa para quem constrói infra no Brasil

Para times brasileiros que adotam eBPF em observabilidade, redes e segurança (via ferramentas como Cilium, Falco ou soluções próprias), a mensagem prática é que anexar um hook ao kernel nunca é de graça, e o custo precisa ser medido em hot paths. O roteiro descrito, harness controlado em C, perf com símbolos JIT resolvidos e flamegraph, é diretamente reproduzível em qualquer ambiente Linux e ajuda a transformar suposições de performance em dados de p50/p99.

Fonte: Hacker News