nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

memory: the e820 work, and why the extended suite flaps

Browse source 
Records the measured effect of the region-based allocator (2.2x on a cold
ls, 6 s off the boot), the two pre-existing UEFI blockers found while
verifying it, and the three confounds that each produced a confident
wrong answer about guest speed in one session.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-08-09 21:05:34 +02:00
commit c55e65de5e
2 changed files with 73 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

31
.claude/memory/schos-bootcheck-trust.md
View file

@ -4,7 +4,7 @@ description: bootcheck silently stopped running and five of seven modes asserted
metadata:
node_type: memory
originSessionId: 9d8a2aef-bcf0-47a0-96c6-f706efab4a95
modified: 2026-08-09T13:55:00.546Z
modified: 2026-08-09T19:05:06.942Z
---
**A green run is only green if you counted the checks.** On 2026-08-09 the
@ -45,3 +45,32 @@ of success. Both of these produced clean-looking runs while testing nothing.
**How to apply:** after any change to the harness itself, verify the check
count, not just the absence of FAIL.
## The extended suite is timing-fragile on the Fedora laptop
`Wait-Prompt` waits a fixed **20 s**; measured on this machine with the guest's
own `/proc/uptime`, a cold `ls /bin | wc -l` takes **23 s** and took **51 s**
before the e820 work. When it overruns, the script sleeps 2 s and types anyway,
so the next command lands in a busy shell and the transcript interleaves — and
the check that fails is then some *later* one whose output is no longer
adjacent to its command. `yes writes through a pipe` failed this way while
`y`/`y` were plainly correct in the transcript. Treat a single FAIL in
`-Fb -Tty -Usb -Sock -Evdev -Ps` as suspect until the transcript is read.
**Leaked QEMU made this worse and is now fixed** (commit 4e0478c): the
`finally` cannot run when the *script* is killed, so QEMU outlived it and, under
TCG, taxed every later run. Each run now records its pid and reaps the previous
one's orphan.
## Measuring anything about guest speed
Do not use host wall clock, and do not compare runs made minutes apart. Three
confounds each produced a confident wrong answer in one session:
1. **Stray QEMU** pinning a core (see above).
2. **`build/schfs.img` ages** — it accumulates writes across boots. Delete and
`make build/schfs.img` before every timed boot.
3. **Ordering / host drift** — alternate the variants and run each twice.
Time it from inside: `cat /proc/uptime` either side of the command. The guest's
tick does not care what the host is doing. See [[schunix-verify-by-driving-shell]].