`diff-back` contesta «¿el .config honra el PLAN?»; el contrato contesta la otra
mitad, «¿el kernel trae lo que el userland usa por nombre?». Son distintas: un
kernel puede honrar su plan al pie de la letra y no tener MEMCG, que nunca
estuvo en ningún plan porque nadie lo pidió.
Queda dicho también que hoy sale ROJO a propósito (2 de 11) y por qué.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
- §0 y §4.bis: el «sin MEMCG» deja de ser deducción del defconfig. Los ONCE
.config sellados traen `# CONFIG_MEMCG is not set` y `# CONFIG_PSI is not
set`, y ninguno tiene CFS_BANDWIDTH (⇒ tampoco existe `cpu.max`; hoy nadie
lo pide). Y se nombra por qué sobrevivió: el kernel de la máquina de
desarrollo SÍ los trae — el fallo sólo existe del lado del artefacto.
- §4.ter: el guardián `hammer kernel contract`, con las tres decisiones de
diseño (por perfil, contra el .config y no la receta, apagado ≠ ausente).
- §3: de tres sorpresas a cinco (taskstats no es más rápido que /proc; el
sondeo es ciego, no lento).
- §9: reescrita. Cuatro de los seis experimentos nombrados quedaron medidos
con root; siguen abiertos el iterador BPF (detrás de H7) y el Intel con PTI.
- §5, §7 y §10: filas medidas, H1 marcado como pendiente-pero-vigilado,
H8 (el contrato es parte del release) y H9 (reflink alimenta SDD 18).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
SDD 25 §9 listó seis experimentos que no se pudieron correr y por qué. Cuatro
de ellos sólo pedían privilegios, y esta sesión los tuvo. Programas y salidas
crudas en docs/evidencia/tasas-kernel-2026-08-29/.
1. proc connector (bench_connector.c) — el sondeo de /proc no es lento, es
CIEGO: 200 procesos de vida mínima lanzados uno cada 10 ms, sondeando cada
100 ms se ven **0 de 200**; por connector, **200 de 200**. Y esperar el
evento no cuesta nada frente a waitpid (116,0 vs 114,8 µs, dentro del ruido),
con 0 eventos perdidos en 1400.
Sorpresa: taskstats por genetlink **no es más rápido** que parsear
/proc/self/stat (2 688 vs 2 697 ns). Su valor es el CONTENIDO (delay
accounting), no la velocidad.
2. reflink (bench_reflink.c) — el «copiar en O(1)» existe y NO está en ext4:
FICLONE no soportado, y copy_file_range ≈ read+write (13,7 vs 14,5 ms).
En xfs y btrfs es PLANO: 64 MiB en 0,010 ms y 512 MiB —ocho veces más— en
0,020 ms, contra 512,7 ms de read+write. **25 600× a 512 MiB.**
3. io_uring SQPOLL (bench_sqpoll.c) — no rescata el veredicto de T12: sobre
datos cacheados pierde igual. ext4: pread 554 ns < io_uring 618 < SQPOLL 868.
tmpfs: pread 749 < SQPOLL 1 409 < io_uring 2 030 (ahí sí mejora al io_uring
normal, 1,4×, pero sigue perdiendo contra la syscall). Y se come un core.
4. syscalls por invocación de compilador — con el strace DEL PROPIO CORPUS
(store/3c1fd8c0…-strace), que es la respuesta a «no hay strace en esta
máquina». gcc: 1 803 syscalls por un `-c` trivial, **1 095 con error (61%),
919 de ellas readlink** — la canonicalización de rutas, que T8 no medía.
Pero al piso de 78,7 ns son 0,14 ms sobre 30,5 ms de compilado: **el cruce
al kernel es el 0,5%**. La tormenta de rutas vale milisegundos, no minutos.
Condiciones distintas a la corrida original (load ~1,3 sobre 4 vCPU contra 7,3)
⇒ los absolutos NO se comparan entre corridas, sólo los cocientes dentro de una.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
SDD 25 §4 dejó el hallazgo escrito y sin guardián: los kernels de hammer se
construyen sin CONFIG_MEMCG, `memory.max` no existe, y arje descarta el error
al escribirlo ⇒ una Card pide un tope de memoria, corre SIN tope, y la única
huella es un `warn!`. Nadie lo veía porque la máquina de desarrollo SÍ trae
MEMCG: el fallo sólo existe del lado del artefacto sellado.
`hammer kernel contract` declara qué pedazos de interfaz de kernel usa el
userland POR NOMBRE (con consumidor, fichero y CÓMO FALLA HOY si no está) y los
comprueba contra un `.config` YA PRODUCIDO — no contra la receta: entre el
`scripts/config -e X` y el `.config` hay un `olddefconfig` que puede tragarse el
símbolo en silencio.
Por perfil, no global — misma lección que el gate de hardware: `linux.toml` es
el kernel de QEMU del selfhost-verify, no hospeda Cards, y su hash es
load-bearing del baseline `of_tree`. Exigirle contabilidad de memoria sería
rechazar una receta sana.
Medido sobre el store: **2 de 11 configs sellados cumplen su perfil**; los 9
`anfitrion-cards` fallan por MEMCG (apagado A MANO: `# CONFIG_MEMCG is not
set`) y les falta PSI. El kernel vivo de esta máquina pasa las 11 exigidas —
que es exactamente por qué el bug sobrevivió.
Distingue apagado explícito de ausente (un símbolo que el .config ni nombra
puede ser un renombrado entre versiones), y un kernel sin perfil declarado
queda SIN COMPROBAR en vez de contar como aprobado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
16 tasas de Linux medidas en momento (KVM, 4 vCPU, bajo carga): piso de
syscall, /proc como API de texto, fork vs espacio de direcciones del padre,
enlazado dinámico, VFS, io_uring, THP, namespaces. Programas en C y salidas
crudas en docs/evidencia/tasas-kernel-2026-08-29/.
Lo que sale de medir y después verificar contra las recetas: los kernels de
hammer se construyen sin CONFIG_MEMCG (no está en x86_64_defconfig y no tiene
default y), y arje/sandokan escriben memory.max descartando el error. Un tope
de memoria pedido por una Card no se aplica y sólo deja un warn.
Tres resultados que contradicen el consejo de manual y quedan documentados:
THP 3x más lento que 4K con defrag=madvise, io_uring 2,8x más lento que pread
sobre tmpfs, y stat cuesta lo mismo en tmpfs que en ext4 (es tasa del VFS).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Sergio