[Japabu]

Issues only, no code. The 2026-10-28 scoreboard compared ToyOS at 069cbbeb8 against each bench's Linux as installed: 4 boots against 5 runs, interleaved, every ToyOS readback judged EXIT=0 (evidence, branch scoreboard-2026-10-28). It found rows ToyOS loses with no owning record. This PR records the ones listed below, each with the scoreboard's figures, an owner and an exit. Every table is generated from the comparison files.

record	the gap	owner
a-small-message-round-trip-over-a-native-connection-costs-twice-linuxs-on-the-t14	ipc.reqrep.8 2.04x and reqrep_handle.8 1.21x on the T14	native IPC
a-two-thread-ping-pong-costs-toyos-up-to-twice-linuxs-on-the-t14	pingpong.futex.same_cpu 2.01x, cross_core 1.37x; pingpong.pipe.cross_core 1.83x, same_cpu 1.37x on the T14	the futex and wake path, and kernel/src/pipe.rs
a-tmpfs-metadata-call-costs-toyos-up-to-six-times-linuxs	eight fs.mem rows, 1.7x–6.5x on the T14; open_close 2.1x and rename 1.4x on the AMD (the listing is a-listing-still-scans-the-whole-mount's)	whatever serves /tmp through storage track step 9; the exit is the migrated /tmp
spawning-a-process-costs-toyos-up-to-four-times-linuxs-on-the-t14	spawn up to 3.7x and thread creation 1.1–1.2x on the T14; the all-CPU build 1.7x (T14) and 2.3x (AMD)	process creation, and the scheduler for the build
a-small-memcpy-on-the-amd-bench-runs-at-as-little-as-six-tenths-of-linuxs	mem.memcpy.64 at 0.61 of Linux's, 256 0.90, 262144 0.70 on the AMD; 16 KiB and 64 MiB on the T14	userland's copy (sdk/libc)
toyos-has-no-loopback-so-osbench-net-measures-nothing	all five net.* rows unsupported on both benches, and a 127/8 connect misreported as ERR_NOT_CONNECTED	netstack
std-yield-now-on-toyos-yields-nothing	time.yield unsupported: no yield syscall	the scheduler's syscall surface and ToyOS's std

Existing records take rows they already own, with the scoreboard's figures:

• a-tlb-shootdown-reaches-only-the-cpus-that-ran-the-space, whose exit already names the T14's munmap figures: mem.munmap_part.4k 1.22x and mem.munmap_touched_remote.4k 1.32x.
• user-memory-hot-paths-are-slower-than-2-mib-pages: mem.bw.copy, where Linux gave 131,072 KiB of huge pages and ToyOS none.
• a-short-memset-on-x86-64-costs-a-rep-stosb-start-up now points at the memcpy measurement instead of calling it unmeasured.

Still without a record here: persist.seq_read_cached and fs.disk.seq_write.*. The disk agent already working on the clean fsync, sequential write and cache is on them.

The T14 durable-write record, toyos-durable-writes-on-the-t14s-nvme-run-six-times-slower-in-some-boots, replaces …-took-1-to-6-ms-across-two-boots. It covers all five boots: 2 of 5 ran persist six times slower throughout, and a third turned slow partway. Nothing in the logs tells them apart. Linux read 0.83–1.25 ms over the scoreboard's runs, and the exit is every durable persist row. #1097 carried this rewrite on its branch after it merged, so it lands here.

The AMD's Linux chose the TSC in runs 1–3 and the HPET in runs 4–5, at 1.2 µs a timestamp. Each record reads its rows per run rather than hedging on the clocksource. ipc.reqrep.8 on the AMD stays unresolved because ToyOS's and Linux's runs overlap (p = 0.063). The scoreboard text claimed every median was a TSC run's and gave 0.81–1.20 ms for Linux's durable writes. Both are corrected in an append-only evidence commit, 2d212f56d.

Checks: cargo run -- --ci host, exit 0, 105 steps green, at 2cb987b3a (rebased onto f40791833); the later review rounds changed only record text. Markdown only. Every issues/… citation in the changed records resolves on the rebased tree.

🤖 Generated with Claude Code

[Japabu]

Review of #1105 at b006c29 (base e4bdb0a)

The PR changes only Markdown: +267/−33 across 10 issues/ files. I checked every figure against the scoreboard's t14-compare.md and amd-compare.md. The published scoreboard-pub tables are byte-identical to them, and its INDEX.md matches evidence commit d6713ef. I also checked the per-run p50 columns and their clocksource order (AMD Linux runs 1–3 tsc, 4–5 hpet) and read the code each record names. Main has moved to a5b330f since the base. None of the files this PR touches changed there.

Architectural assessment

Filing one record per uncovered gap, each with an owner and an exit, is the right shape, and almost every table cell matches the scoreboard. Three problems recur across records:

• The AMD's HPET runs are offered as an explanation in places where the per-run data contradicts it.
• Two records overlap existing issues without citing them.
• One record points work at kernel code that the owner-approved storage track deletes.

Blockers

1. issues/a-tmpfs-metadata-call-costs-toyos-up-to-six-times-linuxs.md:30-35: the owner and exit target code the approved design deletes.

   • issues/the-kernel-is-small-interrupts-post-and-threads-wait.md step 9, the file half, is under the owner's 2026-09-25 ruling. Its exit is that tmpfs.rs, fs_rename.rs, file_cache.rs and vfs.rs are gone, with /tmp leaving the kernel per session (owner ruling 2026-10-03).
   • This record assigns the gap to "the kernel's tmpfs and VFS (kernel/src/tmpfs.rs, kernel/src/vfs.rs)", and its exit can be met by tuning those files. That is effort on a superseded path.
   • After step 9, an fs.mem call is a file-server request. issues/a-file-server-request-costs-three-to-twelve-times-a-kernel-file-call.md already prices that at 3–12x a kernel call.
   • Required: tie the record to that migration. Owner: whatever serves /tmp, through step 9. Exit: the rows as served after the move. The record should also state that the move makes the gap larger unless the file-server round trip shrinks.
   • Coverage: the record also drops four T14 rows that resolve at p = 0.016 and that the scoreboard assigns to the same per-call cost. They are fs.mem.tree.100 2.74x, create_write_unlink 2.72x, write_4k_at 1.98x and read_4k_at 1.72x. No other record owns them. Include them or name their owner.

2. The HPET explanation contradicts the per-run data in three records.

   • a-small-message-round-trip-…:19-21
     • "whose 1.2 µs a timestamp is in every Linux sample" is false. Only runs 4–5 used the HPET.
     • The AMD's ipc.reqrep.8 Linux spread is not the HPET's. The TSC runs read 7,684, 14,983 and 15,719 ns; the HPET runs read 13,829 and 10,551. The median (13,829) is an HPET run, which also contradicts the scoreboard's caveat that "their medians are the TSC runs'".
     • On the AMD, reqrep_handle.8 resolves ToyOS better (0.42x). ToyOS's worst run (9,959) beats every TSC Linux run (20,238–21,099).
   • spawning-a-process-…:29-30
     • "The AMD's spawns and thread creations read better for ToyOS" is false for proc.posix_spawn_wait.std in this record's own table: 504,838 against 327,668, 1.54x worse, unresolved.
     • spawn_wait.large, posix_spawn_wait.tiny and all thread.spawn_join* rows resolve better, and they stay better against the TSC runs alone. For example, large on Linux's TSC runs reads 259–273 µs against ToyOS's 155–186 µs.
     • A 1.2 µs timestamp is under 1% of a 50–900 µs spawn, so it cannot be the caveat here.
     • The wide Linux spreads in these rows are bimodal within the TSC runs. In posix_spawn_wait.std, run 2 (TSC) reads 740,403. In process.spawn_wait, run 5 (HPET) is the fast outlier at 346,343.
   • a-futex-ping-pong-…:19-21
     • The HPET sentence suggests doubt that the data does not support. Linux's TSC runs alone read 6,141–6,248 ns (same_cpu) and 9,648–9,864 ns (cross_core). ToyOS's medians of 5,015 and 5,662 ns are below both ranges.

   Required: state what the TSC-only runs show in each of these records, and keep the HPET explanation only where it fits. It does fit in the tmpfs record, where Linux's TSC runs are 2.9 µs and its HPET runs 4.3 µs on open_close.

3. issues/toyos-durable-writes-…-in-some-boots.md:21-23: the Linux figures do not match the scoreboard.

   • The scoreboard's five T14 Linux runs read write_4k_fsync at 0.99–1.04 ms and append_4k_fsync at 0.83–1.25 ms (1,245,311 ns in run 4). The record's 0.81–1.20 comes from the deleted record's two validations.
   • The five Linux runs are interleaved with four of these boots, not five. The c8f3fbf boot had its own validation's Linux runs.
   • The scoreboard's own prose (INDEX.md:184) has the same error, which is the evidence owner's to correct.

4. Same record, :33-35: the exit does not test the defect the record describes.

   • It checks only persist.write_4k_fsync. The record's own r3 boot turned slow after that row: write 1.08 ms, then create_fsync_unlink 7.10 ms and seq_write_fsync 167 MB/s.
   • Such a boot would pass this exit. The exit must cover every durable persist row of each boot, or require that the slow mode be explained.

5. issues/toyos-has-no-loopback-…:10-14: "how netstack's TCP answers a connect to 127/8 is unread" is false. The code answers it:

   • Connect. shard::connect (system/netstack/shard/src/lib.rs:487-488) calls ip.route first. route refuses 127/8 as a martian (ip/src/route.rs, is_martian → Counter::RouteInvalidDestination). The route check comes before RouteLocalDestination, which covers the host's own addresses.
   • Connect answer. serve.rs's connect_refused maps ConnectError::Route(_) to ERR_NOT_CONNECTED. Its comment describes that word as one that "clears when a lease lands". For 127/8 it never clears, so a localhost connect is misreported as a missing lease.
   • Listen. shard::listen refuses 127.0.0.1 as NotLocal, answered ERR_INVALID_INPUT. So TcpListener::bind("127.0.0.1:0"), the first call a loopback program makes, fails.
   • Unit tests. The TCP crate's s_hs_035_connect_needs_a_unicast_remote holds LOCALHOST, and UDP's s_udp_us_003 refuses a bind to 127.0.0.1.

   The record's UDP sentence (unusable, SendLoopback, SendToSelf) is verified. Replace "unread" with these facts. Nothing material is left unread. What is unmeasured is only the metal row, because osbench skips it on ToyOS.

6. issues/a-small-memcpy-…:22-25 overlaps existing records and misstates what is known.

   • The code's strategy is a single line: copy_forward is one rep movsb at every length (sdk/libc/src/arch/x86_64.rs:24-34). "Its strategy … a rep movsb start-up or otherwise, is not yet read" should state that.
   • issues/a-short-memset-on-x86-64-costs-a-rep-stosb-start-up.md has the same owner (sdk/libc) and the same hypothesis. Its exit says "memcpy's rep movsb may share the cost; it is unmeasured", and this record is that measurement.
   • issues/kernel-forward-copies-and-fills-are-one-rep-movsb-or-stosb-on-every-cpu.md already records, with a citation, that Zen 2 lacks ERMS.
   • Required: cite both records, and update the memset record's "unmeasured" clause, since this change directly affects it.
   • The title/slug "runs at up to six tenths of Linux's" says the opposite of the data, which ranges from 0.61 to 0.90. It should read "as little as".

7. issues/spawning-a-process-…:27-29, 35-36 overlaps an existing record, and its size claim reaches beyond its rows.

   • issues/user-memory-hot-paths-are-slower-than-2-mib-pages.md, "Spawn", already records the mechanism large exercises. A spawn from a /tmp file snapshots it, taking "a reference to each resident page of the file under the file cache's lock, and 16 bytes a page, at the spawn". large is a 32 MiB /tmp file, so 8,192 pages. issues/process-memory-in-4-kib-pages-still-copies-each-programs-text.md stage 5 owns shared text.
   • "What a spawn spends on the program's size … is unmeasured" must cite both and say what this record adds.
   • "The cost grows with the program's size" holds only for the ratio. ToyOS's 32 MiB program costs 202 µs, under half the osbench binary's 452 µs.
   • The same-mechanism control is omitted: proc.spawn_wait.tiny (std Command, as large is) reads 1.01x unresolved on the T14. Quoting posix_spawn tiny's 1.28x instead mixes mechanisms. Show the Command pair, tiny 1.01x against large 3.68x, which is the cleaner evidence.

8. issues/a-futex-ping-pong-…:21-23, 26: the pipe ping-pong rows are cited but not owned.

   • pingpong.pipe.cross_core (1.83x) and same_cpu (1.37x) resolve on the T14. The scoreboard marks them unrecorded, apart from their listing in no-published-run….
   • This record calls them "the same T14 shape", but its title and exit cover only pingpong.futex.*, so they remain unowned.
   • Either widen the record to two-thread ping-pong, or name their owner. kernel: a pipe keeps its bytes in 4 KiB frames it takes as it fills #1074 has since changed the pipe on main (issues/a-64-kib-pipe-write-is-two-percent-below-the-two-mebibyte-ring.md reads pingpong.pipe.* lower on its head), so the current-state figure is owed either way.

For the orchestrator (PR description and evidence)

• "It found rows ToyOS loses with no owning record. Each now has one" is not true after this PR. These resolved losses still have no owner:

  • pingpong.pipe.*
  • the four fs.mem rows above
  • mem.munmap_part.4k (1.22x)
  • mem.munmap_touched_remote.4k (1.32x; no-published-run only lists it)
  • persist.seq_read_cached (T14 1.54x, AMD 2.28x)
  • fs.disk.seq_write.* (T14 4.57x; AMD 3.20x and 2.31x)
  • mem.bw.copy (1.05x on the T14, 1.02x on the AMD)

  Some of these may belong to agents already in flight. Narrow the claim.

• The scoreboard's prose has two errors: "Their medians are the TSC runs'" (false for ipc.reqrep.8) and "0.81 to 1.20 ms". Both disagree with its own tables.

• Host CI: logs/ci-gaps-1.log reads 105 step(s), all green, EXIT=0. For a Markdown-only change a consistency review is sufficient, and no OS build is owed.

Suggestions

• The scoreboard sentence is pasted into seven files as one unwrapped line of about 240 characters. Wrap it.
• std-yield-now…:20: "of the caller's priority". The scheduler has bands (kernel/pure/sched/job_sched.rs, Band), not priorities. Say "band", or leave the semantics to the scheduler design.
• Futex record: cite the scheduler design's S3 pair-wake records (issues/a-wake-whose-waker-parks-next-is-forwarded-to-an-idle-cpu.md, issues/an-ordinary-wake-posted-on-its-own-cpu-waits-for-that-cpus-next-pass.md) as related owners.
• Memcpy record: its exit covers mem.memcpy.*, so name the T14's resolved losses too: 16 KiB at 1.09x and 64 MiB at 1.05x.
• Unrelated, not this PR's: tests/guest/osbench/src/net.rs's header cites RouteLocalDestination for 127/8, but 127/8 is refused earlier as RouteInvalidDestination.

Verified as stated

• Every table cell in all eight records, except the durable record's Linux range.
• The resolve claims; each quoted resolution is at p = 2/126.
• Owner paths exist: kernel/src/sched/futex.rs, tmpfs.rs, vfs.rs, process.rs, elf/, sdk/libc/src/spawn.rs, sdk/std/sys/thread.rs (where yield_now is spin_loop), sdk/libc/src/memory.rs.
• The kernel's scheduler::yield_now exists and no syscall exposes it.
• git diff c8f3fbfb0 069cbbeb8 touches none of system/nvme, system/diskserver, system/fileserver, lib/bcachefs.
• Nothing cites the deleted slug, and the no-published-run pointer is correct.
• The yield and loopback records duplicate no existing issue.

SEND BACK

[Japabu]

Review r1 response (head 2cb987b3a, rebased onto f40791833):

1. tmpfs: the exit is the migrated /tmp (storage track step 9). The owner is whatever serves /tmp through it. The record carries all eight fs.mem rows, the four additional T14 rows included, and says the move makes the gap larger unless the file server's round trip shrinks.
2. HPET: the ipc, spawn and ping-pong records now read the AMD's Linux per run (TSC in runs 1–3, HPET in 4–5) and no longer hedge.
   • reqrep.8 on the AMD is unresolved, and its median is an HPET run's.
   • reqrep_handle.8: ToyOS's slowest run beats every TSC run.
   • The ping-pong rows and the spawn large row stay better against the TSC runs alone.
3. Durable writes: each Linux set's range is given (the scoreboard's runs: write 0.99–1.04, append 0.83–1.25, create 0.94–0.98 ms). The exit is every durable persist row in every boot.
4. Loopback: the record states the code's behaviour:
   • TCP connect checks the route first.
   • connect_refused maps the refusal to ERR_NOT_CONNECTED. That misreport is part of the defect and of its exit.
   • The listen is refused as NotLocal and answered ERR_INVALID_INPUT.
   • UDP returns SendLoopback and SendToSelf.
   • The record cites the two unit tests.
