SDD 25 §7-H7 — Qué cuesta encender DEBUG_INFO_BTF, medido construyendo
Medido 2026-08-31 en 'momento'. NO se cruza con los números de §2, §9 ni §9.5:
esto no es un microbenchmark, es un kernel construido.

== qué se compara ==
El MISMO kernel por los dos caminos, con UNA sola diferencia en el .config:
  A) linux-generic VIGENTE, sellado          — DEBUG_INFO_NONE, sin BTF
  B) linux-generic-btf, receta derivada       — DEBUG_INFO_DWARF5 + DEBUG_INFO_BTF
Todo lo demás (defconfig 7.1.2, la lista entera de -e/-d, el sledgehammer de amdgpu,
CC=gcc, el CMDLINE) es byte a byte el mismo texto.

POR QUÉ SOBRE linux-generic Y NO SOBRE linux, que es más barato de construir:
BTF tiene 'depends on BPF_SYSCALL' y el .config sellado de linux lo trae APAGADO
(# CONFIG_BPF_SYSCALL is not set). Medir ahí obligaría a encender BPF_SYSCALL a la
vez y el delta mezclaría dos cosas. linux-generic ya lo trae ⇒ el delta es limpio.

La receta derivada vive en work/medicion-btf/ —FUERA de recipes/— para no entrar al
grafo compartido como deuda; el catálogo se le presta por symlinks en su directorio.
Nada del corpus se re-hashea por esta medición.

== condiciones ==
máquina             : momento, 4 vCPU, 7 GiB RAM
load al arrancar    : 3.42 2.64 2.38
memoria disponible  : 4293 MiB
disco libre (store) : 78G
paralelismo         : -j2 (no $(nproc)): con -g cada gcc pesa más y hay ~4 G libres.
                      NO afecta a los bytes del bzImage, que es lo único que se mide.
ruido conocido      : el mismo 'yes' huérfano (pid 1750, reparentado a arje-zero) sigue
                      quemando un core de los 4. Encarece el TIEMPO, no los BYTES.
pahole              : v1.30, estático (el arreglo del 2026-08-31)

== baseline A ==
bzImage sellado : 16937984 bytes
                  (es el mismo número que cita §7-H1 tras pagar MEMCG+PSI)

== B: construido con DWARF5 + BTF ==
receta derivada     : work/medicion-btf/linux-generic-btf.toml (hash b3:771e4823…)
duración del build  : 20:02:49 → 20:51:09 UTC = 48 min con -j2
deps que hubo que añadir a las del kernel sellado: dwarves, python3

guarda del .config (CLAUDE.md §3, y por qué hace falta):
  scripts/pahole-version.sh imprime 0 si pahole no está en el PATH;
  'depends on PAHOLE_VERSION >= 122' deja de cumplirse y olddefconfig BORRA la
  línea EN SILENCIO. El build saldría OK sellando un kernel SIN BTF. Por eso la
  fase configure verifica el .config PRODUCIDO y sale 1 si no está. Salida real:
    v1.30
    OK: CONFIG_DEBUG_INFO_BTF=y en el .config producido

== lo medido ==
vmlinux 588319992 bytes
bzImage 19473408 bytes
  [10] .BTF              PROGBITS        ffffffff830e0000 22e0000 785d26 00   A  0   0  1
  [11] .BTF_ids          PROGBITS        ffffffff83866000 2a66000 000928 00   A  0   0  1
  [39] .debug_info       PROGBITS        0000000000000000 330f240 18c33a9d 00      0   0  1
.BTF 7888166 bytes

bzImage sin BTF  :   16.937.984 bytes
bzImage con BTF  :   19.473.408 bytes
DELTA            :   +2.535.424 bytes = +2.42 MiB = +14.97%

seccion .BTF en vmlinux (sin comprimir): 7.888.166 bytes = 7.52 MiB
seccion .BTF_ids                       : 2.344 bytes
⇒ los 7.52 MiB de .BTF se comprimen a 2.42 MiB dentro del bzImage (3.11x)

== contra el precio de H1, que es la unica vara comparable que tenemos ==
  MEMCG+PSI  : +80 KiB   = +0,49%  del mismo bzImage
  BTF        : +2,42 MiB = +14,97% del mismo bzImage
  ⇒ BTF cuesta 31x lo que costo H1 en bytes.

== el numero de Artix NO servia, y en la direccion CONTRARIA a la esperable ==
El BTF del kernel de Artix son 6,4 MB y §9.5 dijo que no decia nada de un kernel
monolitico y pelado. Correcto — pero el nuestro sale MAS GRANDE: 7,5 MiB. Artix es
MODULAR, y su .BTF de vmlinux cubre solo el core built-in; el nuestro es monolitico
(i915 + nouveau + radeon + iwlwifi + todo el resto son =y) y sus tipos entran todos.
Un kernel mas chico en drivers cargables tiene MAS BTF que uno grande en modulos.

== lo que costo construirlo, que no es lo que se paga al arrancar ==
vmlinux con DWARF   : 588.319.992 bytes (561 MiB), de los cuales .debug_info
                      son 415.447.709 bytes (396 MiB).
Eso NO entra en la imagen: la receta empaqueta bzImage, no vmlinux. Es coste de
build (tiempo, RAM de pahole y disco), no de arranque.

== como se reproduce ==
La receta derivada esta guardada al lado: docs/evidencia/.../linux-generic-btf.toml.
'hammer build' no tiene --base-dir (solo el fallback al catalogo PADRE), asi que para
construirla fuera de recipes/ hay que prestarle el catalogo por symlinks:
    M=work/medicion-btf; mkdir -p $M
    for f in $PWD/recipes/*.toml; do ln -s "$f" "$M/$(basename $f)"; done
    cp docs/evidencia/tasas-kernel-2026-08-29/linux-generic-btf.toml $M/
    flock work/.farm-build.lock ./target/release/hammer --store ./store build $M/linux-generic-btf.toml

EL ARTEFACTO SE BORRO A PROPOSITO tras anotar estos numeros. No es basura olvidada:
'hammer kernel contract --sealed' lo encontraba y lo listaba como SIN COMPROBAR
(no declara [[target]], que es justo lo que H8 exige), o sea un ⚠ permanente en
docs/state/kernel-contract.txt, que el cron commitea cada 30 min. Un aviso fijo que
no corresponde a ningun problema es como se deja de leer un vigia.