[FIX] imbrication : la descente a réfuté ce qu'on croyait mesuré

La doc et l'en-tête de l'algorithme affirmaient qu'au quatrième étage le noyau
invité gelait « au même octet quelles que soient les ressources ». Lancer la
descente l'a réfuté : son propre quatrième étage, à 2 vCPU, a démarré, s'est
installé, et a écrit des gigaoctets. La VM examinée à la main en avait douze.

Ce n'était donc pas un plafond d'imbrication mais un plafond de PARALLÉLISME
sous imbrication — précisément ce que l'algorithme borne, et qui cesse ainsi
d'être une supposition.

Le « même octet », par ailleurs, ne voulait rien dire de ce qu'on lui faisait
dire : 33 682 432 octets, c'est 32 Mio, la taille des fichiers d'amorçage.
Retirer de la mémoire ne le déplaçait pas parce qu'il ne dépendait pas de la
mémoire, pas parce qu'un mur absolu s'y trouvait. La conclusion — ne pas
borner la RAM — reste juste ; sa justification était fausse.

Une affirmation fausse dans la documentation est pire que pas de
documentation : elle décide à la place du lecteur. Les deux passages disent
maintenant ce qui a été mesuré, sur quoi, et ce que la descente a montré
ensuite.

--- EN ---

The documentation and the algorithm's header claimed that at the fourth level
the guest kernel froze "at the same byte whatever the resources". Running the
descent refuted it: its own fourth level, at 2 vCPU, booted, installed, and
wrote gigabytes. The VM examined by hand had twelve.

So it was not a nesting ceiling but a PARALLELISM ceiling under nesting —
exactly what the algorithm caps, which thereby stops being a guess.

The "same byte", moreover, did not mean what it was made to mean: 33,682,432
bytes is 32 MiB, the size of the boot files. Removing memory did not move it
because it did not depend on memory, not because an absolute wall sat there.
The conclusion — do not cap RAM — still holds; its justification was wrong.

A false claim in documentation is worse than no documentation: it decides in
the reader's place. Both passages now say what was measured, on what, and what
the descent showed afterwards.

Assisted-by: Claude Opus 5
(cherry picked from commit b8c53eaf104f6891703e71b540c76ffd5994a2cb)

LongTest/README.base.md

@@ -15,12 +15,22 @@ Run them from the menu — `TODO › Execute › Test › Long tests` — or dir
 
 ## deep_proxmox.py — how deep does Proxmox-in-Proxmox go?
 