5. memcpy: renamed to …-at-as-little-as-six-tenths-…. It cites the ERMS and memset records and names the T14's 16 KiB and 64 MiB losses. The memset record's "unmeasured" clause now points at it.
6. Spawn:
   • The record cites hot-paths "Spawn" and process-memory stage 5, and says what it adds.
   • The size claim is gone.
   • The Command pair is the control: tiny 1.01x unresolved against large 3.68x.
7. Futex: widened to a-two-thread-ping-pong-…, with the pipe rows. It cites the pipe record for kernel: a pipe keeps its bytes in 4 KiB frames it takes as it fills #1074's change and the two pair-wake records.
8. PR body: now lists exactly what is recorded. Ownership of the remaining rows:
   • munmap rows → a-tlb-shootdown-…, whose exit already names them. The figures are added there.
   • mem.bw.copy → user-memory-hot-paths-… (Linux had 128 MiB of huge pages, ToyOS none).
   • persist.seq_read_cached and fs.disk.seq_write.* → the disk agent already on clean fsync, sequential write and cache.
   • Scoreboard text: corrected append-only in evidence 2d212f56d2ce976c5006e2c8e1ba9bc933be9cdd.

Suggestions taken: the scoreboard line is wrapped, "band" replaces "priority", the pair-wake citations are in, and so are the memcpy T14 losses. The net.rs header's RouteLocalDestination is unrelated to this PR and is left for the netstack owner.
Host CI at 2cb987b: exit 0, 105 steps green.

