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

scripts/ci/docker/linux-runner/persist/README.md

@@ -30,11 +30,30 @@ n'a pas ete remplacee. Un `git pull` ne deploie pas `persist/`.
 | `po-2026/pool.sh` | **po-2026** | `/home/jesse/CoursIA-runners-p0/pool.sh` (WSL Ubuntu) | **deploye et vivant** -- superviseur du pool, **8 slots** et **borne depuis le 2026-09-22** (cf. `po-2026/README.md`) |
 | `po-2026/run-pool-po2026.sh` | **po-2026** (hote Windows) | `C:\dev\CoursIA-runners-p0\run-pool-po2026.sh` | **deploye et vivant** -- lanceur de la tache planifiee, porte la borne CPU/memoire. **Attention : ce fichier vit sous `C:\dev\...`, pas sous `D:\Dev\CoursIA-runners-p0\`** (cf. `po-2026/README.md`) |
 | `po-2026/README.md` | -- | -- | **document** : architecture, dimensionnement, piege du verrou |
+| `po-2024/coursia-ci.slice` | **po-2024** | `/etc/systemd/system/coursia-ci.slice` | **a deployer** (2026-10-08, amendement J+7 : valeurs 20G/22G -> 14G/16G, budget 21 -> 15) -- le mur kernel qui manquait a cette machine : `MemoryHigh=14G`, `MemoryMax=16G`, `MemorySwapMax=0`. Homonyme de la slice ai-01, valeurs differentes (cf. section `po-2024/`) |
+| `po-2024/coursia-waiters.service.d/10-sizing.conf` | **po-2024** | `/etc/systemd/system/coursia-waiters.service.d/10-sizing.conf` | **a deployer** (2026-10-08) -- 12 -> 6 slots waiters pour po-2024 seulement, par drop-in, parce que `coursia-waiters.service` est le fichier d'**ai-01** que les deux machines executent |
 
 Le sous-repertoire `ai-01/` existe parce que les deux machines ont des fichiers
 **homonymes et incompatibles**. Les melanger a plat, comme c'etait le cas, revient
 a laisser croire qu'il n'y en a qu'un.
 
+Le sous-repertoire `po-2024/` existe pour la meme raison que `ai-01/` : ses deux
+fichiers sont homonymes de fichiers d'autres machines, et **incompatibles** avec
+eux. `coursia-ci.slice` porte les bornes de la VM de 24 Go de po-2024, la ou la
+copie d'ai-01 borne une machine bien plus large ; les confondre ferait deployer
+16 Go de plafond dur sur une machine qui en a 24, ou l'inverse. Le drop-in
+waiters est l'autre moitie du meme probleme : l'unite `coursia-waiters.service`
+appartient a ai-01 et po-2024 l'execute **telle quelle**, donc editer l'unite
+pour descendre po-2024 descendrait aussi ai-01 -- le drop-in rend le perimetre
+explicite.
+
+Les fichiers po-2024 anterieurs (wrappers `runner-start`, `lean-start`, unites
+`runner` et `lean`) restent a la racine de `persist/` : ce sont eux qui ont
+etabli la convention « racine = po-2024 » avant que les sous-repertoires
+n'existent, et les deplacer serait du churn sans portee. Tout **nouvel** artefact
+propre a une machine dont le nom est deja pris ailleurs va dans son
+sous-repertoire.
+
 Le sous-repertoire `po-2026/` existe pour une raison differente : cette machine est
 la seule du parc dont la chaine de runners ne passe **ni par Docker ni par une unite
 systemd**. Ses fichiers ne sont homonymes d'aucun autre, mais la table ci-dessus,

scripts/ci/docker/linux-runner/persist/coursia-ci.slice

@@ -84,10 +84,27 @@
 #      Avec `COURSIA_REQUIRE_CI_SLICE=1`, son absence devient un refus de
 #      demarrer plutot qu'un avertissement.
 #
-# Sur une machine qui NE la deploie PAS (po-2024), il n'y a rien a faire :
+# Sur une machine qui NE la deploie PAS, il n'y a rien a faire :
 # `CI_CGROUP_PARENT` reste vide, `--cgroup-parent` n'est pas passe, et le
 # superviseur avertit sans refuser (cf assert_ci_slice dans supervise.sh).
 #
+# po-2024 A DEPLOYE LA SIENNE LE 2026-10-08, et l'exemple que ce paragraphe
+# citait est donc tombe. Il nommait po-2024 comme LA machine sans slice ; ce
+# n'est plus vrai, et c'est precisement ce qui a ete corrige : cette machine a
+# une VM de 24 Go et sa composition declarait 27 648 Mo de caps, payes en swap
+# (104 GiB ecrits en moins de 11 h, DriveFS et RooSync emportes avec). Sa slice
+# n'est PAS une copie de celle-ci : elle porte `MemoryHigh=14G`,
+# `MemoryMax=16G`, `MemorySwapMax=0` (amendement J+7 du 2026-10-08 ; 20G/22G
+# au premier depot) -- des valeurs calibrees sur SA VM, et
+# aucun `CPUQuota`, parce que son axe CPU a son propre arbitrage en cours. La
+# copie de reference vit sous `po-2024/coursia-ci.slice`, et les deux ne
+# doivent jamais etre confondues : deployer celle-ci sur po-2024 poserait des
+# bornes calibrees pour une autre machine.
+#
+# La valeur de ce paragraphe n'est donc pas dans l'exemple mais dans la regle :
+# une machine sans slice n'a AUCUN mur kernel derriere son budget userspace, et
+# c'est un etat a corriger, pas un etat stable.
+#
 #
 [Unit]
 Description=CoursIA CI runner containers -- aggregate budget (all families)

scripts/ci/docker/linux-runner/persist/coursia-lean-start.sh

@@ -52,28 +52,79 @@ export COURSIA_LEAN_RUNNER_NAME_PREFIX="${COURSIA_LEAN_RUNNER_NAME_PREFIX:-myia-
 export COURSIA_RUNNER_STATE_DIR="${COURSIA_RUNNER_STATE_DIR:-/var/lib/coursia-lean}"
 mkdir -p "$COURSIA_RUNNER_STATE_DIR"
 
-# MEME BUDGET QUE LES DEUX AUTRES JAMBES DE CETTE MACHINE -- 42 Go depuis
-# l'agrandissement VM du 2026-09-21 (24 032 -> 40 110 Mo, arbitrage user,
-# mission ai-01 msg-20260921T203652-qxg3en). Cette jambe est celle qui a rendu
-# l'ecart visible : ses 2 slots a 6 Go demandent 12 288 Mo, et le garde les
-# refusait tant que les 18 432 Mo des deux autres familles etaient en vol
-# (18 432 + 12 288 > 12 288) -- sous l'ancien budget 12 Go, les slots lean ne
-# DEMARRAIENT JAMAIS. Le refus etait correct ; ce qui manquait etait un budget
-# couvrant la composition complete (8x1536 + 12x1536 + 2x6144 = 43 008 Mo).
+# MEME BUDGET QUE LES DEUX AUTRES JAMBES DE CETTE MACHINE -- 15 Go depuis le
+# 2026-10-08, amendement J+7 (le 42 etait devenu faux deux fois : VM revenue
+# de 40 110 a 24 032 Mo, et son arithmetique comptait « 12x1536 waiters »
+# pour des waiters a 512 Mo -- detail complet en tete de coursia-runner-start.sh).
+#
+# CETTE JAMBE EST CELLE QUI REND LE BUDGET VISIBLE, et c'est pour ca qu'elle
+# doit le declarer : son slot a 6 Go demande 6 144 Mo a lui seul. Sous
+# un budget trop court, le garde refuse son demarrage -- ce qui est CORRECT,
+# et c'est l'incident fondateur ecrit ici : sous l'ancien budget 12 Go, les
+# slots lean ne demarraient JAMAIS tant que les autres familles etaient en vol.
+# Un budget qui ne couvre pas la composition complete ne protege rien : il
+# empeche une jambe entiere de tourner.
+#
+# L'AMENDEMENT J+7 DESCEND CETTE JAMBE DE 2 A 1 SLOT (verdict
+# characterize_runner_variance.py --days 7 du 2026-10-08 : 5 runners docker
+# sur 6 au-dessus du seuil p90/mediane 5x -- ratios 9,3 / 5,1 / 14,5 / 4,0 /
+# 23,3 / 15,4) : la regle #15574 item 3 tranche le passage CPU 24 -> 18, le
+# right-sizing etant ce slot unique (cap unitaire 6 Go / 6 vCPU INCHANGE --
+# on reduit un nombre de slots, jamais un cap). Le volume chaud
+# coursia-runner-work-lean-2 reste en place, non supprime : remettre le
+# second slot est un `ExecStart ... 2` + restart, pas une reconstruction.
+#
 # Les trois jambes doivent annoncer le meme nombre : assert_memory_budget
 # somme les familles entre elles, une divergence refuserait des slots sans
 # nommer sa cause.
-export COURSIA_RUNNER_BUDGET_GB="${COURSIA_RUNNER_BUDGET_GB:-42}"
+export COURSIA_RUNNER_BUDGET_GB="${COURSIA_RUNNER_BUDGET_GB:-15}"
+
+# AUCUN SWAP POUR LA JAMBE LEAN (2026-10-08) -- memory-swap = memory.
+# Le defaut de supervise.sh est `LEAN_MEMORY_SWAP="${COURSIA_LEAN_RUNNER_MEMORY_SWAP:-12g}"`,
+# soit 6 Go de RAM PLUS 6 Go de swap par slot. On l'aligne ici sur LEAN_MEMORY :
+# le conteneur dispose de 6 Go en tout, et d'aucune page sur disque.
+#
+# POURQUOI CE CHOIX, ALORS QUE LE COMMENTAIRE DE supervise.sh DIT LE CONTRAIRE.
+# Le bloc LEAN de supervise.sh argumente que le swap n'est pas un dogme mais un
+# curseur : « supprimer le swap ne retire pas le pic de Hashlife, il transforme
+# un build qui deborde en un exit 137 ». C'est exact, et c'est le but recherche
+# ici. Le swap d'une VM WSL est un FICHIER SUR LE DISQUE WINDOWS : chaque page
+# poussee la retarde DriveFS, puis `G:`, puis RooSync -- la chaine qui a gele
+# ai-01 quatre fois et qui a fait ecrire 104 GiB en 11 h a cette machine le
+# 2026-10-08. Un build Lean qui deborde doit mourir (exit 137, echec local,
+# retryable, un job perdu) plutot que d'emporter la coordination de la flotte.
+#
+# CONSEQUENCE NOMMEE : le build Hashlife de conway_lean depassait 16 Go a
+# froid ; a 6 Go sans swap il ne passera PAS. La reponse 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 deja, et non de
+# remonter le swap de cette machine.
+# La valeur est ecrite ici pour ce qu'elle EST, pas referencee par le nom
+# qu'elle porte dans supervise.sh : `LEAN_MEMORY` est une constante de
+# supervise.sh, elle n'existe pas dans ce wrapper -- et ce fichier tourne sous
+# `set -u`, donc `$LEAN_MEMORY` y serait une erreur de variable non definie,
+# pas un defaut silencieux. La coherence avec le cap est gardee en lisant la
+# MEME variable d'environnement que supervise.sh (COURSIA_LEAN_RUNNER_MEMORY),
+# avec le meme defaut 6g : memory-swap = memory, y compris si le cap est
+# surcharge un jour.
+export COURSIA_LEAN_RUNNER_MEMORY_SWAP="${COURSIA_LEAN_RUNNER_MEMORY:-6g}"
 
 # BUDGET CPU INTER-FAMILLES (#15574 item 3, arbitrage coordinateur du
 # 2026-10-01, comment 5933689033) -- MEME NOMBRE que coursia-runner-start.sh.
 # assert_cpu_budget somme les familles d'EXECUTION (start + lean ; les
-# waiters, oisifs, en sont exclus) et refuse le demarrage au depassement.
-# Valeur 30, pas les 24 de l'arbitrage : docker 6x3 + lean 2x6 = 30, et a 24
-# cette jambe-ci serait REFUSEE au demarrage -- le verrou « service failed »
-# que l'arbitrage citait precisement pour l'ecarter. Le garde est inerte a 0
-# ou absent (etat anterieur de la machine).
-export COURSIA_RUNNER_CPU_BUDGET="${COURSIA_RUNNER_CPU_BUDGET:-30}"
+# waiters, oisifs, en sont excludes) et refuse le demarrage au depassement.
+# Valeur 18 depuis l'amendement J+7 du 2026-10-08 : docker 4x3 + lean 1x6 =
+# 18. C'etait 24 avec 2 slots lean (4x3 + 2x6), 30 avec 6 slots docker ;
+# le budget a suivi la composition, il ne l'a pas precedee. Le garde est
+# inerte a 0 ou absent (etat anterieur de la machine).
+export COURSIA_RUNNER_CPU_BUDGET="${COURSIA_RUNNER_CPU_BUDGET:-18}"
+
+# PARENT CGROUP -- meme valeur que coursia-runner-start.sh, meme raison : les
+# trois familles doivent entrer dans la MEME slice pour que ses limites
+# s'appliquent a leur somme. C'est la jambe lean qui rendait l'absence
+# de mur visible (12 288 Mo de caps pour ses 2 slots d'alors, contre une VM
+# de 24 032) ; elle est desormais sous MemorySwapMax=0 comme le reste de la CI.
+export COURSIA_RUNNER_CGROUP_PARENT="coursia-ci.slice"
 
 cd "$REPO_DIR" || exit 1
 

scripts/ci/docker/linux-runner/persist/coursia-lean.service

@@ -16,8 +16,13 @@
 # (check-run 102437210604), et deux jobs lean de PR sont restes en queue
 # toute l'apres-midi (diagnostic po-2027, 14:23Z).
 #
-# N slots porte par l'argument ExecStart (po-2024 -> 2, l'effectif
-# d'avant la chute : volumes _work chauds coursia-runner-work-lean-{1,2}).
+# N slots porte par l'argument ExecStart (po-2024 -> 1 depuis l'amendement
+# J+7 du 2026-10-08 : verdict characterize_runner_variance.py --days 7,
+# 5 runners docker sur 6 au-dessus du seuil p90/mediane 5x, la regle
+# #15574 item 3 tranche le passage CPU 24 -> 18 avec right-sizing lean
+# 2 -> 1 -- cap unitaire 6 Go / 6 vCPU INCHANGE. Le volume chaud
+# coursia-runner-work-lean-2 reste en place, non supprime : remettre le
+# second slot est un `ExecStart ... 2` + restart, pas une reconstruction).
 [Unit]
 Description=CoursIA Lean runners pool (coursia-lean slots)
 # Wants= et non Requires= (meme raison que coursia-runner.service, #14347) :
@@ -32,7 +37,7 @@ StartLimitBurst=5
 
 [Service]
 Type=simple
-ExecStart=/usr/local/bin/coursia-lean-start.sh 2
+ExecStart=/usr/local/bin/coursia-lean-start.sh 1
 ExecStop=/usr/local/bin/coursia-lean-start.sh stop
 Restart=always
 RestartSec=30
@@ -44,8 +49,10 @@ TimeoutStopSec=900
 
 # Nice=10 gouverne le CPU ; l'I/O du pool cede sous contention comme les
 # autres (IOWeight=50), cf #15091. Les caps durs par conteneur (cpus=6,
-# memory=8g, memory-swap=24g) sont portes par supervise.sh lui-meme via
-# LEAN_CPUS/LEAN_MEMORY/LEAN_MEMORY_SWAP -- l'unite ne les re-encode pas.
+# memory=6g, memory-swap=6g -- le swap lean est aligne sur la memoire depuis
+# le 2026-10-08, detail en tete de coursia-lean-start.sh) sont portes par
+# supervise.sh lui-meme via LEAN_CPUS/LEAN_MEMORY/LEAN_MEMORY_SWAP -- l'unite
+# ne les re-encode pas.
 IOAccounting=yes
 IOWeight=50
 

scripts/ci/docker/linux-runner/persist/coursia-runner-start.sh

@@ -39,23 +39,67 @@ export COURSIA_RUNNER_TOOLCACHE_VOLUME="coursia-runner-toolcache"
 # rend auditable : la valeur effective vit dans un fichier que l'operateur ouvre,
 # pas dans un defaut de shell que personne ne lit.
 #
-# 42 POUR po-2024 (arbitrage user 2026-09-21, mission ai-01
-# msg-20260921T203652-qxg3en) : la VM WSL est passee de 24 032 a 40 110 Mo
-# (.wslconfig memory=40GB). Le nombre est le PLAFOND D'ADMISSION, egal a la
-# somme des caps declares des trois jambes (8x1536 docker + 12x1536 waiters +
-# 2x6144 lean = 43 008 Mo) : sous l'ancien 12 Go, la garde refusait des slots
-# sains -- les 2 slots lean ne demarraient JAMAIS tant que les autres familles
-# etaient en vol. Les vrais murs restent les caps par conteneur (docker
-# --memory) et le plafond vmmem de la VM ; l'hote garde sa moitie au-dela de
-# la VM, comme `MemoryHigh` de coursia-ci.slice sur les machines qui deployent
-# la slice (po-2024 ne la deploie pas : ici le budget n'a pas de mur kernel
-# derriere lui).
+# 15 POUR po-2024 (2026-10-08, amendement J+7) -- LE 42 EST TOMBE, ET IL
+# ETAIT DEVENU FAUX DEUX FOIS. Il avait ete pose le 2026-09-21 pour une VM de
+# 40 110 Mo (.wslconfig memory=40GB, arbitrage user, mission
+# msg-20260921T203652-qxg3en). Depuis, la VM est revenue a 24 Go : `.wslconfig
+# memory=24GB` et `free -m` (24 032 Mo) le mesurent tous les deux. Et son
+# arithmetique de 43 008 Mo n'a jamais ete la vraie : elle comptait
+# « 12x1536 waiters » alors que WAITER_MEMORY vaut 512m (supervise.sh l.180).
+# La composition REELLE etait 6x1536 + 12x512 + 2x6144 = 27 648 Mo de caps sur
+# une VM de 24 032 -- une somme de caps superieure a la RAM, qui se paie en
+# swap. Mesure du jour : 6 285 Mo de swap consommes, 104 GiB ecrits depuis le
+# boot en moins de 11 h, DriveFS et la coordination de la flotte en premier.
+#
+# LA COMPOSITION QUE CE BUDGET DECLARE, ET CE QU'ELLE LAISSE :
+#     4 slots docker x 1536 Mo = 6 144 Mo   (cap unitaire INCHANGE)
+#     6 waiters      x  512 Mo = 3 072 Mo   (cap unitaire INCHANGE)
+#     1 slot lean    x 6144 Mo = 6 144 Mo   (2 -> 1, verdict J+7 ci-dessous)
+#     --------------------------------------
+#     total CAPS                15 360 Mo   sur 24 032 -> marge 8 672 Mo
+#
+# ON REDUIT DES NOMBRES DE SLOTS, JAMAIS DES CAPS. Mesure du 2026-10-08 :
+# 3 des 6 conteneurs docker touchaient leur cap de 1536 Mo a 99 %, donc le cap
+# unitaire n'est pas en trop -- c'est la CONCURRENCE qui ne tenait pas. Un job
+# lourd garde exactement le meme regime memoire ; il attend son tour au lieu de
+# pousser la machine dans le swap. La regle #15202 de persist/README.md interdit
+# d'abaisser un cap sans nommer les jobs non mesures qu'il couvre, et cette PR
+# ne l'abaisse nulle part.
+#
+# LE BUDGET RESTE UN PLAFOND D'ADMISSION, PAS UN MUR. Il refuse de DEMARRER un
+# slot au-dela de 15 Go ; il ne borne pas ce qu'un slot deja lance consomme.
+# Le mur kernel est desormais pose sur cette machine : voir
+# persist/po-2024/coursia-ci.slice (MemoryHigh=14G, MemoryMax=16G,
+# MemorySwapMax=0), et COURSIA_RUNNER_CGROUP_PARENT plus bas, qui y fait entrer
+# les conteneurs.
 #
 # LES TROIS JAMBES DOIVENT ANNONCER LE MEME NOMBRE. `assert_memory_budget`
 # somme les conteneurs label `coursia-ci=1` de TOUTES les familles : deux jambes
 # qui divergeraient refuseraient leurs slots l'une contre l'autre, et le message
 # d'erreur ne nommerait pas la divergence -- il parlerait de memoire en vol.