-The practicable nesting depth cannot be deduced, only measured. A manual
+The practicable nesting depth cannot be deduced, only measured — and one
-measurement found, at the fourth level, a guest **36 times slower than real
+measurement is not a measurement.
-time** — 583 seconds of wall clock for 16 seconds of guest time, each ACPI
+
-line taking a second — then a guest kernel frozen at the **same byte**
+A manual look at one fourth-level VM found a guest **36 times slower than real
-whatever the resources. A number obtained once, on one machine, is not a
+time** (583 seconds of wall clock for 16 seconds of guest time, each ACPI line
-number: this script redoes it on demand and says exactly where it breaks.
+taking a second) and then a frozen kernel: identical RIP across three samples
+two minutes apart, and **not one byte written** to disk.
+
+Running this script **refuted the conclusion drawn from it**. Its own
+fourth-level VM — 2 vCPU where the manual one had 12 — booted, installed, and
+wrote gigabytes. What looked like a nesting ceiling was a *parallelism*
+ceiling under nesting. That is exactly what the algorithm caps, and this is
+how it stopped being a guess.
+
+Which is the point of the script: a number obtained once, on one machine, in
+one chain, is an anecdote.
 
 ```
 ./LongTest/deep_proxmox.py --depth 10 --dry-run   # the plan, nothing created
@@ -54,8 +64,11 @@ level. Twelve vCPU at the fourth level froze the guest kernel in early boot;
 the same two progressed. Bringing twelve processors online costs as many
 round trips through the whole stack.
 
-Memory is **not** capped: the same VM froze at the same byte with 9 GB and
+Memory is **not** capped. On that one manual VM, dropping it from 9 GB to
-with 2 GB, so trimming it would gain nothing and starve the level below.
+2 GB moved nothing — it stopped after reading the same 32 MiB, which is simply
+the size of the boot files. Memory was not the lever; the vCPU count was. And
+trimming memory would starve the level below, which needs it to host the
+next.
 
 The plan is printed **before** anything is created, and the script never
 promises a depth it knows will not fit — better to announce six levels and
@@ -75,13 +88,24 @@ directement.
 
 ## deep_proxmox.py — jusqu'à quel étage un Proxmox dans un Proxmox tient-il ?
 
-La profondeur d'imbrication praticable ne se déduit pas, elle se mesure. Une
+La profondeur d'imbrication praticable ne se déduit pas, elle se mesure — et
-mesure à la main a trouvé, au quatrième étage, un invité **36 fois plus lent
+une mesure n'est pas une mesure.
-que le temps réel** — 583 secondes d'horloge pour 16 secondes de temps
+
-invité, chaque ligne d'ACPI prenant une seconde — puis un noyau invité gelé au
+Un examen à la main d'UNE VM du quatrième étage a trouvé un invité **36 fois
-**même octet** quelles que soient les ressources. Un chiffre obtenu une fois,
+plus lent que le temps réel** (583 secondes d'horloge pour 16 secondes de
-sur une machine, n'est pas un chiffre : ce script le refait à la demande et
+temps invité, chaque ligne d'ACPI prenant une seconde), puis un noyau gelé :
-dit exactement où ça casse.
+même RIP à trois relevés deux minutes d'écart, et **pas un octet écrit** sur
+le disque.
+
+Lancer ce script a **réfuté la conclusion qu'on en avait tirée**. Sa propre VM
+du quatrième étage — 2 vCPU là où celle de la main en avait 12 — a démarré,
+s'est installée, et a écrit des gigaoctets. Ce qui ressemblait à un plafond
+d'imbrication était un plafond de *parallélisme* sous imbrication. C'est
+précisément ce que l'algorithme borne, et c'est ainsi qu'il a cessé d'être une
+supposition.
+
+D'où le script : un chiffre obtenu une fois, sur une machine, dans une chaîne,
+est une anecdote.
 
 ```
 ./LongTest/deep_proxmox.py --depth 10 --dry-run   # le plan, rien de créé
@@ -116,8 +140,11 @@ tout étage imbriqué. Douze vCPU au quatrième étage ont gelé le noyau invit
 tout début de démarrage ; les mêmes deux avançaient. Amener douze processeurs
 en ligne coûte autant d'allers-retours à travers toute la pile.
 
-La mémoire n'est **pas** bornée : la même VM gelait au même octet avec 9 Go et
+La mémoire n'est **pas** bornée. Sur cette unique VM examinée à la main, la
-avec 2 Go, donc la rogner ne gagnerait rien et priverait l'étage du dessous.
+faire passer de 9 Go à 2 Go n'a rien déplacé : elle s'arrêtait après avoir lu
+les mêmes 32 Mio, c'est-à-dire simplement la taille des fichiers d'amorçage.
+La mémoire n'était pas le levier ; le nombre de vCPU l'était. Et la rogner
+priverait l'étage du dessous, qui en a besoin pour héberger le suivant.
 
 Le plan est affiché **avant** que quoi que ce soit ne soit créé, et le script
 ne promet jamais une profondeur qu'il sait irréalisable — mieux vaut annoncer

LongTest/README.fr.md

@@ -12,13 +12,24 @@ directement.
 
 ## deep_proxmox.py — jusqu'à quel étage un Proxmox dans un Proxmox tient-il ?
 