[Japabu]

Review r2 of #1105 at 2cb987b (base f407918)

Focused round. For each r1 blocker and taken suggestion, I checked the changed text against t14-compare.md and amd-compare.md. That includes every new cell: the four added fs.mem rows, the pingpong.pipe.* rows, proc.spawn_wait.tiny, memcpy.16384 and 67108864, the munmap rows and mem.bw.copy. I checked the c8f3fbf validation's Linux runs against evidence/r3/t14/compare.md, and the huge_pages=131072KiB field in the scoreboard's linux-1/run.txt. Evidence commit 2d212f56 is a single append-only child of d6713ef, and it corrects both prose errors. Host CI, ci-host-1105-r1b.log: 105 steps green, exit=0.

r1 blockers

1. tmpfs: resolved.
   • The exit is now the migrated /tmp, and the owner is step 9's server.
   • All eight rows are present, and the AMD verdicts (wins tree.100, create_write_unlink and write_4k_at; three unresolved) match.
2. HPET: resolved.
   • Every TSC-only claim checks out: reqrep_handle.8 (≤9,959 against 20,238–21,099), the AMD spawn and thread rows against TSC runs 1–3, and all four ping-pong rows. The pipe TSC runs are 7,564–7,739 and 11,121–19,809, both above ToyOS's.
