Perfilar código eBPF es clave para cuantificar la sobrecarga que introduce un hook en el kernel antes de llevarlo a producción. Este artículo describe una metodología reproducible para medir y diagnosticar ese impacto, usando como caso de estudio un hook LSM de file_open.
El método combina tres piezas. Primero, un arnés de pruebas en C que llama directamente a la syscall SYS_openat sobre /etc/hostname en caché caliente, descarta el 10% inicial como warmup, fija la ejecución a una CPU con taskset y la eleva a prioridad real-time con chrt -f 99; con él se obtienen 90.000 muestras válidas para calcular latencias p50 y p99 sin eBPF cargado. Segundo, una configuración del kernel que activa el JIT y expone los símbolos BPF compilados al tool perf, de modo que perf report muestre nombres de programas en lugar de direcciones hexadecimales; en el ejemplo se usa un kernel 6.8.0-134 compilado a medida, con perf en una ruta no estándar. Tercero, una captura con perf record -g --call-graph fp -e cycles:k -F 997 que registra solo ciclos en modo kernel (syscall, VFS, LSM y eBPF), a una frecuencia no redonda para evitar aliasing con otros temporizadores.
A partir del perf.data se genera un flamegraph con Inferno para localizar visualmente la pila bpf_lsm_file_open y sus tail calls, que es donde se concentra el cuello de botella. El artículo insiste en que la metodología, no los números, es lo importante: la sobrecarga real depende de lo que haga el hook, por lo que el lector debe repetir el experimento en su propio entorno para extraer conclusiones accionables, desde caching interno hasta rediseño algorítmico.