-La profondeur d'imbrication praticable ne se déduit pas, elle se mesure. Une
+La profondeur d'imbrication praticable ne se déduit pas, elle se mesure — et
-mesure à la main a trouvé, au quatrième étage, un invité **36 fois plus lent
+une mesure n'est pas une mesure.
-que le temps réel** — 583 secondes d'horloge pour 16 secondes de temps
+
-invité, chaque ligne d'ACPI prenant une seconde — puis un noyau invité gelé au
+Un examen à la main d'UNE VM du quatrième étage a trouvé un invité **36 fois
-**même octet** quelles que soient les ressources. Un chiffre obtenu une fois,
+plus lent que le temps réel** (583 secondes d'horloge pour 16 secondes de
-sur une machine, n'est pas un chiffre : ce script le refait à la demande et
+temps invité, chaque ligne d'ACPI prenant une seconde), puis un noyau gelé :
-dit exactement où ça casse.
+même RIP à trois relevés deux minutes d'écart, et **pas un octet écrit** sur
+le disque.
+
+Lancer ce script a **réfuté la conclusion qu'on en avait tirée**. Sa propre VM
+du quatrième étage — 2 vCPU là où celle de la main en avait 12 — a démarré,
+s'est installée, et a écrit des gigaoctets. Ce qui ressemblait à un plafond
+d'imbrication était un plafond de *parallélisme* sous imbrication. C'est
+précisément ce que l'algorithme borne, et c'est ainsi qu'il a cessé d'être une
+supposition.
+
+D'où le script : un chiffre obtenu une fois, sur une machine, dans une chaîne,
+est une anecdote.
 
 ```
 ./LongTest/deep_proxmox.py --depth 10 --dry-run   # le plan, rien de créé
@@ -53,8 +64,11 @@ tout étage imbriqué. Douze vCPU au quatrième étage ont gelé le noyau invit
 tout début de démarrage ; les mêmes deux avançaient. Amener douze processeurs
 en ligne coûte autant d'allers-retours à travers toute la pile.
 
-La mémoire n'est **pas** bornée : la même VM gelait au même octet avec 9 Go et
+La mémoire n'est **pas** bornée. Sur cette unique VM examinée à la main, la
-avec 2 Go, donc la rogner ne gagnerait rien et priverait l'étage du dessous.
+faire passer de 9 Go à 2 Go n'a rien déplacé : elle s'arrêtait après avoir lu
+les mêmes 32 Mio, c'est-à-dire simplement la taille des fichiers d'amorçage.
+La mémoire n'était pas le levier ; le nombre de vCPU l'était. Et la rogner
+priverait l'étage du dessous, qui en a besoin pour héberger le suivant.
 
 Le plan est affiché **avant** que quoi que ce soit ne soit créé, et le script
 ne promet jamais une profondeur qu'il sait irréalisable — mieux vaut annoncer

LongTest/README.md

@@ -10,12 +10,22 @@ Run them from the menu — `TODO › Execute › Test › Long tests` — or dir
 
 ## deep_proxmox.py — how deep does Proxmox-in-Proxmox go?
 
-The practicable nesting depth cannot be deduced, only measured. A manual
+The practicable nesting depth cannot be deduced, only measured — and one
-measurement found, at the fourth level, a guest **36 times slower than real
+measurement is not a measurement.
-time** — 583 seconds of wall clock for 16 seconds of guest time, each ACPI
+
-line taking a second — then a guest kernel frozen at the **same byte**
+A manual look at one fourth-level VM found a guest **36 times slower than real
-whatever the resources. A number obtained once, on one machine, is not a
+time** (583 seconds of wall clock for 16 seconds of guest time, each ACPI line
-number: this script redoes it on demand and says exactly where it breaks.
+taking a second) and then a frozen kernel: identical RIP across three samples
+two minutes apart, and **not one byte written** to disk.
+
+Running this script **refuted the conclusion drawn from it**. Its own
+fourth-level VM — 2 vCPU where the manual one had 12 — booted, installed, and
+wrote gigabytes. What looked like a nesting ceiling was a *parallelism*
+ceiling under nesting. That is exactly what the algorithm caps, and this is
+how it stopped being a guess.
+
+Which is the point of the script: a number obtained once, on one machine, in
+one chain, is an anecdote.
 
 ```
 ./LongTest/deep_proxmox.py --depth 10 --dry-run   # the plan, nothing created
@@ -49,8 +59,11 @@ level. Twelve vCPU at the fourth level froze the guest kernel in early boot;
 the same two progressed. Bringing twelve processors online costs as many
 round trips through the whole stack.
 
-Memory is **not** capped: the same VM froze at the same byte with 9 GB and
+Memory is **not** capped. On that one manual VM, dropping it from 9 GB to
-with 2 GB, so trimming it would gain nothing and starve the level below.
+2 GB moved nothing — it stopped after reading the same 32 MiB, which is simply
+the size of the boot files. Memory was not the lever; the vCPU count was. And
+trimming memory would starve the level below, which needs it to host the
+next.
 
 The plan is printed **before** anything is created, and the script never
 promises a depth it knows will not fit — better to announce six levels and

script/proxmox/nesting.py

@@ -26,11 +26,16 @@ Deux nombres viennent de la même mesure, et méritent d'être dits :
   démarrage — même RIP à trois relevés, deux minutes d'écart, pas un octet lu
   de plus. Les mêmes 2 vCPU avançaient. D'où VCPU_IMBRIQUE = 2 : amener douze
   processeurs en ligne demande autant d'allers-retours à travers la pile ;
-* la même VM s'arrêtait ensuite au MÊME octet — 33 682 432 — quelles que
+* cette VM-là s'arrêtait après avoir lu 33 682 432 octets — 32 Mio, soit
-  soient les ressources, dans la réservation des tables ACPI. Ce mur-là n'est
+  simplement la taille de ses fichiers d'amorçage — et le chiffre ne bougeait
-  pas une question de taille, et aucun réglage ici ne le déplacera. La
+  pas quand on lui retirait de la mémoire. La mémoire n'était donc pas le
-  profondeur RÉELLEMENT atteignable se mesure ; ce module ne calcule que ce
+  levier, et c'est pourquoi ce module n'en borne pas.
-  qui est arithmétiquement possible.
+
+Une descente complète a ensuite RÉFUTÉ ce qu'on avait conclu de la première :
+son quatrième étage, à 2 vCPU, a démarré, s'est installé, et a écrit des
+gigaoctets. Le plafond était celui du parallélisme sous imbrication, pas celui
+de l'imbrication. La profondeur RÉELLEMENT atteignable se mesure — LongTest la
+mesure ; ce module ne calcule que ce qui est arithmétiquement possible.
 """
 
 # Ce qu'on laisse à la machine physique : elle fait tourner l'orchestrateur,
@@ -143,11 +148,13 @@ def capped_for_depth(profondeur: int, vcpu: int, ram_mo: int) -> tuple:
 
     Rend (vcpu, ram, raison). `raison` vide quand rien n'a été touché.
 
-    Seul le vCPU est borné, et la mesure le dit : la même VM au quatrième
+    Seul le vCPU est borné, et la mesure le dit : sur la VM examinée au
-    étage gelait au MÊME octet avec 9 Go et avec 2 Go — la mémoire n'est pas
+    quatrième étage, passer de 9 Go à 2 Go n'a rien déplacé — elle s'arrêtait
-    le levier. Douze vCPU, en revanche, gelaient plus tôt et plus dur que
+    après les mêmes 32 Mio, la taille de ses fichiers d'amorçage. Douze vCPU,
-    deux. La RAM passe donc telle quelle : la rogner ne gagnerait rien et
+    en revanche, gelaient là où deux avançaient, et une descente complète a
-    priverait l'étage suivant.
+    fini par franchir cet étage à 2 vCPU. La RAM passe donc telle quelle : la
+    rogner ne gagnerait rien et priverait l'étage suivant, qui en a besoin
+    pour héberger le sien.
 
     Pourquoi borner au lieu d'avertir seulement : l'écran lit la capacité de
     l'HÔTE et l'offre en entier. Sur un troisième étage à 14 cœurs et 9 Go, il