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

16
.claude/memory/schos-uefi-loader.md
View file

@ -4,7 +4,7 @@ description: "boot/uefi works under OVMF; the SCH64 entry, the GDT trap, and the
metadata:
node_type: memory
originSessionId: d4821aa9-2e49-40da-91e7-90ef9ed9997e
modified: 2026-08-09T20:03:43.364Z
modified: 2026-08-09T20:44:02.893Z
---
**`boot/uefi/` boots.** `make uefi`, `make esp`, `make qemu-uefi`. Verified
@ -61,12 +61,14 @@ raising the bound past a hole.
Result: 1018 MB in 7 regions under OVMF, 1023 MB in 2 under BIOS.
**It is also a large speedup, which was not the goal and is worth knowing.**
Measured from inside the guest (`/proc/uptime`, fresh image each boot,
alternating rounds): boot to prompt **14.8 s vs 21.2 s**, and a cold
`ls /bin | wc -l` **23.6 s vs 51.2 s** — 2.2x. Both rounds agreed within
0.3 s. So if the allocator ever looks slow again, this is the baseline to
compare against.
**A "2.2x speedup" was claimed for this change on 2026-08-09. It was wrong,
and the retraction matters more than the claim did.** The measurement sent a
command, slept a fixed 50 s on the *host*, and then read `/proc/uptime` — so it
timed the sleep, not the command, through a guest clock that drifts under load.
Correctly measured (see [[schos-bootcheck-trust]]), `ls /bin | wc -l` is **2.9 s
under TCG, 1.1 s under KVM**, and the region-based allocator has no measurable
effect on it either way. The change is still right; it simply is not a
performance change.
## UEFI reaches userspace — 2026-08-09