boot: unitload and memory-policy go, their answers stay beside the decisions

.github/workflows/lab.yml

@@ -35,9 +35,7 @@ on:
           - boot:initcalls
           - boot:userspace
           - boot:systemd
-          - boot:unitload
           - boot:ssh-load
-          - boot:memory-policy
           - boot:page-cache
           - boot:firmware
           - boot:firmware-stages

boot/Taskfile.yml

@@ -48,16 +48,6 @@ tasks:
     cmds:
       - SPIN_PAGE_CACHE=1 go test ./boot/ -run '^TestPageCache$' -count=1 -v -timeout 60m
 
-  memory-policy:
-    desc: >-
-      A process that takes memory until something stops it, in a login session of a 1 GiB
-      guest: logins while it grows, how long until it is gone and what killed it, with the image
-      as built and without MGLRU's min_ttl_ms. Needs /dev/kvm and a built release; no sudo.
-      REPS= boots per variant.
-    deps: [':tools']
-    cmds:
-      - SPIN_MEMORY_POLICY=1 go test ./boot/ -run '^TestMemoryPolicy$' -count=1 -v -timeout 90m
-
   logind:
     desc: >-
       Check first SSH login, reconnect, user services and logout in a disposable guest.
@@ -88,17 +78,6 @@ tasks:
     cmds:
       - SPIN_INITCALL_PROBE=1 go test ./boot/ -run TestKernelInitcalls -count=1 -v -timeout 30m
 
-  unitload:
-    desc: >-
-      What systemd spends loading units and building the initial transaction, from its own
-      instrumentation: `systemd --test` reports it at LOG_INFO where a real boot logs it at
-      LOG_DEBUG. Many runs inside one boot, so there is no boot-to-boot noise, and it
-      measures the generators by masking two that cannot do anything on this machine. Needs
-      KVM, a built release and sudo.
-    deps: [':tools']
-    cmds:
-      - SPIN_UNITLOAD_PROBE=1 go test ./boot/ -run TestUnitLoadCost -count=1 -v -timeout 15m
-
   userspace:
     desc: >-
       systemd's own account of the boot: its kernel/userspace split, `blame` and the

boot/testdata/ssh-load.sh

@@ -82,47 +82,6 @@ tmp_full() {
     rm -f /tmp/sshload-fill
 }
 
-# The logins while a process in spin's session takes memory until something stops it, then how
-# long that took, who stopped it and whether the machine answers afterwards. Last in a run,
-# because the guest may not come out of it.
-grow() {
-    label=$1 hog=$2
-    $SSH "nohup sh -c '$hog' >/dev/null 2>&1 &" </dev/null
-    start=$(date +%s%N)
-    out= gone=
-    while [ $(( ($(date +%s%N) - start) / 1000000000 )) -lt 90 ]; do
-        out="$out $(login)"
-        if ! pgrep -u spin -x tail >/dev/null; then
-            gone=$(( ($(date +%s%N) - start) / 1000000 ))
-            break
-        fi
-    done
-    echo "SSHLOAD $label$out"
-    after=$(login)
-    echo "SSHLOADEXHAUST $label gone_after_ms=${gone:-never} login_after=$after" \
-        "kernel_oom_kills=$(journalctl -k -b --no-pager | grep -c 'Out of memory: Killed')" \
-        "min_ttl_ms=$(cat /sys/kernel/mm/lru_gen/min_ttl_ms 2>/dev/null || echo none)" \
-        "swap_total=$(awk '/^SwapTotal:/ { print int($2 / 1024) }' /proc/meminfo)MiB" \
-        "victims=$(journalctl -k -b --no-pager | sed -n 's/.*Killed process [0-9]* (\([^)]*\)).*/\1/p' | sort | uniq -c | tr -s ' ' | tr '\n' ',')"
-    pkill -KILL -u spin || true
-    sleep 2
-}
-
-# tail keeping a line that never ends, from a pipe: `tail /dev/zero` seeks to the end of the
-# device, keeps nothing and measured nothing (2026-09-28). At full speed the kernel runs out of
-# anything to reclaim within a second or two and kills it.
-exhaust() {
-    grow exhaust "cat /dev/zero | tail"
-}
-
-# The case that hangs a machine: memory taken slowly, ~80 MB/s, while the session reads its
-# libraries over and over, as a build reads headers. Reclaim keeps finding page cache to evict
-# and the reader keeps faulting it back, so the kernel is never out of options and the OOM
-# killer is never called: the old LRU's thrash.
-exhaust_slow() {
-    grow exhaust-slow "(while :; do cat /usr/lib/x86_64-linux-gnu/*.so* >/dev/null 2>&1; done) & while :; do head -c 8M /dev/zero; sleep 0.1; done | tail"
-}
-
 for c in ${SSHLOAD_CASES:-idle cpu_service cpu_session tmp_full}; do
     case $c in
     idle) measure idle ;;

image/mkosi.extra/usr/local/lib/spin-base/optimize-systemd.sh

@@ -167,7 +167,7 @@ DISABLE_GENERATORS=(
     # runs on a machine systemd itself logs as not booted in EFI mode.
     #
     # Worth 1.0 ms of the 26 ms systemd spends loading units and building the initial
-    # transaction — measured 2026-09-26 with `task boot:unitload`, which asks systemd for that
+    # transaction — measured 2026-09-26 with the unitload probe (ad05544), which asks systemd for that
     # number through `systemd --test` rather than reading it out of a debug-logged boot. The
     # same number read from a debug boot is 212 ms, and that difference is the logging.
     systemd-tpm2-generator

image/mkosi.extra/usr/local/lib/spin-base/rootfs/etc/tmpfiles.d/lru-gen.conf

@@ -4,7 +4,7 @@
 # page cache still counts as reclaimable, and the OOM killer never comes: the VM is up and
 # answers nothing.
 #
-# Measured 2026-09-28 with boot/memory_policy_test.go, 1 GiB, 2 vCPUs, memory taken at ~80 MB/s
+# Measured 2026-09-28 with the memory-policy probe (337c08d), 1 GiB, 2 vCPUs, memory taken at ~80 MB/s
 # while a session re-read its libraries, 3 boots: the worst SSH login was 611-1785 ms without
 # this and 105-106 ms with it, and the process was killed after 11.2 s instead of 13.8. 1000 ms
 # is the value the kernel's documentation suggests; the kernel needs CONFIG_LRU_GEN, which

kernel/Dockerfile

@@ -204,7 +204,7 @@ RUN <<EOT
     #                           cache still counts as reclaimable. Measured 2026-09-28, 1 GiB guest,
     #                           memory taken slowly while libraries are re-read, 3 boots: the worst
     #                           SSH login 611-1785 ms without it, 105-106 ms with it, and the
-    #                           process killed ~20% sooner (boot/memory_policy_test.go).
+    #                           process killed ~20% sooner (the memory-policy probe, 337c08d).
     #
     #                           Not ZRAM: in the same test it gave the runaway process more room
     #                           and it was killed later (20 s against 14), with the worst login