-export COURSIA_RUNNER_BUDGET_GB=42
+# Les trois jambes de po-2024 portent 15 : celle-ci, la jambe lean, et la jambe
+# waiters (par le drop-in persist/po-2024/coursia-waiters.service.d/10-sizing.conf,
+# dont le wrapper appartient a ai-01 et ne declare aucun budget).
+export COURSIA_RUNNER_BUDGET_GB=15
+
+# PARENT CGROUP -- LE MUR KERNEL QUI MANQUAIT A CETTE MACHINE (2026-10-08).
+# supervise.sh pose `--cgroup-parent=$COURSIA_RUNNER_CGROUP_PARENT` sur chaque
+# conteneur quand cette variable est declaree : les conteneurs des trois
+# familles entrent alors dans la meme slice, et les limites du parent
+# s'appliquent a leur SOMME. C'est le seul endroit ou un budget inter-familles
+# existe -- un plafond par conteneur ne peut pas borner une flotte.
+#
+# Le nom est `coursia-ci.slice` (pas le chemin imbrique complet) parce que ce
+# daemon est docker-ce, pilote systemd : systemd y resout une slice sur son nom,
+# donc `coursia-ci.slice` vit sous `coursia.slice` et le chemin cgroup reel est
+# /sys/fs/cgroup/coursia.slice/coursia-ci.slice/. La forme litterale
+# « coursia.slice/coursia-ci.slice » serait necessaire pour un daemon cgroupfs
+# (Docker Desktop), qui ne resout rien -- ce n'est pas le cas ici.
+#
+# `assert_slice` REFUSE le demarrage si la slice declaree est introuvable ou
+# sans `io.max`. La slice doit donc etre posee AVANT de redemarrer ces unites :
+# c'est l'ordre documente en tete de persist/po-2024/coursia-ci.slice.
+export COURSIA_RUNNER_CGROUP_PARENT="coursia-ci.slice"
 
 # BUDGET CPU INTER-FAMILLES (#15574 item 3, arbitrage coordinateur du
 # 2026-10-01, comment 5933689033). supervise.sh le lit (assert_cpu_budget) :
