fix(ci,#15091): budget memoire po-2024 coherent avec la VM de 24 Go + mur kernel

[jsboige]

Grain: DEEP/tooling -- lane myia-po-2024:CoursIA -- prev: MED/notebook-python #19795

Mission ai-01 (DM URGENT, 2026-10-08). La VM WSL de po-2024 fait 24 Go, la CI y déclarait un budget de 42 Go pour une composition de 27 648 Mo de caps, et la machine n'avait aucun mur kernel derrière ce budget : 104 GiB écrits dans le swap en moins de 11 h, DriveFS emporté le premier, puis G: et RooSync — l'arrêt de la coordination de la flotte.

Ce que la mesure dit (2026-10-08, firsthand sur po-2024)

Grandeur	Valeur mesurée
VM (free -m, .wslconfig)	24 032 Mo (memory=24GB)
Budget déclaré par les wrappers	42 Go
coursia-ci.slice	chargée mais inactive (dead), fichier /etc/systemd/system/coursia-ci.slice inexistant
MemoryHigh / MemoryMax / MemorySwapMax	infinity — aucun mur kernel
Swap	6 285 Mo consommés au relevé ; 104 GiB écrits depuis le boot
Composition réelle des caps	6×1536 docker + 12×512 waiters + 2×6144 lean = 27 648 Mo

Le 42 était faux deux fois — et cette PR le défait sciemment.

Le 42 a été posé par #17322 (« declarations budget po-2024 12->42 Go (VM WSL 40 Go) »), et la composition actuelle par #18691 (« waiters hors du budget CPU + deploy po-2024 (30, docker 8->6) »). Cette PR ne les contredit pas sur leur raisonnement : elle constate que leur prémisse a changé.

1. La VM est revenue de 40 110 à 24 032 Mo. Le 42 datait du 2026-09-21, calibré pour memory=40GB (arbitrage user, mission msg-20260921T203652-qxg3en) ; .wslconfig et free -m disent tous les deux 24 Go aujourd'hui. fix(runners): declarations budget po-2024 12->42 Go (VM WSL 40 Go) #17322 avait raison le jour où il a été écrit — c'est la VM qui a rebouclé en arrière depuis, sans que le budget suive.
2. Son arithmétique n'a jamais été la vraie : le commentaire justifiait « 8×1536 docker + 12×1536 waiters + 2×6144 lean = 43 008 Mo », alors que WAITER_MEMORY vaut 512m (supervise.sh l.180). La composition réelle totalisait 27 648 Mo — déjà supérieure à la RAM de la VM, et c'est cela qui se payait en swap.

Arithmétique retenue — budget 21, le même nombre sur les trois jambes

Famille	Slots	Cap unitaire	Total
docker (start)	6 → 4	1 536 Mo (inchangé)	6 144 Mo
waiters	12 → 6	512 Mo (inchangé)	3 072 Mo
lean	2 (inchangé)	6 144 Mo (inchangé)	12 288 Mo
		total caps	21 504 Mo

VM 24 032 Mo − caps 21 504 Mo = 2 528 Mo de marge pour le noyau WSL2, dockerd et le page cache. Mesure du même jour : le système hors conteneurs pesait ~3 200 Mo, dont 2 429 Mo de buff/cache — reclaimable, et c'est précisément ce que MemoryHigh met sous pression avant le mur.

On réduit des NOMBRES DE SLOTS, jamais des CAPS. Mesure : 3 des 6 conteneurs docker touchaient leur cap de 1536 Mo à 99 % (1,492 / 1,474 / 1,497 GiB) — le cap unitaire n'est pas en trop, c'est la concurrence qui ne tenait pas. Un job lourd garde exactement le même régime mémoire ; il attend son tour au lieu de pousser la machine dans le swap.

CPU, conséquence et non arbitrage : COURSIA_RUNNER_CPU_BUDGET passe de 30 à 24 (4×3 + 2×6) mécaniquement, par la même règle qu'avant (le budget est la somme des caps). L'axe CPU lui-même n'est pas tranché ici — #15574 a son propre point de retour mesuré J+7, qui tombe aujourd'hui et reste ouvert.

Le mur kernel — ce que la PR ajoute vraiment

Un budget userspace refuse de démarrer un slot ; il ne borne pas ce qu'un slot déjà lancé consomme. C'est tout l'écart, et aucun garde userspace ne peut le fermer.

persist/po-2024/coursia-ci.slice (nouveau, homonyme de la slice d'ai-01, valeurs différentes) :

MemoryHigh=20G      # pression + reclaim du page cache avant le mur
MemoryMax=22G       # filet de dernier recours, 2 Go sous la VM
MemorySwapMax=0     # AUCUN SWAP POUR LA CI

MemorySwapMax=0 est l'arbitrage central, et il est assumé, pas subi. Le swap d'une VM WSL est un fichier sur le disque Windows : chaque page poussée retarde DriveFS, puis G:, puis RooSync. Un job qui dépasse son cap doit mourir (exit 137, échec local, retryable, un job perdu) plutôt que d'emporter la coordination de la flotte.

Conséquence nommée, pour qu'elle ne soit pas découverte en panne : la jambe lean perd son coussin. LEAN_MEMORY_SWAP valait 12g (6 Go RAM + 6 Go swap par slot). Le commentaire du bloc LEAN de supervise.sh documente pourquoi — « supprimer le swap ne retire pas le pic de Hashlife, il transforme un build qui déborde en un exit 137 — c'est un curseur, pas un dogme ». Le curseur est ici tourné dans l'autre sens, délibérément. Le build Hashlife de conway_lean dépassait 16 Go à froid : à 6 Go sans swap il ne passera pas. La réponse n'est pas de remonter le swap de cette machine, elle est de router ce lake vers un runner hosted (32 Go de fallocate swap, lean-axiom.yml) — exactement la conclusion que le commentaire de supervise.sh tire déjà.

Aucun CPUQuota sur la slice : l'axe CPU a son propre arbitrage et son point de retour du jour. CPUAccounting=yes est posé — on mesure, on ne plafonne pas.

Deux constats de la pose, relevés sur le cgroup vivant et versés ici parce qu'ils changent ce qu'un lecteur peut croire de cette slice :

1. IOWeight=50 est inerte sur ce noyau — et ce n'est pas un défaut de la slice. Les fichiers io présents dans le cgroup sont io.latency, io.max, io.pressure, io.stat : il n'y a pas de io.weight. En cgroup v2, io.weight n'est exposé que sous l'ordonnanceur bfq ; sans lui, c'est io.latency qui tient ce rôle, et systemd rapporte IOWeight=50 comme propriété sans que rien ne soit écrit dans le noyau. Le seul plafond I/O qui mord réellement est io.max — c'est aussi le seul que assert_cgroup_budget lit (supervise.sh l.1147-1149). Un opérateur qui croirait IOWeight protecteur se tromperait : c'est exactement la « garde de façade » que le commentaire d'en-tête de la slice dénonce pour l'unité du superviseur, et elle se reproduit ici pour une autre raison.

2. Le trou de câblage est corroboré par une mesure indépendante. La lane po-2024:Maintenance a relevé le 2026-10-07 que HostConfig.CgroupParent était vide sur les trois familles (jsboige/Maintenance#76, c. 08/10 00:3x) : les conteneurs n'étaient rattachés à aucune slice. C'est la démonstration, depuis un autre instrument que le mien, que poser la slice sans COURSIA_RUNNER_CGROUP_PARENT l'aurait laissée inerte — un cgroup correct que rien n'habite. Les deux moitiés voyagent donc ensemble dans cette PR.

Une sonde à ne pas refaire : [ -s "$cg/io.max" ] rend faux sur un fichier cgroupfs, dont le st_size vaut 0 alors qu'il a du contenu. Le contrôle juste est [ -r ] puis lecture du contenu — ce que fait assert_cgroup_budget. Un test de taille y fabrique un faux « mur absent » sur un mur présent.

Les deux listes exigées par #15202 (cette PR abaisse des bornes)

Jobs dont le pic a été MESURÉ sous la nouvelle valeur

Famille	Mesure (2026-10-08, docker stats)	Cap	Ce que la PR change
docker	1,492 / 1,474 / 1,497 GiB sur 1536 MiB (99 %) pour 3 slots occupés ; 180 / 232 / 283 MiB pour les 3 au repos	1 536 Mo	le cap, non — le nombre de slots, 6 → 4
waiters	59 à 118 Mo sur 512 MiB (12 à 23 %) sur 12 conteneurs	512 Mo	le cap, non — le nombre de slots, 12 → 6
lean	67 et 74 Mo sur 6 GiB (idle au relevé)	6 144 Mo	rien — jambe inchangée

Les deux familles dont on réduit le nombre gardent leur cap unitaire intact : aucun job mesuré ne change de régime mémoire.

Jobs NON mesurés qui tournent sur ce pool, nommés un par un

• coursia-linux (famille start, 4 slots) — 128 workflows la portent. Famille d'exécution générale : les jobs de gate et de vérification du dépôt. Le passage de 6 à 4 slots réduit la concurrence, pas le cap : un job qui consommait 1,5 Go continue de pouvoir le faire, il attend son tour plus souvent.
• coursia-waiter (6 slots) — 4 workflows : pr-gate.yml (le principal), pr-gate-stale-sweep.yml, linux-runner-starvation-advisory.yml, runner-starvation-advisory.yml. Un waiter n'est pas un conteneur inerte : il EXÉCUTE ces jobs. C'est pourquoi son cap de 512 Mo n'est pas abaissé — le faire aurait changé le régime de jobs non mesurés, ce que ci(runner): 'Build Quarto site' OOM (exit 137) sur le pool auto-heberge -- le dimensionnement du parc n'a jamais echantillonne le job le plus lourd, et main est rouge depuis 13 h #15202 interdit. Seul le nombre de slots baisse (12 → 6), et 6 reste strictement supérieur aux 4 slots d'exécution : la file de gates garde de quoi absorber une rafale sans faire attendre un job derrière un slot d'exécution.
• coursia-lean (2 slots) — lean-knot.yml (+ 2 workflows d'observation). Inchangée : ni le nombre, ni le cap. Elle reste le poste dominant (58 % du budget) et c'est assumé — c'est le goulot du parc, et l'abaisser toucherait des builds Lean, pas des jobs interchangeables.
• Hors familles du superviseur : myia-po-2024-fast-guards (label coursia-fast-guards, 2 workflows) — ce runner n'est pas lancé par supervise.sh et n'est donc pas couvert par le budget ni par la slice. Signalé ici pour qu'il ne soit pas découvert plus tard : il consomme de la mémoire hors de tout plafond, et sa mise sous slice est un sujet distinct.

Le nombre 6 pour les waiters n'est pas un plancher mesuré — cette machine n'a pas d'historique d'occupation, seulement un instantané (12 waiters, 12 × busy: false au relevé). Il est choisi par la règle ci-dessus (supérieur aux slots d'exécution), et si l'occupation soutenue approche 6, c'est le budget de la machine qu'il faudra rouvrir — pas ce nombre qu'il faudra deviner à la hausse sans mesure.

Fichiers

Fichier	Nature
persist/po-2024/coursia-ci.slice	nouveau — le mur kernel (MemoryHigh=20G, MemoryMax=22G, MemorySwapMax=0)
persist/po-2024/coursia-waiters.service.d/10-sizing.conf	nouveau — 12 → 6 slots pour po-2024 seulement, par drop-in, parce que coursia-waiters.service est le fichier d'ai-01 que les deux machines exécutent (byte-identique, sha256 vérifié)
persist/coursia-runner-start.sh	budget 42 → 21, CPU 30 → 24, COURSIA_RUNNER_CGROUP_PARENT
persist/coursia-lean-start.sh	budget 42 → 21, CPU 30 → 24, memory-swap = memory, COURSIA_RUNNER_CGROUP_PARENT
persist/coursia-runner.service	start 6 → start 4
persist/README.md	table de correspondance + pourquoi po-2024/ existe
persist/coursia-ci.slice	correction d'une affirmation devenue fausse : il citait po-2024 comme LA machine sans slice

Périmètre : aucun fichier d'ai-01 n'est modifié. C'est la raison d'être du drop-in — éditer coursia-waiters.service pour descendre po-2024 descendrait ai-01 au prochain déploiement, sans que rien ne le signale.

Déploiement (fait sur l'hôte, après merge du présent commit — cf. étape 5)

Ordre obligatoire, la slice d'abord : assert_slice refuse le démarrage si la slice déclarée est introuvable ou sans io.max.

1. install de la slice + daemon-reload + start coursia-ci.slice
2. install des wrappers et unités
3. daemon-reload
4. redémarrage des trois jambes — un conteneur déjà vivant ne migre pas dans la slice : seul un cycle de conteneur l'y met. Les slots en vol partent en fin de job (ExecStop gracieux, TimeoutStopSec=900).
5. vérification : le démarrage doit afficher [slice] mur agrege ACTIF : memory.high=... memory.max=...

Le dry-run (systemd-analyze verify) et la liste exacte des fichiers/valeurs sont postés sur le dashboard CoursIA avant toute écriture, conformément à la règle UAC/dry-run du 2026-08-27.

Ce que cette PR ne fait PAS

• Elle ne tranche pas l'axe CPU (ci(infra): variance 3-4x du pool self-hosted coursia-ephemeral a code constant — gouvernance de co-residence #15574) — elle en subit la conséquence arithmétique (30 → 24) sans le décider. Le point de retour J+7 tombe aujourd'hui et reste ouvert.
• Elle ne remonte ni ne descend aucun cap unitaire : 1536 Mo docker, 512 Mo waiters, 6144 Mo lean sont inchangés.
• Elle ne met pas myia-po-2024-fast-guards sous la slice — signalé, pas traité.
• Elle ne migre pas le build Hashlife vers un runner hosted — la conséquence est nommée, le routage est un sujet distinct.

Post-déploiement (08/10, ~01:40 heure locale) — confirmations + correctif associé

Déployé sur l'hôte après dry-run publié (systemd-analyze verify + liste fichiers/valeurs sur le dashboard CoursIA). Mesures complètes postées sur jsboige/Maintenance#76 (c.6049087196).

• Composition en service : docker 4 × 1536 + waiters 6 × 512 + lean 2 × 6144 = 21 504 Mo de caps déclarés, 100 % des conteneurs avec CgroupParent=coursia-ci.slice. La jambe docker oscille 3-4 selon les jobs en vol.
• Mur vérifié au cgroup, pas au systemctl show : memory.high=21474836480, memory.max=23622320128, memory.swap.max=0, io.max=8:48 rbps=419430400 wbps=209715200 ; memory.current 5,2-7,9 GiB sous le mur ; oom_kill 0 ; pswpout gelé (swap stable à 1 069 Mo).
• Lean sans swap : Memory=MemorySwap=6442450944 sur les deux slots.
• Lignes [slice] mur agrege ACTIF au journal des trois jambes (runner 01:17:50, lean 01:18:27, waiters 01:38:11).
• Incident de restart intégralement traité et rapporté (993 s d'arrêt gracieux → superviseurs SIGKILL → 14 conteneurs orphelins tenant 18 432 Mo → refus arithmétique → récupération ordonnée docker→waiters→lean). Détail dans le commentaire Maintenance#76.

Correctif associé : f9b1958caf8 — wrapper waiters, chemin du dépôt

Le premier restart post-déploiement a exposé un défaut préexistant du dépôt : coursia-waiters-start.sh portait le défaut /mnt/d/CoursIA — correct pour ai-01, faux pour po-2024 depuis la migration du 17/09 (/mnt/d/Dev/CoursIA) : la jambe waiters refusait master.env illisible et épuisait StartLimitBurst. Le wrapper étant déployé à l'identique sur les deux sièges (les deux ExecStart pointent /usr/local/bin/coursia-waiters-start.sh), le défaut sonde désormais les deux racines documentées (persist/README.md) ; la surcharge COURSIA_REPO_DIR/COURSIA_MASTER_ENV est inchangée. Déployé et vérifié : 6 waiters dans la slice.

Découverte latérale pour ai-01 : l'épingle #16134 de la jambe waiters n'existait pas (les 12 anciens waiters dataient d'avant la garde) — geste supervise.sh pin passé. Et l'image vivante 2.337.0 (21/09) n'embarque pas la seconde barrière #16938 (wch_check_workdir appelé nu au lieu du garde if !) : l'épingle a été ramenée à la paire cohérente image pour démarrer ce soir ; déployer #16938 exige pin forward + docker build + restart roulé — signalé sur le dashboard.

Preuves

• test_supervise_guards.sh : 137 PASS / 0 FAIL après modifications (exécuté dans WSL, l'environnement cible).
• bash -n propre sur les deux wrappers modifiés.
• Encodage vérifié : UTF-8 valide, sans BOM, sans CRLF sur les 7 fichiers touchés.
• Wrappers vivants byte-identiques au dépôt avant modification (sha256 comparés : be4a9dc3…, ede4694d…, 2465a973…) — le déploiement est prévisible.
• Mesures docker stats, free -m, systemctl, API GitHub runners : firsthand le 2026-10-08 sur po-2024.

See #17322 (le 42, dont la prémisse a changé) · See #18691 (composition 6+2 du 01/10) · See #15574 (axe CPU, non traité ici) · See #15202 (règle des deux listes) · See #15091 (slice agrégée)

---

Amendement J+7 (2026-10-08) — verdict mesure, application de la regle

Le point de retour prevu par l'arbitrage CPU du 2026-10-01 (#15574 item 3, comment 5933689033) a ete joue le jour meme :

python scripts/ci/characterize_runner_variance.py --days 7
# 456 jobs lourds, fenetre majoritairement pre-#19802 (ere 6-slots / 30 vCPU)
# ratio p90/mediane par runner po-2024 :
docker-1  9,3x    docker-4  4,0x
docker-2  5,1x    docker-5 23,3x
docker-3 14,5x    docker-6 15,4x

5 runners sur 6 au-dessus du seuil 5x : la regle s'applique — passage CPU 24 -> 18 avec right-sizing. Le right-sizing est la jambe lean (2 -> 1 slots, cap unitaire 6 Go / 6 vCPU INCHANGE — on reduit un nombre de slots, jamais un cap, regle #15202). La memoire suit le meme mouvement : budget 21 -> 15, composition 4x1536 + 6x512 + 1x6144 = 15 360 Mo sur 24 032 (marge 8 672 Mo), slice MemoryHigh 14G / MemoryMax 16G (deploiement a suivre : la slice vive porte encore 20G/22G).

Parametre	Avant amendement	Apres
COURSIA_RUNNER_BUDGET_GB (3 jambes + drop-in waiters)	21	15
COURSIA_RUNNER_CPU_BUDGET (2 wrappers execution)	24	18
ExecStart lean (coursia-lean.service)	... 2	... 1
slice po-2024 MemoryHigh/MemoryMax	20G / 22G	14G / 16G
Volume chaud coursia-runner-work-lean-2	—	conservé (remettre le slot 2 = ExecStart ... 2 + restart)

Fichiers touches : coursia-runner-start.sh (blocs budget memoire + CPU), coursia-runner.service (commentaire historique), coursia-lean-start.sh (budget + CPU + cgroup-parent), coursia-lean.service (ExecStart + commentaires), po-2024/coursia-ci.slice (valeurs + arithmetique), po-2024/coursia-waiters.service.d/10-sizing.conf (21 -> 15), persist/README.md + persist/coursia-ci.slice (references croisees).

Runbook retour arriere : ExecStart ... 2 + budget 21 + slice 20G/22G sur les trois jambes, puis restart (le volume lean-2 reste chaud, la reconstruction n'est pas due).

Temoins : test_supervise_guards.sh rejoue sur le worktree apres amendement (resultat dans les checks de cette PR) ; mesure J+7 archivee j7_variance.json citee au dashboard.

🤖 Generated with Claude Code

[jsboige]

[po-2024:CoursIA] Fermeture + reouverture accidentelles (23:1xZ) : la session qui reconciliait le doublon #19806 a laisse un gh pr close 19802 silencieux dans sa commande -- erreur de composition, aucune intention. Aucun merge, aucun rebase, la branche na pas bouge : la PR est intacte (OPEN, B.0 OK au releve). Desole pour le bruit dans la timeline du dossier.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 19802
head: 4936b99
complete: true
body: read
comments-reviewed: 1
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: fa94b93c0f63b80ec33a835d9867bcd24279ce27f99fb7e9613dcedca46b5e22
diff-files: 9
diff-additions: 486
diff-deletions: 47
checks: BLOCKED
b0: clear
scope: pass
domain: pass
verdict: BLOCKED
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 19802
organ-rc: 3
[/ADJOINT PREFLIGHT]

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-ai-01:CoursIA
pr: 19802
head: 4936b99
complete: true
body: read
comments-reviewed: 3
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 7f986a5b44c72fd80cfa50b64ed42f4a8089bf14aa69061f75c37dd0be016fcd
diff-files: 9
diff-additions: 486
diff-deletions: 47
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
supersedes: 2
supersedes-why: Le dossier BLOCKED du secretariat (00:53Z) tenait sur le plancher DWELL, ecoule depuis 03:07Z ; aucun commit ni reserve depuis, seul un avis bot non bloquant.
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 19802
organ-rc: 0
[/ADJOINT PREFLIGHT]

Tiers ai-01 (perimetre CI) : le seul ajout depuis le dossier du secretariat est l'avis shebang non bloquant de github-actions ; DWELL ecoule, derive-verdict READY a la tete 4936b99, budget memoire relu au cycle 22:13Z.