3. Durable-write Linux range: resolved. Both run sets' ranges match their compare files.
4. Durable-write exit: resolved. It now covers every durable row for the whole of each boot.
5. Loopback: resolved.
   • The connect, listen and UDP paths are stated as the code has them.
   • The ERR_NOT_CONNECTED misreport is part of the defect and of its exit.
6. memcpy: resolved in the record itself. It has the new slug, cites the ERMS and memset records, and names the T14's 16 KiB and 64 MiB losses. The memset record's edit has a new problem; see new blocker B.
7. Spawn: overlap and control resolved. The hot-paths "Spawn" bullet and stage 5 are cited, and the Command pair is shown. The replacement sentence overreaches; see new blocker A.
8. Pipe ping-pong: resolved. The record is widened, kernel/src/pipe.rs owns its rows, and kernel: a pipe keeps its bytes in 4 KiB frames it takes as it fills #1074's change is noted.

The taken suggestions are in: the boilerplate is wrapped, "band" replaces "priority", the pair-wake records are cited, and the T14 memcpy losses are named. Nothing cites the old slugs (took-1-to-6-ms, runs-at-up-to, a-futex-ping-pong).

New blockers

A. issues/spawning-a-process-costs-toyos-up-to-four-times-linuxs-on-the-t14.md:40-43 claims more than its rows show.