@@ -78,17 +122,36 @@ export COURSIA_RUNNER_BUDGET_GB=42
 #   - le service passe de start 8 a start 6 (conforme a l'arbitrage) dans
 #     coursia-runner.service : la reduction de 24 a 18 vCPU docker vit la.
 #
-# Point de retour mesure J+7 (prevu par l'arbitrage) : rejeu de
-# characterize_runner_variance.py sur la meme fenetre ; si le ratio
-# p90/mediane des jobs lourds ne descend pas sous 5x, passage a 16 avec
-# right-sizing -- qui devra alors aussi redimensionner la jambe lean, sinon
-# elle seule depasse le budget.
+# CE BLOC PASSE DE 30 A 24 PUIS A 18 LE 2026-10-08, ET LES DEUX FOIS CE SONT
+# DES CONSEQUENCES, PAS DES ARBITRAGES. Le raisonnement initial tenait pour
+# une composition docker 6 : 6x3 + 2x6 = 30, et 24 aurait refuse la jambe
+# lean. Le budget memoire de cette PR descend les slots docker a 4, donc la
+# somme redevenait 4x3 + 2x6 = 24. L'AMENDEMENT J+7 (verdict mesure, le
+# point de retour prevu par l'arbitrage) descend la jambe lean a 1 slot :
+# 4x3 + 1x6 = 18. Ce qui a change est la composition, pas la doctrine : le
+# budget reste egal a la somme des caps des familles d'execution, jamais un
+# chiffre choisi pour lui-meme.
+#
+# VERDICT J+7 (2026-10-08, characterize_runner_variance.py --days 7, 456 jobs
+# lourds) : le ratio p90/mediane des jobs lourds par runner po-2024 est
+# docker-1 9,3x · docker-2 5,1x · docker-3 14,5x · docker-4 4,0x ·
+# docker-5 23,3x · docker-6 15,4x -- CINQ RUNNERS SUR SIX AU-DESSUS DU SEUIL
+# 5x que l'arbitrage avait fixe. La regle s'applique donc : passage a 18 avec
+# right-sizing, le right-sizing etant la jambe lean (2 -> 1 slots, son cap
+# unitaire de 6 Go et 6 vCPU reste INCHANGE). Noter que la fenetre 7 j couvre
+# majoritairement l'ere 6-slots/30 vCPU d'avant le budget memoire -- rapporte
+# tel quel, la regle ne conditionnait pas sa decision a la composition.
+#
+# La sur-souscription CPU reelle de la machine baisse au passage : elle etait
+# de 30 vCPU declares pour 16 disponibles (1,875x) avec 6 slots docker ; 24
+# pour 16 (1,5x) avec 4 docker + 2 lean ; elle est de 18 pour 16 (1,125x)
+# avec 4 docker + 1 lean.
 #
 # LES DEUX JAMBES D'EXECUTION PORTENT LE MEME NOMBRE (runner et lean) : le
 # garde fire au demarrage de chacune et somme l'autre. La jambe waiters n'en
 # declare pas : depuis l'exclusion, un demarrage de waiters n'ajoute rien a
 # la somme -- la declarer serait du decor.
-export COURSIA_RUNNER_CPU_BUDGET=30
+export COURSIA_RUNNER_CPU_BUDGET=18
 
 # #15095 : echec immediat si le demon du socket epingle ne repond pas --
 # AVANT tout demarrage de slot et tout fetch de registration token (gh).