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

Rebuild when RAMROOT is toggled, and add an opt-in KVM target

Browse source 
`make ramroot` wiped the objects on the way in, and nothing wiped on the
way out. So a plain `make` afterwards kept every RAMDISK_ROOT object and
linked the 24 MB ramdisk back into a kernel that no longer used it: 25 MB
where a clean build is 836 KB. It still booted -- from the ramdisk -- and
the only outward symptom was stage2 having thirty times as much to load
through PIO, one sector at a time. That is the "booting got slower"
report this came from.

A stamp file records which setting the objects were built with, and the
tree is dropped when it changes in either direction.

qemu-kvm is opt-in and the default stays TCG, because the suite's timings
were established there. Measured with the guest timing itself,
`ls /bin | wc -l` goes 2.9s -> 1.1s. Boot does not improve and gets
slightly worse: every PIO port access in stage2 is a VM exit under KVM.

Retracts a claim from earlier today. The "2.2x speedup" attributed to the
region-based allocator was a measurement artifact -- the probe sent a
command, slept a fixed 50s on the host, then read /proc/uptime, so it
timed the sleep rather than the command, through a guest clock that drifts
under load. Bracketing the command inside one guest command line shows no
measurable difference. The e820 change is still correct; it is simply not
a performance change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Nexoniarz 2026-08-09 22:46:00 +02:00
commit 7b2d4037a4
3 changed files with 69 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

28
.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-09T19:17:56.770Z
modified: 2026-08-09T20:44:14.569Z
---
**A green run is only green if you counted the checks.** On 2026-08-09 the
@ -83,5 +83,27 @@ confounds each produced a confident wrong answer in one session:
`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]].
Time it from inside — **and bracket the command in a single guest command line**:
```sh
cat /proc/uptime; ls /bin | wc -l; cat /proc/uptime
```
Sending the command, sleeping a fixed interval on the host, then asking for
uptime **measures the host's sleep, not the command**. That produced a confident
and completely fictional "2.2x speedup" for the e820 work: the two readings were
50 s apart because the host slept 50 s, and the arm that looked faster only had
a guest clock lagging under load. One command line, two readings, no host timing
in the loop.
4. **The guest clock drifts under TCG.** Missed timer ticks mean `/proc/uptime`
undercounts during heavy load, so it is trustworthy for bracketing a short
command and not for comparing long intervals across runs.
Baselines, measured correctly 2026-08-09 with an 836 KB kernel:
`ls /bin | wc -l` **2.9 s TCG / 1.1 s KVM**; boot to `schinit: ready` ~3.7 s TCG.
`make qemu-kvm` is the opt-in KVM target. **KVM does not speed up boot** and
slightly slows it: stage2 loads the kernel by PIO one sector at a time, and each
port access is a VM exit.
See [[schunix-verify-by-driving-shell]].