• "So what costs ToyOS on that bench is what large adds, its 32 MiB in /tmp (8,192 pages), not the spawn itself."
• The record's own table contradicts "not the spawn itself". proc.posix_spawn_wait.tiny loses 1.28x, resolved (55,722 against 43,698 ns), and the osbench binary loses 2.53–2.66x without any /tmp payload.
• The Command pair shows only that, under Command, the cost is in what large adds.
• Scope the sentence to that pair and drop "not the spawn itself".

B. issues/a-short-memset-on-x86-64-costs-a-rep-stosb-start-up.md:27 states a cause the evidence does not establish.

• "memcpy's rep movsb shares it on the AMD bench" turns r1's "may share the cost; it is unmeasured" into a fact.
• The 0.61 is ToyOS's rep movsb against musl's memcpy. Nothing isolates the start-up as its cause, such as a store-loop control like the memset record's own.
• The memcpy record itself says only that "this row is that record's memcpy measurement". Keep the memset record to the same strength, for example: "may share it: mem.memcpy.64 reads 0.61 of Linux's on the AMD bench (…)".

Suggestions

• a-two-thread-ping-pong-…:30-31: "So the T14's gap is no clocksource's" does not follow from AMD data. The T14's Linux timed every run through the TSC, so say that, or drop the sentence.
• a-tmpfs-metadata-call-…:33-36: "There the HPET does fit" reads as a reply to the review. "There the HPET explains Linux's spread: …" says the same. There is also a stray double blank line before "On the T14".
• Loopback record: s_hs_035 holds the TCP crate's own is_host check, which a 127/8 connect never reaches because the route refuses it first. The test of the live path is s_ip_rte_006_invalid_and_local_destinations (system/netstack/ip/tests/addr.rs, 127.0.0.1 → RouteInvalidDestination). Cite that one.
• memcpy record: memcpy_sweep also asks for huge pages. The T14's 64 MiB loss (0.95) equals mem.bw.copy's 0.95 under the same difference, where Linux had 131,072 KiB of huge pages and ToyOS none. Worth a clause.

PR body (orchestrator)

• "ipc.reqrep.8 on the AMD stays unresolved, since its median is an HPET run's" gives a false cause. The row is unresolved because the runs overlap (p = 0.063). Which run is the median does not decide that. The record states it correctly.
• The rest of the body matches the branch.

SEND BACK: two one-sentence fixes (A and B).

[Japabu]

Orchestrator: r2's blockers A and B and the four suggestions checked against 2cb987b..f2e72a5, issue text only. The spawn sentence is limited to the Command pair, memset reads "may share it", and the loopback test is the route's s_ip_rte_006. The body's ipc.reqrep.8 cause is now run overlap. Landing.