BOUNCE was 2048 while the comment directly above it said "one page at a
time", and the buffer it sizes is a single kalloc() -- so half of every
bounce buffer went unused and every read did twice the work it needed to.
The chunk size is not a copy-size tuning knob. Each trip through the loop
takes the volume sleeplock and builds a fresh B-tree cursor to find the
extent for that offset, so it really sets how many tree descents happen
per byte read. An 834 KB file took 417 of them; it now takes 209.
Measured in the guest, bracketed inside one command line so nothing
depends on host timing: reading 834 KB goes from 1.73s to 0.90s under
TCG, cold and warm alike. Warm equalling cold is itself the tell -- the
cost was never the disk, it was the per-chunk work, which is why KVM was
6.4x faster on the same read while caching made no difference at all.
This does not fix `ls`, and the numbers say why: 2.80s -> 2.65s cold.
loaduvm already reads a page at a time, so exec was never the bottleneck
there. At 241 entries in 2.65s that is ~11ms per file, spent in the
per-entry lookup path rather than in reading anything.
schfs-check passes; bootcheck 108 [ok].
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An x86-64 operating system built from xv6, now largely rewritten: SMP,
a copy-on-write root filesystem (SchFS), PCI/USB/virtio drivers, a TTF
rasteriser, and a Linux-numbered syscall ABI.
No history before this point -- the tree was never under version control.
This commit exists so the rename that follows has something to undo to.
