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

36
Makefile
View file

@ -320,6 +320,26 @@ else
RAMDISK_OBJ =
endif
# Drop the objects when RAMROOT is toggled, in *either* direction.
#
# RAMROOT changes CFLAGS, and make cannot see that: an object compiled one way
# is happily reused the other way. The `ramroot` target already wiped on the way
# in, and nothing wiped on the way out -- so a plain `make` after `make ramroot`
# kept every RAMDISK_ROOT object and linked the 24 MB ramdisk back in. The
# result still booted, from the ramdisk, and the only outward symptom was that
# stage2 now had 25 MB to load through PIO one sector at a time. Measured:
# 25,413,120 bytes against 836,840 for the same kernel built clean.
#
# Evaluated when the Makefile is read, so the wipe happens before anything is
# compiled against the wrong setting.
RAMROOT_STATE := $(if $(RAMROOT),on,off)
RAMROOT_STAMP := $(BUILD)/ramroot.state
$(shell mkdir -p $(BUILD); \
if [ "$$(cat $(RAMROOT_STAMP) 2>/dev/null)" != "$(RAMROOT_STATE)" ]; then \
rm -rf $(BUILD)/kernel $(BUILD)/lib $(BUILD)/cmd; \
printf '%s' '$(RAMROOT_STATE)' > $(RAMROOT_STAMP); \
fi)
# -----------------------------------------------------------------------
# Top-level targets
# -----------------------------------------------------------------------
@ -856,6 +876,20 @@ $(BUILD)/fs.img: $(MKFS) $(BUILD)/sysroot.stamp
# -----------------------------------------------------------------------
# QEMU
# -----------------------------------------------------------------------
# The same thing with hardware virtualisation. Opt-in, never the default: the
# test suite's timings were established under TCG and changing the execution
# engine underneath them is a variable to introduce on purpose.
#
# Worth knowing what it does and does not buy. Measured with the guest timing
# itself, `ls /bin | wc -l` goes from 2.9s to 1.1s. Boot does *not* improve --
# it gets worse -- because stage2 loads the kernel by PIO one sector at a time,
# and under KVM every one of those port accesses is a VM exit, where under TCG
# it is cheap.
qemu-kvm: schos.img $(BUILD)/schfs.img
$(QEMU) -enable-kvm -serial mon:stdio $(QEMU_DISPLAY) -cpu host \
-hda schos.img -hdb $(BUILD)/schfs.img \
-m 1G -smp 2 -machine pc-i440fx-9.2
qemu: schos.img $(BUILD)/schfs.img
$(QEMU) -serial mon:stdio $(QEMU_DISPLAY) -cpu qemu64,+rdtscp \
-hda schos.img -hdb $(BUILD)/schfs.img \
@ -955,7 +989,7 @@ qrtest: $(QRTEST)
qrcheck: $(QRTEST)
$(PYTHON) tools/python/qrcheck.py
.PHONY: all kernel ramroot cmd ports sysroot-install qemu \
.PHONY: all kernel ramroot cmd ports sysroot-install qemu qemu-kvm \
schfs-test schfs-objtest schfs-image-test schfs-check mkschfs \
schfs-fsck crashshot qemu-schfs iso qemu-iso clean distclean \
logo qrtest qrcheck crashqr usb-ids