1# SDD 25 — Las tasas del kernel: qué cobra Linux, cuánto, y por dónde se esquiva
2
3Escrito 2026-08-29. Nace de una pregunta del operador: *«¿hay cómo crear módulos para
4kernel para optimizar cosas que son estándares y por eso no se cambian — por ejemplo una API
5más cercana del control de procesos sin que sandokan use `/proc`? Con tawasuyu ponerse de
6acuerdo para pasar por debajo de mecanismos pesados POSIX.»*
7
8`/proc` y sandokan eran el ejemplo, no el alcance. Lo que sigue es **la lista entera de tasas
9que Linux cobra por compatibilidad histórica, medida en esta máquina**, y para cada una: si
10se esquiva, con qué, y quién paga hoy.
11
12El espejo de este documento para el lado tawasuyu es
13`tawasuyu/HANDOFF-TASAS-KERNEL-DESDE-HAMMER.md` (mismo patrón que ADR 0010 ↔
14`HANDOFF-arranque-grafo.md`).
15
16## 0. La respuesta corta
17
181. **Un módulo cargable no es una opción en hammer y no hace falta.** Las tres recetas de
19   kernel (`linux-generic.toml:43`, `linux-metal.toml:104`, `linux-metal-dual.toml:51`)
20   configuran `-d MODULES`: kernel monolítico. `linux.toml` no lo apaga pero sólo compila
21   `bzImage`, nunca `make modules`. Cualquier código de kernel propio en hammer es
22   **built-in**, o sea un parche a la receta — que además es lo correcto para el proyecto,
23   porque la fase `configure` **es** la identidad del artefacto (SDD 22) y así queda sellado
24   y atestado junto al kernel.
252. **Casi todo lo que duele ya tiene salida en mainline y nadie la está usando.** `pidfd`,
26   `cgroup` v2 agregado, `posix_spawn`, `getdents64`, `close_range`, `openat2`. Cero código
27   de kernel, ganancias de 3× a 17× medidas abajo.
283. **La medición encontró un bug cruzado que no se buscaba**: los kernels de hammer se
29   construían **sin `CONFIG_MEMCG`**, y arje/sandokan escriben `memory.max` ignorando el
30   error. Un límite de memoria pedido por una Card **no se aplicaba y nadie se enteraba**. §4.
31   Confirmado sobre los **11 `.config` sellados**, no deducido del defconfig (§4.bis), vigilado
32   por `hammer kernel contract` (§4.ter) y **PAGADO el 2026-08-30**: los cuatro kernels que
33   hospedan Cards se reconstruyeron con `MEMCG` y `PSI` y el barrido sale **5 de 5 vigentes en
34   verde** (§7-H1).
354. **Sondear `/proc` no es lento, es ciego** (§9.1): de 200 procesos de vida mínima, un sondeo
36   cada 100 ms vio **cero**; el proc connector, los 200. Y **el «copiar en O(1)» existe pero no en
37   ext4**: en xfs/btrfs un reflink de 512 MiB tarda 0,020 ms contra 512,7 ms de `read+write`
38   (§9.2).
39
40## 1. Método y condiciones — leer antes de citar un número
41
42- **Máquina**: `momento`, KVM sobre AMD EPYC-Rome, 4 vCPU, 7,7 GiB RAM, Linux 7.1.4,
43  glibc/Artix. Store en `/dev/sdb` (ext4), árbol en `/dev/sdc` (ext4), `/tmp` tmpfs.
44- **Mitigaciones activas**: retpolines (`spectre_v2`), retbleed, SSBD por prctl. **Sin PTI**
45  (AMD, `meltdown: Not affected`). En un Intel con PTI el piso de syscall sería peor.
46- **La máquina estaba CARGADA**: load 7,3 sobre 4 vCPU, un build de LLVM en vuelo, 773 MiB
47  libres. ⇒ **los absolutos son cotas superiores; la señal está en los cocientes dentro de
48  una misma corrida**, que es como está escrito todo lo de abajo.
49- Cada medida son 7–9 rondas; se reporta **mínimo** (mejor caso, el estimador robusto al
50  ruido del scheduler) y **mediana**. Las corridas marcadas «pinneado» fijan el proceso a un
51  cpu para sacar de en medio la cola del planificador.
52- **SEGUNDA CORRIDA, mismo día, con root** (§9): la máquina estaba mucho más suelta —load ~1,3
53  sobre 4 vCPU y 4,3 GiB libres— y por eso **los absolutos de las dos corridas NO se comparan
54  entre sí**. Cada cociente que se cita abajo sale de una sola corrida, y se dice de cuál.
55- Fuentes y salidas crudas: `docs/evidencia/tasas-kernel-2026-08-29/`.
56- **Piso de referencia**: una syscall nula (`getppid`) cuesta **78,7 ns**. El vDSO
57  (`clock_gettime`) cuesta 31,2 ns y por syscall 143,8 ns ⇒ **cruzar al kernel son ~110 ns**.
58  Todo lo de abajo se lee en «syscalls equivalentes».
59
60## 2. La lista
61
62### T1 · `fork()` copia el espacio de direcciones del padre
63
64| padre con … | `fork+_exit+wait` | `posix_spawn+wait` |
65|---|---|---|
66| 0 MB tocados | 109 µs | 231 µs |
67| 64 MB | 938 µs | 234 µs |
68| 256 MB | **3 949 µs** | **231 µs** |
69
70≈ **59 ns por página de 4 KiB del padre**, ida y vuelta. `posix_spawn` (que usa
71`CLONE_VFORK|CLONE_VM`) es **plano**: no mira el tamaño del padre. A 256 MB, **17× más
72barato — haciendo estrictamente más trabajo** (además ejecuta un binario).
73
74Es la tasa POSIX por excelencia: `fork` no se puede arreglar sin romper la semántica, y la
75salida está dentro del propio POSIX.
76
77### T2 · `exec` + enlazado dinámico
78
79| | µs/exec |
80|---|---|
81| musl ESTÁTICO | **77,4** |
82| glibc ESTÁTICO | 232,7 |
83| glibc DINÁMICO | 324,3 |
84
85`ld.so` cuesta **+92 µs** (+39%). Pero el salto grande es glibc→musl: **4,2× entre el peor y
86el mejor**, con el mismo `main(){return 0;}`. El corpus de hammer ya está del lado bueno
87(verificado: los binarios del store son `statically linked`); esto **cuantifica** lo que la
88de-Alpinización compró: un build que lanza 20 000 procesos se ahorra ~5 s sólo en arranque.
89
90### T3 · `/proc` es una API de TEXTO, y se paga como tal
91
92| | ns | = syscalls |
93|---|---|---|
94| `getrusage(RUSAGE_SELF)` | 238 | 3 |
95| `clock_gettime(PROCESS_CPUTIME)` | 214 | 3 |
96| `pread`+parse `/proc/self/stat` (fd ya abierto) | 1 271 | 16 |
97| `open`+`read`+parse `/proc/self/stat` | **2 692** | **34** |
98| `open`+`read`+parse `/proc/self/status` (VmRSS) | **4 643** | **59** |
99
100Leer el CPU propio por `/proc` cuesta **11× más** que `getrusage`. Y la mitad del coste es
101abrir la ruta, no el texto (1 271 vs 2 692 con el fd cacheado).
102
103**Barrido completo** (291 procesos vivos): `readdir` solo **106 µs**; `readdir` + `stat` de
104cada pid **991 µs**, o sea **3,4 µs por proceso**.
105
106### T4 · Contabilidad por unidad: cgroup v2 es O(1) donde `/proc` es O(procesos)
107
108Leer `cpu.stat` + `memory.current` + `pids.current` de un cgroup: **4,6 µs**, y **no depende
109de cuántos procesos tenga la unidad**. Sumar `/proc` para esa misma unidad: 3,4 µs × N.
110**El cruce está en N = 2.** Para una unidad de 20 procesos, 15× a favor del cgroup.
111
112### T5 · Liveness por `/proc/<pid>`: la carrera, no la lentitud
113
114| | ns |
115|---|---|
116| `access("/proc/<pid>")` — lo que se usa hoy | 345 |
117| `kill(pid, 0)` | 119 |
118| `pidfd_send_signal(fd, 0)` | 119 |
119
120`pidfd` **no es más rápido que `kill(0)`**; es 2,9× más rápido que la ruta `/proc`. Su valor
121real es otro: **no hay reuso de PID**, y el fd se vuelve legible al morir el proceso ⇒ entra
122en el `epoll` y el supervisor deja de sondear.
123
124### T6 · Señales: la notificación más cara de POSIX
125
126`kill(self,SIGUSR1)` + handler = **1 165 ns = 15 syscalls**. Un `eventfd` en el bucle de
127eventos hace el mismo trabajo por una fracción.
128
129### T7 · Despertar cuesta µs; sincronizar en usuario cuesta ns
130
131| | ns |
132|---|---|
133| `pthread_mutex` lock+unlock sin disputa | **8,6** |
134| RTT `eventfd` (2 hilos, mismo cpu) | 2 507 |
135| RTT `pipe` | 2 956 |
136| RTT `socketpair` AF_UNIX | 3 639 |
137
138**291× entre sincronizar en espacio de usuario y despertar por el kernel.** El bus de arje
139(postcard sobre socket Unix) paga ~3,6 µs por ida y vuelta: aceptable por mensaje, ruinoso
140por campo.
141
142Adyacente: `sched_yield` 174 ns; `nanosleep(1 ms)` se pasa **65 µs** bajo carga ⇒ los lazos
143de control no se construyen sobre `sleep`.
144
145### T8 · `stat()` es tasa del VFS, no del filesystem
146
147| ns/fichero | ext4 | tmpfs |
148|---|---|---|
149| `stat()` por ruta completa | 648 | 714 |
150| `fstatat(dirfd, nombre)` | 439 | 489 |
151| `statx(…, DONT_SYNC)` | 467 | 593 |
152| `openat`+`close` | 899 | 961 |
153| **`getdents64` (barrido, sin stat)** | **168** | **59** |
154
155**ext4 ≈ tmpfs en `stat`.** ⇒ una tormenta de `stat` **no se arregla cambiando de
156filesystem**; se arregla no haciéndola: `getdents64` da el barrido **3,9× más barato en ext4
157y 12× en tmpfs**, y `fstatat` relativo a un `dirfd` ahorra 32% sobre la ruta completa.
158
159**Profundidad de ruta**: 12 componentes extra cuestan +205 ns en ext4 y +203 en tmpfs ⇒
160**~17 ns por componente**, idéntico en ambos. Otra vez: el VFS, no el disco.
161
162### T9 · `openat2` con `RESOLVE_BENEATH` es casi gratis
163
164ext4: 1 025 vs 899 ns (+14%). tmpfs: 763 vs 961 ns (midió *más rápido*, o sea dentro del
165ruido). ⇒ **la resolución hermética de rutas no tiene precio apreciable.** Es material
166directo para harkaq (SDD 16): la garantía «no se sale del árbol» sin demonio auxiliar y sin
167una syscall extra.
168
169### T10 · Materializar un árbol: hardlink vs copia
170
171| 2 000 ficheros de 1 byte | ext4 | tmpfs |
172|---|---|---|
173| `link()` | 9,2 µs | 2,9 µs |
174| `open+read+write+close` | 142,2 µs | 5,0 µs |
175| **cociente** | **15,4×** | 1,7× |
176
177Lo que hace cara la copia es el **journal de ext4**, no el VFS. La estrategia de hardlinks de
178`.dmerge` está bien elegida — y su contrapartida ya está documentada (la caché retiene lo que
179se borra del store).
180
181### T11 · `copy_file_range`/`sendfile` no ganan sobre ext4
182
18364 MiB en caché: `read+write` 2 837 MB/s · `sendfile` 3 345 · `copy_file_range` 3 521. ~20%
184en el mejor caso. **ext4 no tiene reflink**, así que `copy_file_range` cae a una copia dentro
185del kernel. El «copiar en O(1)» que la gente espera **exige un FS con reflink** (xfs/btrfs) —
186sin medir acá, §9.
187
188### T12 · io_uring no es una ganancia universal
189
190| | ns/op |
191|---|---|
192| syscall nula | 78,7 |
193| **io_uring NOP en lote (piso de operación)** | **47,7** |
194| `pread` 4K en caché (ext4) | 540 |
195| io_uring read 4K profundidad 32 (ext4) | 594 |
196| `pread` 4K (tmpfs) | 602 |
197| io_uring read 4K (tmpfs) | **1 672** |
198
199El piso por operación es **0,61× una syscall**: en lote, io_uring amortiza el cruce. Pero
200sobre datos ya cacheados **pierde** — 10% en ext4 y **2,8× en tmpfs**. io_uring paga cuando
201las operaciones son muchas, agrupables y **de verdad bloquean**. Sobre caché es una
202pesimización.
203
204### T13 · THP puede ser 3× PEOR (y acá lo es)
205
20664 MiB anónimos, ns por página de 4 KiB: `MADV_HUGEPAGE` **3 046** · `MADV_NOHUGEPAGE`
207**1 013** · `MAP_POPULATE` **752**.
208
209La causa está en la máquina, no en el kernel:
210`/sys/kernel/mm/transparent_hugepage/defrag = madvise` ⇒ una región con `MADV_HUGEPAGE`
211dispara **compactación síncrona** en el fallo de página, y con 773 MiB libres eso es caro.
212**THP bajo presión de memoria es un pasivo de latencia, no una optimización.** Reproducido en
213las dos corridas independientes (128 MiB y 64 MiB).
214
215`mmap`+`munmap` de 4K: 1 664 ns.
216
217### T14 · El sandbox por namespaces cuesta ~1 ms por proceso
218
219`fork+exec` base 1 649 µs · con `unshare` de 6 namespaces 2 742 µs · con `USER|MNT` 2 050 µs.
220⇒ **+1,09 ms** por el juego completo, **+0,40 ms** por USER|MNT.
221
222Para hammer es ruido por fase de build (segundos a minutos). Sería caro **sólo si se
223enjaulara por-exec**: 20 000 execs × 1,09 ms = 22 s.
224
225### T15 · Cerrar descriptores antes del `exec`
226
227`dup+close` uno a uno: 0,2 µs/fd ⇒ 512 fds = 102 µs. `close_range(lo,hi)`: por debajo del
228ruido. Gratis, y ya está en mainline.
229
230### T16 · Hilo vs proceso
231
232`pthread_create`+`join` = **11,9 µs**, contra 109 µs de `fork+_exit` con el padre vacío:
233**9×**, y la distancia crece con el tamaño del padre (T1).
234
235## 3. Las cinco sorpresas
236
237Las anoto aparte porque contradicen el consejo de manual:
238
2391. **THP más lento que 4K** (T13) — el manual dice que THP acelera; con `defrag=madvise` y
240   memoria apretada, triplica el coste del fallo.
2412. **io_uring más lento que `pread`** sobre tmpfs (T12) — el manual dice que io_uring es el
242   futuro; sobre datos cacheados el futuro pierde 2,8×.
2433. **`stat` cuesta lo mismo en tmpfs que en ext4** (T8) — invalida la reacción natural
244   («movamos el árbol a tmpfs y vuela»): el coste está en el VFS.
2454. **`taskstats` binario NO es más rápido que parsear `/proc`** (§9.1) — 2 688 vs 2 697 ns por
246   consulta. La intuición «binario le gana a texto» falla porque el ida y vuelta de netlink cuesta
247   lo mismo que `open`+`read`+parse. Su valor es el **contenido** (delay accounting, que `/proc` no
248   da) y la estabilidad bajo carga, no la velocidad.
2495. **Sondear `/proc` no es lento: es CIEGO** (§9.1) — de 200 procesos de vida mínima lanzados uno
250   cada 10 ms, un sondeo cada 100 ms vio **cero**. Toda la discusión de «cuánto cuesta el barrido»
251   (T3) presupone que el barrido VE lo que hay, y para procesos cortos no lo ve.
252
253## 4. El hallazgo cruzado: los kernels de hammer no tienen `MEMCG`
254
255No lo buscaba; salió de verificar la recomendación antes de escribirla.
256
257**Lado hammer.** Las recetas hacen `make ARCH=x86_64 defconfig` y después
258`scripts/config`. Lo que `arch/x86/configs/x86_64_defconfig` trae de contabilidad:
259`CONFIG_TASKSTATS=y`, `TASK_DELAY_ACCT=y`, `CGROUPS=y`, `CGROUP_SCHED=y`, `CGROUP_PIDS=y`,
260`CGROUP_FREEZER=y`, `CONNECTOR=y` ⇒ y `PROC_EVENTS` es `default y` con `depends on
261CONNECTOR=y`, así que **también entra**.
262
263**`CONFIG_MEMCG` no está en el defconfig y no tiene `default y` ⇒ queda en `n` en todos los
264kernels de hammer.** `CONFIG_PSI`, igual.
265
266**Lado tawasuyu.** `sandokan-core::Engine` expone `set_memory_max` / `set_memory_high`
267(`shared/sandokan/sandokan-core/src/engine.rs:60-72`), `sandokan-local` los delega a
268`arje_incarnate::cgroup` (`03_ukupacha/sandokan/sandokan-local/src/lib.rs:675-681`), y ahí:
269
270```rust
271// arje/init/arje-incarnate/src/cgroup.rs:60
272let _ = std::fs::write(abs.join("cpu.weight"), format!("{w}\n"));   // error DESCARTADO
273// :79
274match std::fs::write(&path, format!("{mem}\n")) {
275    Err(e) => tracing::warn!(..., "memory.max write failed"),        // sólo un warn
276```
277
278**Consecuencia.** Sobre un sistema hammer, una Card que pide un tope de memoria arranca
279**sin tope**, y la única huella es una línea de log. Es exactamente la forma de fallo que
280`CLAUDE.md` §3 nombra: *un ausente falla ruidosamente; un vacío llega hasta el final diciendo
281que todo fue bien*. La jaula que no está se comporta igual que la jaula que sí está, hasta
282que hace falta.
283
284### 4.bis · Confirmado sobre los artefactos, no deducido del defconfig
285
286Lo de arriba se dedujo leyendo `x86_64_defconfig`. Se comprobó después contra los **`.config` que
287las recetas instalan** en `boot/config-<versión>`, que es la prueba dura porque incluye lo que hizo
288`olddefconfig`. Los **11 kernels sellados del store** —cinco nombres de artefacto: `linux`,
289`linux-generic`, `linux-metal`, `linux-metal-dual`, `linux-gioser`— traen literalmente:
290
291```
292# CONFIG_MEMCG is not set
293# CONFIG_PSI is not set
294```
295
296y ninguno tiene `CFS_BANDWIDTH` (⇒ `cpu.max`, la cuota dura de CPU, tampoco existe; hoy nadie la
297pide, pero cuando `pacha` la quiera será otro re-hasheo). Lo que **sí** está en los once:
298`CGROUP_SCHED`+`FAIR_GROUP_SCHED` (`cpu.weight`), `CGROUP_PIDS` (`pids.max`), `CPUSETS`
299(`cpuset.cpus`), `BLK_CGROUP`+`BLK_CGROUP_IOCOST` (`io.weight`, con la sintaxis «default N» que
300arje ya usa), `TASKSTATS`+`CONNECTOR`+`PROC_EVENTS`, `SECCOMP_FILTER`, `SECURITY_LANDLOCK`,
301`FANOTIFY`, `OVERLAY_FS` con metacopy e `IO_URING`.
302
303**Y por qué el bug sobrevivió meses**: el kernel de la máquina de desarrollo (Artix 7.1.4) **sí**
304trae `MEMCG`, `PSI` y `CFS_BANDWIDTH`. El fallo sólo existe del lado del artefacto sellado, que es
305el lado que nadie mira con un depurador.
306
307### 4.ter · El guardián: `hammer kernel contract`
308
309Un hallazgo escrito en un documento no impide que vuelva a pasar. El contrato vive en
310`docs/state/kernel-contract.toml` y declara, por capacidad: los símbolos que la construyen, la
311interfaz que aparece o no aparece (`memory.max`, `pids.max`, `landlock_restrict_self`…), **el
312consumidor con ruta y símbolo**, y **cómo falla hoy si no está**. Se comprueba contra un `.config`
313ya producido:
314
315```sh
316hammer --store ./store kernel contract --sealed     # barre los kernels sellados
317hammer kernel contract --profile anfitrion-cards    # el kernel vivo de esta máquina
318hammer kernel contract --list                       # qué promete hammer (esto es el W6)
319```
320
321Tres decisiones que valen la pena nombrar:
322
3231. **Por perfil, no global** — misma lección que el gate de hardware. `linux.toml` es el kernel de
324   QEMU del selfhost-verify: no hospeda Cards y su hash es load-bearing del baseline `of_tree`.
325   Exigirle contabilidad de memoria sería rechazar una receta sana, así que ahí los límites por
326   unidad son `wants` y no `requires`.
3272. **Contra el `.config`, no contra la receta** — entre el `scripts/config -e X` y el `.config`
328   está `olddefconfig`, que puede tragarse el símbolo sin decir nada (es justo lo que
329   `hammer kernel diff-back` ya vigila para los planes).
3303. **Distingue apagado de ausente** — un símbolo que el `.config` ni nombra puede ser un
331   renombrado entre versiones. Cuenta igual como capacidad ausente, pero se informa aparte; y un
332   kernel sin perfil declarado queda **SIN COMPROBAR** en vez de contar como aprobado.
3334. **Distingue vigente de superado** (agregado al pagar H1) — el store guarda **todos** los
334   sellados, no el último. Mirándolos a todos por igual, arreglar la receta dejaba el gate rojo
335   para siempre por artefactos que nadie va a volver a construir, y **un portón que no puede
336   ponerse verde deja de leerse**. Ahora cada sellado se compara con el `ArtifactHash` que la
337   receta de hoy produce —la misma vigencia de `hammer hash --check`, lab incluido—: el vigente
338   bloquea; el superado sale en su propia sección con lo que le falta, porque sigue siendo cierto
339   que una máquina que arranque ese kernel corre sus Cards con lo que ese kernel traiga. Y dos
340   negativas explícitas: si la vigencia no se puede resolver se comprueba **todo** y se dice por
341   qué, y **cero vigentes con superados a la vista sale ≠0**, no verde — el vacío leído como
342   presencia (CLAUDE.md §3) es justo el fallo que este guardián vino a arreglar.
343
344Estado al escribirlo: **2 de 11 configs sellados cumplían su perfil** (los dos `linux`), los 9 de
345perfil `anfitrion-cards` fallaban por `MEMCG`. **Estado tras pagar H1 (2026-08-30): 5 de 5 vigentes
346cumplen**, y los 10 sellados que quedaron atrás salen listados como superados. El kernel vivo de
347esta máquina pasa las 11 exigidas.
348
349Lo que **sí** funciona en un kernel hammer: `cpu.weight` (CGROUP_SCHED), `pids.max`
350(CGROUP_PIDS), `cpu.stat` (rstat del core) y `cgroup.freeze` — este último porque el freezer
351v2 es `obj-y` en `kernel/cgroup/Makefile`, no el `CONFIG_CGROUP_FREEZER` de v1.
352
353## 5. Qué se esquiva SIN escribir kernel
354
355| Tasa | Reemplazo mainline | Ganancia medida |
356|---|---|---|
357| T1 `fork` de padre grande | `posix_spawn` / `CLONE_VFORK` | 17× a 256 MB, y plano |
358| T2 `ld.so` | binario estático musl | 4,2× |
359| T3 `/proc` texto | `getrusage`, `taskstats` | 11× |
360| T4 sumar `/proc` por unidad | agregado de cgroup v2 | O(1) vs O(N), cruce en N=2 |
361| T5 liveness por `/proc` | `pidfd` (+ sin carrera de PID) | 2,9× y correctitud |
362| T3 enumerar procesos | proc connector (netlink): eventos push | **0 vs 200 procesos vistos** (§9.1) |
363| T6 señales | `eventfd`/`signalfd`/`pidfd` | 15 syscalls → 1 |
364| T8 tormenta de `stat` | `getdents64`, `fstatat(dirfd,…)` | 3,9×–12× |
365| T9 hermetismo de rutas | `openat2 RESOLVE_BENEATH` | ~gratis |
366| T10 materializar árbol | `link()` | 15,4× en ext4 |
367| T11 copiar un fichero entero | `FICLONE`/reflink **en xfs o btrfs** | **25 600× a 512 MiB** (§9.2) |
368| T15 cerrar fds | `close_range` | 102 µs → ~0 |
369
370**Ninguna de estas exige un módulo, un parche ni un kernel propio.** Es la primera conclusión
371del documento y la que ordena todo lo demás.
372
373## 6. Qué exigiría tocar el kernel — y su precio en hammer
374
375Después de agotar §5 quedan tres deseos legítimos que mainline no da:
376
3771. **Una syscall que devuelva un lote de estadísticas por proceso en binario.** Lo más
378   cercano es `taskstats` (por tarea, netlink) y el agregado de cgroup. No existe el «dame
379   los 291 en una llamada».
3802. **Eventos de estado con más contexto que el proc connector.**
3813. **Un plano de control de unidades que no pase por el filesystem.**
382
383Su precio, concreto:
384
385- **Es built-in, no `.ko`** (`-d MODULES`). ⇒ parche a la receta ⇒ entra en `hash_inputs`
386  ⇒ kernel nuevo, artefacto nuevo, y rebase manual en cada versión.
387- **Nunca un número de syscall nuevo**: choca con upstream para siempre. Lo compatible es un
388  char device, un fichero propio en sysfs, o una kfunc BPF.
389- **Con eBPF (que es la forma sin código out-of-tree) el precio es `DEBUG_INFO_BTF`**, hoy
390  apagado en las cuatro recetas con motivo escrito (`linux.toml:32`: *«pahole (BTF), ausente
391  del toolchain»*). Deuda ya medio pagada: dwarves construye (frente libdw/musl cerrado).
392- **El bloqueo de diseño, que no es técnico**: `SDD-SERVIDOR-AJENO.md` promete *«cero
393  invasión — la máquina sigue siendo su Ubuntu de siempre»*. Un sandokan que dependa de un
394  kernel hammer deja de correr ahí. ⇒ **el núcleo se queda portable siempre; lo rápido es un
395  backend opcional detectado en runtime, con `/proc` como respaldo que no se borra.**
396
397## 7. Propuestas — lado hammer
398
399- **H1 · `-e MEMCG -e PSI` en los kernels que hospedan Cards. PAGADO 2026-08-30.** Cierra §4 y
400  habilita `memory.current` (T4) y las señales de presión. Se hizo en **una sola tanda** —el precio
401  era el re-hasheo de todos los artefactos de kernel— sobre `linux-generic`, `linux-metal`,
402  `linux-metal-dual` y la derivada `linux-gioser`, que hubo que **regenerar**: una receta derivada
403  inlinea la fase `configure` de su base y sin regenerarla se queda con la vieja. En `linux.toml`
404  (perfil `qemu-serial`) NO corre: su hash es el baseline del selfhost-verify y ahí no hay Cards.
405
406  Tres cosas que valen para la próxima:
407
408  1. **El `x86_64_defconfig` de 7.1 ya no trae `MEMCG=y`** — de ahí que hiciera falta pedirlo. Y
409     `MEMCG` no tiene un solo `depends on` (sólo `select`s), así que el `olddefconfig` no se lo
410     podía tragar; se comprobó igual **contra el `.config` producido**, que es la regla.
411  2. **Precio en bytes, medido**: bzImage `linux-generic` 16 856 064 → 16 937 984 (**+80 KiB,
412     +0,49%**), `linux-metal` +84 KiB (+0,57%), `linux-metal-dual` +88 KiB (+0,53%), `linux-gioser`
413     +80 KiB (+0,71%). Contabilidad por unidad y presión, por medio punto porcentual de kernel.
414  3. **La prueba de que se pagó es el mismo comando**: `hammer kernel contract --sealed` sale 0 y
415     dice `5 de 5 config(s) VIGENTES cumplen su perfil`. La salida cruda quedó en
416     `docs/evidencia/tasas-kernel-2026-08-29/contrato-h1-pagado.txt`, junto con el `diff-back` del
417     plan de gioser sobre el config nuevo (35 cumplidos, 0 incumplidos).
418- **H2 · `MODULES=n` se queda.** Si algún día hace falta código de kernel, es built-in y
419  parcheado en la receta. Queda escrito para no rediscutirlo.
420- **H3 · `harkaq` usa `openat2 RESOLVE_BENEATH|RESOLVE_NO_SYMLINKS`** donde hoy valida rutas
421  a mano (T9, ~gratis).
422- **H4 · Ningún `Command` de hammer pone `pre_exec`** — Rust apaga el camino `posix_spawn` en
423  cuanto hay uno, y cae a `fork+exec` (T1: 17× a 256 MB tocados). `hammer-build/sandbox.rs` lanza
424  `bwrap` sin `pre_exec`, o sea que estaba bien **por suerte**: nadie lo comprobaba. **HECHO**: el
425  test `crates/hammer-build/tests/sin_pre_exec.rs` barre las fuentes del workspace y falla si
426  aparece uno (comprobado en los dos sentidos: inyectando un `pre_exec` el test se pone rojo, y un
427  barrido que no encuentra fuentes también, para que no apruebe por vacío). Si algún día hace falta
428  de verdad, la salida es escribir en el test por qué ese caso paga los 17×, no borrarlo.
429- **H5 · La materialización de dependencias se queda en hardlink** (T10) y el experimento de
430  reflink (§9) alimenta SDD 18 (wawafs), donde el store como FS vivo cambiaría el cociente.
431- **H6 · No `madvise(MADV_HUGEPAGE)` en el camino de build** mientras `defrag=madvise` y la
432  granja corra apretada de RAM (T13).
433- **H7 · `DEBUG_INFO_BTF` sigue apagado** hasta que haya un consumidor real de BPF; cuando lo
434  haya, la deuda es pahole en el lab y un re-hasheo, no un rediseño.
435- **H8 · El contrato de capacidades es parte del release del kernel** (§4.ter). Toda receta de
436  kernel nueva declara su `[[target]]` con perfil; un kernel sin perfil sale **SIN COMPROBAR**, no
437  aprobado. Y toda capacidad nueva entra con consumidor —ruta y símbolo— o no entra: «estaría bueno
438  tener» no es un contrato.
439- **H9 · El experimento de reflink cambia el cálculo de SDD 18, no el de hoy.** Con `.dmerge` sobre
440  ext4 el hardlink sigue siendo la elección correcta (T10). Lo que §9.2 agrega es que un store
441  sobre **xfs o btrfs** compraría semántica de copia —mutación privada, sin la contrapartida de
442  retener lo borrado— al mismo precio. Es un argumento para wawafs, medido; no un cambio de
443  filesystem decidido acá.
444
445## 8. Propuestas — lado tawasuyu
446
447Detalle en el handoff espejo. En una línea cada una:
448
449- **W1 · `pidfd` para liveness y señales** en `sandokan-local` (hoy `access("/proc/<pid>")` y
450  `waitpid(WNOHANG)` en sondeo). Se gana correctitud (carrera de PID) antes que velocidad.
451- **W2 · Telemetría por unidad desde el cgroup**, no sumando `/proc` (T4). Con **sonda de
452  capacidad**: si `memory.current` no existe (kernel sin MEMCG), decirlo, no callarlo. Del lado
453  hammer esa sonda ya tiene con qué contrastarse: `hammer kernel contract --list --json` publica
454  qué promete cada perfil de kernel (§4.ter), que es el W6 en formato de dato.
455- **W3 · `arje-incarnate` con `posix_spawn`** donde el `pre_exec` no sea imprescindible (T1),
456  y `close_range` en el que quede.
457- **W4 · Los errores de cgroup dejan de descartarse.** `let _ = write(...)` y `warn!` sobre un
458  límite no aplicado son el bug de §4, no un detalle de estilo.
459- **W5 · `/proc` no se borra nunca**: es el respaldo portable que hace posible
460  SDD-SERVIDOR-AJENO.
461- **W6 · El contrato entre repos es el trait `Engine`, no una ABI de kernel.** hammer publica
462  la lista de símbolos garantizados (verificable con `hammer kernel probe`); tawasuyu elige
463  backend en runtime.
464
465## 9. Los experimentos nombrados — cuatro medidos, dos abiertos
466
467La primera corrida los dejó nombrados y sin medir, todos por privilegios o por herramienta
468ausente. **Cuatro cayeron el mismo día, con root.** Condiciones distintas a la corrida de arriba
469(load ~1,3 sobre 4 vCPU, 4,3 GiB libres) ⇒ los números de acá **no se cruzan** con los de §2.
470
471### 9.1 · proc connector y `taskstats` — MEDIDO (`bench_connector.c`, `connector.txt`)
472
473**a) Latencia.** Esperar el evento `PROC_EVENT_EXIT` del connector **no cuesta más** que el
474`waitpid` que el padre ya hace: 116,0 µs contra 114,8 µs por `fork+_exit` (mínimo de 7 rondas de
475200), es decir dentro del ruido, con **0 eventos perdidos de 1 400**. Con una advertencia dura que
476salió del propio experimento: el multicast del connector **no reintenta**. Si el buffer del socket
477se llena, el evento se pierde y quien lo espera se cuelga para siempre — la primera versión del
478programa se colgó exactamente así. Un supervisor sobre connector necesita `SO_RCVBUF` grande **y
479un plazo**, no una espera infinita.
480
481**b) Cobertura — el resultado que importa.** 200 procesos de vida mínima, uno cada 10 ms:
482
483| observador | vistos | CPU |
484|---|---|---|
485| sondeo de `/proc` cada 100 ms (23 barridos) | **0 de 200** | 10,5 ms |
486| proc connector (eventos) | **200 de 200** | 95,4 ms |
487
488El sondeo no es caro: es **ciego**. Y la CPU del connector de esa tabla es cota superior — el
489programa lo lee con espera activa de 200 µs, que no es el modo de un supervisor real (sería
490`epoll`, donde el coste es despertar por evento).
491
492**c) `taskstats`.** La familia genetlink existe y responde. Por consulta: **2 688 ns** contra
493**2 697 ns** de `open`+`read`+parse de `/proc/self/stat`. **No gana en velocidad** (sorpresa §3.4).
494Lo que da y `/proc` no: contabilidad de retrasos (delay accounting) y una estructura binaria
495estable en vez de un texto que hay que parsear posicionalmente.
496
497### 9.2 · Copia con reflink — MEDIDO (`bench_reflink.c`, `reflink.txt`)
498
499`mkfs` sobre un loop, xfs con `reflink=1` y btrfs por defecto. Copiar un fichero **entero**:
500
501| | ext4 | xfs (loop) | btrfs (loop) |
502|---|---|---|---|
503| `FICLONE` (reflink) | **no soportado** | 0,010 ms | 0,006 ms |
504| `copy_file_range` | 13,66 ms | 0,010 ms | 0,006 ms |
505| `read+write` (1 MiB) | 14,46 ms | 10,96 ms | 31,32 ms |
506
507Y la prueba de que es O(1) y no «rápido»: **con el fichero ocho veces más grande (512 MiB), el
508reflink pasa de 0,010 a 0,020 ms** —el doble, no ocho veces— mientras `read+write` pasa de 10,96 a
509512,7 ms. **25 600× a 512 MiB en xfs.** En btrfs, 0,006 → 0,015 ms.
510
511Confirma T11 por el lado contrario: en ext4 `copy_file_range` no gana nada (13,66 contra 14,46 ms,
512un 6%) **porque ext4 no tiene reflink**; el «copiar en O(1)» que la gente espera de esa syscall es
513una propiedad del filesystem, no de la syscall. Material directo para SDD 18 (wawafs): con reflink
514se obtiene semántica de **copia** al precio del hardlink, y sin la contrapartida del hardlink —que
515`.dmerge` ya paga: retener en la caché lo que se borró del store.
516
517### 9.3 · io_uring con `SQPOLL` — MEDIDO (`bench_sqpoll.c`, `sqpoll.txt`)
518
5194K aleatorios en caché, profundidad 32, fd registrado:
520
521| ns/op | ext4 | tmpfs |
522|---|---|---|
523| `pread` | **554** | **749** |
524| io_uring sin SQPOLL | 618 | 2 030 |
525| io_uring con SQPOLL | 868 | 1 409 |
526
527**No cambia el veredicto de T12.** Sobre datos cacheados `SQPOLL` sigue perdiendo contra la
528syscall (1,6× peor en ext4), y aunque en tmpfs mejora al io_uring normal (1,4×), sigue estando
5291,9× por detrás de `pread`. Encima **se come un core** con el hilo del kernel, que en una máquina
530de 4 vCPU es el 25% de la granja. `SQPOLL` es para operaciones que **de verdad bloquean**, no para
531amortizar cruces sobre caché.
532
533### 9.4 · Coste en syscalls de un compilado — MEDIDO (`syscalls-compilador.txt`)
534
535La corrida original decía «sin `strace`/`perf` en esta máquina no se puede atribuir». **El
536`strace` estaba en el propio corpus** (`store/3c1fd8c0…-strace`, 6.19): la distro se paga a sí
537misma la herramienta de diagnóstico. Un `-c` de un `main()` trivial con stdio/stdlib/string:
538
539| | syscalls | con error | el grueso |
540|---|---|---|---|
541| `cc -O2 -c` (gcc 16) | 1 803 | **1 095 (61%)** | **919 de 923 `readlink` FALLAN** |
542| `zig cc -O2 -c` (zig 0.16) | 3 608 | 214 (6%) | 1 104 `futex` (70% del tiempo en syscall) |
543
544Dos lecturas:
545
546- **La tormenta de rutas de T8 existe y es de `readlink`, no de `stat`** — canonicalización de
547  rutas de gcc, que T8 no medía. Pero **al piso de 78,7 ns, 1 803 cruces son 0,14 ms sobre 30,5 ms
548  de compilado: el 0,5%.** La respuesta a la pregunta original («¿vale segundos o minutos por
549  receta?») es **milisegundos por invocación**: segundos por millar de compilados. No es ahí donde
550  está el tiempo de una tanda.
551- **`zig cc` tiene otro perfil**: casi no falla rutas, pero coordina hilos. El tiempo que
552  `strace -c` le atribuye es espera **bloqueada**, no CPU — y por eso `strace -c` no sirve para
553  comparar compiladores, sólo para contar llamadas.
554
555### 9.5 · Lo que sigue abierto
556
5571. **Iterador BPF contra `/proc`** (T3): exige BTF y privilegios. Va detrás de H7 —
558   `DEBUG_INFO_BTF` está apagado en las cuatro recetas y su deuda (pahole) ya está medio pagada.
5592. **Un Intel con PTI**: todos los pisos de syscall de acá son de un AMD sin PTI. En el laptop
560   (TigerLake) las mismas medidas darían peor, y ahí T3/T6 duelen más.
561
562## 10. Evidencia
563
564`docs/evidencia/tasas-kernel-2026-08-29/` — **primera corrida**: cuatro programas en C
565(`bench_proc.c`, `bench_io.c`, `bench_extra.c`, `bench_pin.c`) y sus cinco salidas crudas
566(`proc.txt`, `io-ext4.txt`, `io-tmpfs.txt`, `extra.txt`, `pin.txt`). Se compilan con
567`cc -O2` (`bench_io` pide `-luring`, `bench_proc`/`bench_pin` piden `-lpthread`) y se corren
568sin argumentos salvo `bench_io <dir>` y `bench_pin <estatico> <dinamico> <musl>`.
569
570**Nota de unidad**: en `pin.txt` la sección de fallos de página imprime ns/página × 1000 por
571un factor de escala equivocado en el programa; los valores citados en T13 son los de esa
572salida divididos por 1000, y coinciden con `io-ext4.txt`, que sí está en la unidad correcta.
573
574**Segunda corrida (§9, con root)**: `bench_connector.c` → `connector.txt`; `bench_reflink.c` →
575`reflink.txt` (xfs y btrfs sobre loop, montados y desmontados por el propio guion);
576`bench_sqpoll.c` → `sqpoll.txt`; y `syscalls-compilador.txt`, hecho con el `strace` **del store**.
577Se compilan igual que los otros (`bench_sqpoll` pide `-luring`) y los tres primeros piden root:
578`bench_connector` por `CAP_NET_ADMIN`, `bench_reflink` por `mkfs`+`mount`, `bench_sqpoll` por
579`CAP_SYS_NICE`.
580
581**Contrato de capacidades**: `docs/state/kernel-contract.toml` (el dato) y
582`hammer kernel contract --list` (la vista). Los ficheros de esta carpeta no cambian; el contrato sí
583—cada vez que un consumidor nuevo usa el kernel por nombre.
584
585**El pago de H1** (2026-08-30): `contrato-h1-pagado.txt` — el barrido entero con los cuatro kernels
586reconstruidos (5 de 5 vigentes en verde, 10 superados listados) y el `diff-back` del plan de gioser
587contra su `.config` nuevo. Es la única salida de esta carpeta que sí cambia si se vuelve a correr:
588las demás son mediciones de un momento, ésta es un veredicto de hoy.