issues: the speed track's stages stand on the vendors' documents and the literature, and report their figures

[Japabu]

The ruling

The owner's answers to round 1 of #885 (#885 (comment)): where the manufacturers or the published state of the art back a design, it is followed and its bench numbers are reported and never block it; a design nothing published covers is reviewed on its merits, and a speed claim decides only where speed is the design's only purpose. His answer on the metal ceiling (#885 (comment)) keeps a timing past twice its machine's record red on every design; no line here touches a row's record or ceiling.

His direction during round 4, as the orchestrator posted it (#887 (comment)): ToyOS does not follow Linux, cites it nowhere in the tree as an authority, and reads another implementation's source only clean-room (#902). The authority for a design, a value or an oracle is the vendor's documentation and the published literature; a comparison against another OS lives in the evidence. The orchestrator's rulings on round 5 (#887 (comment), with #887 (comment) on the AMD per-CPU half) settle what round 4's left open. No Linux source, commit or capture is cited.

This branch touches only issues/: the track, which it takes up, and six of its stages.

What changed, per stage

The track (toyos-uses-what-modern-hardware-offers-for-speed). A backed stage follows and cites its backing and reports its figure, and a slowdown is filed as a defect carrying both figures; a stage nothing published covers is judged on its merits, its figure deciding only where speed is its only purpose. Its "Unexplained" items state ToyOS's own readings and the measurement each needs next; the comparisons against Ubuntu they carried moved to the evidence: https://github.com/ToyOSOrg/evidence/blob/606ae8c698bb34d09dc8ac22e67ec47011a67023/ubuntu-comparisons.md. The T14's clock item takes as its target Intel's rated frequencies for the T14's i5-1135G7, from Intel's specification of the part: Max Turbo Frequency 4.20 GHz (single core), base 2.40 GHz at the 28 W configurable TDP-up and 900 MHz at the 12 W TDP-down. Its 2.67 GHz reading is above that base and 1.53 GHz short of that turbo; the multi-core turbo limit bit it logs names a per-core-count ceiling that specification does not give. The C0-time and cycles-per-MB item (6.09 ms and 16.20 Mcyc per MB at IPC 0.94) has no published figure to stand on, so it left the list for the evidence: https://github.com/ToyOSOrg/evidence/blob/dfd53ecc2a6bdc2ebef524cf511910fd18059119/readings-without-a-target.md.

TSC deadline. The SDM defines the mode (§13.5.4.1) and recommends it over the count nowhere; AMD has none (APM §E.3.2, and the AMD bench's PPR 55922 rev. 3.06, CPUID.01H:ECX[24] reserved). Intel's specification update for the T14's processor, 631123-034 (UP3, 000806C1h), lists no TSC, TSC-deadline or APIC-timer erratum. Speed is its only purpose, so the T14's reading decides. The twin runs 11 times per arm; a run's figure is the median lateness of its 1 ms timers, an arm's the median of its 11 with their spread, lowest to highest; the deadline is kept only where its median is the lower and the spreads do not overlap, and overlapping spreads keep the count. The twin is deleted once it has answered. Whether the T14 enumerates the mode is ToyOS's own read: the exit gains a boot line printing CPUID.01H:ECX, cited once a T14 boot carries it.

The busy wake. The 7-spinner arm keeps Lozi et al. (EuroSys 2016 §3.3) and its 100 µs bound, and says it does not take the paper's power-policy condition: a wake goes to an idle core in whatever state it waits, so once deeper C-states land the row's p99 also holds that core's exit, and the row names the states its idle CPUs entered. The 8-spinner arm stands on EEVDF (Stoica et al., RTSS 1996, the algorithm of TR-95-22) with a wake's q the protected slice, and is blocked on #874's PROTECTED_RUN_NS, which is not on main.

MWAIT idle. Backed on Intel by SDM §11.10.4 and §11.10.6.4, and Intel's alone: the AMD bench keeps hlt and the kick, and its half is the orchestrator's once that bench's _CST is read; the exit takes no doorbell on AMD. The Goldmont-only verdict table is gone. A 2020+ Intel CPU whose specification update names a MONITOR or MWAIT erratum keeps the kick; the T14's (631123-034) lists none, and the Core Ultra 200V specification update is recorded as unread. The exit reads it, and where it or another 2020+ Intel update names such an erratum, the verdict, a pure function of CPUID's vendor, family and model, and its host test come back with that row. The T14's MONITOR/MWAIT enumeration comes from the same boot line as the timer's.

FSGSBASE. Stands on Intel's 767615: context switch and process-trace system calls keep the bases apart from the selectors, and ring transitions are insensitive to the GS base. ToyOS meets the first two by the exit's arms and has no system call that reads or writes another thread's registers. The oracle is the vector-2 arm on the T14.

Per-CPU lines. Intel's Rule 17 (248966-051 §11.4.5) backs it on the T14. On the AMD bench it stands on ToyOS's rule that per-CPU data goes on lines of its own, resting on the line AMD documents: 8 quadwords by PPR 55922 rev. 3.06 CPUID_Fn00000001_EBX[15:8], and 64 bytes by 55723 rev. 3.00 §2.6.1.

APST. Follows the NVMe Base Specification 2.1 with no table of drives; a drive that misbehaves is a defect measured on the bench and filed.

Every quote is in sources.md, with each document's URL or provenance and SHA-256, Intel's i5-1135G7 specification page included: https://github.com/ToyOSOrg/evidence/blob/dfd53ecc2a6bdc2ebef524cf511910fd18059119/sources.md. It quotes no Linux.

Round 5's review (#887 (comment))

• BLOCKER 1, MWAIT on AMD (ruling 1): the FFH reading and the _CST ground are gone; the stage is Intel's, the AMD bench keeps hlt and the kick, and its half is the orchestrator's once the _CST is read.
• BLOCKER 2, the carve-out (ruling 2): the Goldmont table goes; the 200V update is recorded as unread, and the exit reads it and brings the verdict and host test back with any 2020+ erratum row.
• BLOCKER 3, per-CPU lines on AMD (ruling 3): stated as 6135132762 gives it, citing PPR CPUID_Fn00000001_EBX[15:8] and 55723 §2.6.1; "documents the cost" is gone from the issue and the body.
• NOTE 1 (ruling 4): no Linux capture is cited for the T14's CPU facts; both exits gain the CPUID.01H:ECX boot line.
• NOTE 2 (ruling 5): "measures better" is named, as above.
• NOTE 3 (ruling 6): the Ubuntu comparisons are in the evidence; the track states ToyOS's own readings.
• NOTE 4 (ruling 7): the 7-spinner arm does not take Lozi's power-policy condition, and says what that puts in the 100 µs row.
• NOTE 5 (ruling 7): the 8-spinner arm and its exit say they are blocked on A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874.
• NOTE 6 (ruling 2): the table is deleted.
• NOTE 7 (ruling 3): this body no longer says 55723 gives a cost.

Round 6's review (#887 (comment))

• NOTE 1, per the orchestrator's ruling: the clock item states Intel's rated frequencies for the i5-1135G7 as its target; the cycles-per-MB item leaves "Unexplained" for the evidence.

Merges of main

9b41c8e06 merges #890, #876 and #883; 10dd91393 merges #902, #897 and #873; d1fb0ff6e takes #900; round 6 found origin/main unmoved at b805e6154, so it has no merge. None touches a file this branch changes. #873 deletes page-global-is-a-decision-nobody-has-made.md, which no file here cites. Earlier, ce43d7bd2 took #871's deletion of every-syscall-saves-the-fp-state-and-every-preemption-disable-is-locked.md, whose four hunks here were all met by #871.

Gates

• cargo run -- --ci host at 72def236f276a247bfab48ab0770624fa5e80a5f: EXIT=0, "Host: 76 step(s), all green". Log: https://github.com/ToyOSOrg/evidence/blob/dfd53ecc2a6bdc2ebef524cf511910fd18059119/ci-host.log (the home directory written as ~).
• No guest test reaches this change: it touches only issues/. No production code changes, so no design round, negative control or oracle.

Unsure

• The 7-spinner arm's choice not to take Lozi's power-policy condition is mine, on the arm's purpose (the wake's latency); the orchestrator may rule the other way, in which case the 100 µs row holds only while idle cores stay shallow.
• The clock target is a single-core rating. Intel's specification gives 4.20 GHz as the most one core reaches and no all-core figure; the item says the reading falls short of it and that the multi-core ceiling is not published, not that 4.20 GHz is reachable under that load.
• TR-95-22 itself was not fetched (citeseerx redirects to the offline archive); the quotes are RTSS 1996's.
• The twin carries no clock control (round 3 found the old one's retake unbounded); that is the twin's to fix before it runs.
• Lozi et al.'s title names Linux. It is cited as published literature for the 7-spinner arm.
• Within one protected slice: a wake just after the spinner's dispatch waits the whole 1 ms plus the pass; whether the row allows A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's hop is the row's to set.
• diskserver-drives-nvme-apst.md still says "blockd" and "the blockd step" of the small-kernel track, which names the program diskserver; outside this round's findings, left as it stands.
• The C-states exit (Design: idle CPUs enter the deep idle states the firmware declares #870's file) does not catch its own "always the deepest state" mutation, and still takes its states and oracle from Linux; that file is Design: idle CPUs enter the deep idle states the firmware declares #870's.

Collisions

• Design: idle CPUs enter the deep idle states the firmware declares #870 keeps the kick beside MWAIT for the C-states; the MWAIT stage here wakes by the store alone on every Intel CPU no 2020+ erratum names, and leaves the AMD bench on hlt.
• The busy-wake issue cites PROTECTED_RUN_NS by A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's link and is blocked on it.

🤖 Generated with Claude Code

https://claude.ai/code/session_015xhaydXCVRNscoccHYFUWy

[Japabu]

Round 1, head f1ee8dd945c588585a892b90945663296763b7ce.

Net lines (git diff --shortstat origin/main...f1ee8dd94): 8 files, +90 −127, all under issues/. Production 0, tests 0. git merge-tree --write-tree origin/main f1ee8dd94 exits 0.

Evidence: cargo run -- --ci host passes at this head. The body records EXIT=0. The linked ci-host.log at evidence de7e8151 is 10122 lines, and its last statement is [ci] Host: 76 step(s), all green. Its first stamp, 13:55:41 (build/printer.rs stamps UTC), comes 24 s after the head's commit at 13:55:17Z, and the evidence commit's message names f1ee8dd945c5…. The log has no EXIT= line of its own. No guest test reaches a change to issues/ alone.

Sources: I fetched each file and hashed it against sources.md. The SDM 325462-093 (a4a62e6a…), the optimization manual 248966-051 (284783f5…), Lozi et al. (c0d99ee0…) and the APM 24593 rev. 3.42 (0829b862…) all match. Every quoted SDM sentence is in the extracted text: §7.6, §11.10.4, §11.10.5, §11.10.6.4, §13.5.4.1 and §16.4. The SDM's contents list §6.6 as "Privilege Level Checking When Accessing Data Segments" and §7.6 as "Program or Task Restart". §11.10.6.4's Example 11-27 is a C1 handler that runs MONITOR on the work queue. §11.4.5's step 1 names "the integer value of CPUID.01H:EBX[15:8]" as the false-sharing threshold; sources.md does not quote that step. The SDM's TSC-deadline text recommends nothing: its one "should" is about WRMSR not serialising. The FSGSBASE page carries "ID 767615" and the three quoted sentences. The APM's text did not extract here, so only its hash is checked.

Asked by the brief

• The 2× ceiling. The track's "never blocks it" (toyos-uses-…:22) is about "its figure", which lines 17–20 define as the comparison program's median. That median is a committed fixture, and timings::ceiling never reads it. No changed line touches a metal row's record or its ceiling, so the guard the owner kept stands.
• The busy-wake 100 µs p99 (a-wake-to-a-busy-cpu-…:47-49) is a test that the stage works, not a gain gate. It sets no arm against another and decides no design's life. It bounds the defect's own symptom, a whole quantum's wait (≤10.49 ms), at about a hundredth of it, and sits about 40 times above the sleeping-target p99 (≤2.30 / ≤2.56 µs). As a metal timing row, reviewer.md's Tests makes it a test. For the 8-thread arm, see NOTE 3.
• The C-states lateness (idle-cpus-enter-the-c-states-cst-names.md:14-16) is also a test, not a gain gate. Its allowance is the exit latency the firmware itself declares, an oracle outside ToyOS, so a red says the idle path cost more than the hardware declares. It cannot turn the mutation its own exit names red, though. The allowance is the chosen state's latency, so "always the deepest state" earns the deepest state's allowance and stays inside it, and the idle minute's energy only falls. Design: idle CPUs enter the deep idle states the firmware declares #870's design catches that mutation through its tolerance and audio arms, not through this bound. That file is Design: idle CPUs enter the deep idle states the firmware declares #870's to fix, since Design: idle CPUs enter the deep idle states the firmware declares #870 takes it up. See NOTE 6.

Collisions with open pull requests (not findings)

• User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871 (1eeca8742) changes no file this branch changes. It plans to delete every-syscall-saves-… "in the round that merges main", which meets this branch's hunks as a modify/delete. That merge accounts for the citations added at :15-18 and :28. Its §5 kill (getpid ≤ 0.75 × base) and guard (scout_wake rounds within 5 %) are bench verdicts on a design this branch records as SDM-backed. Both passed, so nothing flips. The exit left here still asks for "the lock saving split by site, posted", and User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871's Unsure says that split was counted from the code, not measured.
• A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874 (d5165c28a) changes no file this branch changes. Its row wake_onto_busy reds at ≥ 1000 µs, ten times the bound this exit keeps. It also leaves the 8-thread arm to Design: the scheduler places by the machine's cache tree, orders fair work by EEVDF and reserves real time, in stages #872's S4, so it cannot close the issue. The metal judgement sent it back on K3, and its K2 and K3 (rounds within 5 % of base, p99 within a bucket) are bench verdicts on a design this branch records as backed. Under the track as this branch leaves it, they report and do not block.
• x86-64 kernel leaves are global under a declared CR4.PGE, and only a kernel-half change drops them #873 (7ea05913b) deletes page-global-is-a-decision-nobody-has-made.md. Its only citation, the track's "Global pages" bullet, is deleted here, so the two do not conflict in text. Its body still says "The design's kill condition decides it" (AMD k = 4, head p50 ≤ 0.98 × base). That contradicts the track as left here and the owner's x86-64 kernel leaves are global under a declared CR4.PGE, and only a kernel-half change drops them #873 ruling.
• Design: idle CPUs enter the deep idle states the firmware declares #870 (design, one empty commit) has kill lines on a design that ACPI's _CST/_LPI back: K2 (≤ 2.2 W) and K3 (no regression). It calls the doorbell "killed in comment 6119443198" and keeps the IPI ("this is not the killed doorbell design"). This branch revives the doorbell stage with a "no IPI" exit, and it deletes the one sentence that ordered the two MWAIT entries. The two designs now meet on one monitor and give opposite answers on the kick.

BLOCKER

• issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md:21-23, :51-55 — the twin and its decision are deleted, and the exit only reads the split, so the stage's speed figure decides nothing — The owner made a figure non-deciding in two cases only: a design that its manufacturers or the published state of the art back, and a design nothing published covers whose only purpose is not speed. On the record, this stage is neither.

  • Its one new citation describes the mode and recommends nothing. The body's Unsure says so, and §13.5.4.1's text agrees.
  • The issue names no purpose but speed: the re-arm's 11.7–12.1 % of a pass (:39) and the boot's 10 ms spin (:19-21).
  • The body's non-speed merits ("one write, an absolute deadline and no second timebase to calibrate") remove nothing. The track has a CPU without a feature run the plain path (toyos-uses-…:9-10). AMD's APM Vol. 2, which this branch read, documents no TSC-deadline mode (sources.md). So the count and its calibration stay beside the deadline.

  As the record stands, this is either the owner's exception, a design whose only purpose is speed and whose figure may decide, or a case he never ruled on. The branch rules it the other way. Fix: record in the issue a purpose besides speed and why it holds while the count stays; or keep a reading that decides the stage, as his exception allows; or put to him a design the manufacturers document but do not recommend, and write in his answer. First read AMD's CPUID reference for Fn0000_0001_ECX[24] (APM Vol. 3, Appendix E), which says whether the count stays.

NOTE

1. issues/toyos-uses-what-modern-hardware-offers-for-speed.md:21 — "cites what its hardware's manufacturers document" — The owner ruled on what the manufacturers back, and A design follows what its hardware's manufacturers or the published state of the art back, and a bench verdict never blocks it #885's round 2 changed the prompts from "document" to "back" for this reason. A stage that cites only documentation, as the timer's now does in the same form as the backed stages, reads as backed. Write "back".
2. issues/a-wake-to-a-busy-cpu-waits-for-its-next-pass-and-no-idle-cpu-can-take-it.md:41-45 — the invariant is cited from the paper's abstract — The paper excuses that invariant's short-term breach "when a thread is created or becomes unblocked" (p. 2, quoted in sources.md itself). Its checker treats a breach as legal unless it outlasts M = 100 ms (§4.1), and every wait here is ≤ 10.49 ms. What backs this stage is §3.3, the Overload-on-Wakeup bug ("a thread that was asleep may wake up on an overloaded core while other cores in the system are idle"), and that section's fix, which wakes the thread on an idle core. Cite §3.3.
3. issues/a-wake-to-a-busy-cpu-…:47-49 — the 8-thread arm — With 8 CPU-bound threads on 8 CPUs, no core idles, so nothing the issue cites reaches this arm. Under the track's rule it is a stage nothing published covers whose only purpose is latency, which is where the owner lets the figure decide, and the 100 µs bound is what decides it. Say so in the issue, so the track's rule reads this arm the way the exit holds it.
4. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:15-21, issues/per-cpu-scheduler-and-pmm-state-shares-lines-every-cpu-writes.md:43-47 — Intel alone backs two stages that run on an AMD bench, and AMD's documents for either were not read. The body's Unsure says APM Vol. 2 is silent and the family 17h guide was not fetched. The owner's x86-64 kernel leaves are global under a declared CR4.PGE, and only a kernel-half change drops them #873 ruling names both makers. Read AMD's documents: APM Vol. 3's MONITOR and MWAIT entries, and the family 17h PPR or optimization guide. Otherwise record in each issue that AMD's position is unread.
5. issues/idle-cpus-enter-the-c-states-cst-names.md:9-10, issues/diskserver-drives-nvme-apst.md:10-13, :18 — Both stages still take their design or their oracle from Linux. The track's new line 21 replaces Linux with the manufacturers and the published state of the art, and reviewer.md's Tests refuses another OS's policy as an oracle. The body leaves them because neither is a kill line. Cite ACPI's _CST/_LPI and the NVMe base specification's APST together with the drive's own id-ctrl table. Or leave the C-states file to Design: idle CPUs enter the deep idle states the firmware declares #870, which takes it up, and say so.
6. PR body, Unsure — "It is what the stage's mutation, 'always the deepest state', is read against" — This is false of the C-states exit. The bound moves with the chosen state, so the mutation stays inside it (Asked, above).
7. PR body, "The ruling" — the opening quote, attributed to the owner "today" — The body links nothing for it, and no comment on issues: the kernel performance audit's findings, priced by three scouts, and the speed track restaged by them #866, Design: idle CPUs enter the deep idle states the firmware declares #870, User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871, x86-64 kernel leaves are global under a declared CR4.PGE, and only a kernel-half change drops them #873, A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874, A design follows what its hardware's manufacturers or the published state of the art back, and a bench verdict never blocks it #885 or issues: the speed track's stages stand on the vendors' documents and the literature, and report their figures #887 carries it. Link where he said it, or drop it.
8. PR body, "What changed" (the FP/lock file) — "The SDM backs both changes" — §7.6 shows that the prefix is unneeded and recommends nothing. The lock half stands on root CLAUDE.md's "no defensive code", not on any backing.
9. PR body, Unsure, "Collisions" — "Whichever lands second resolves a modify/delete or a content conflict on these files" — None of Design: idle CPUs enter the deep idle states the firmware declares #870, x86-64 kernel leaves are global under a declared CR4.PGE, and only a kernel-half change drops them #873 and A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874 changes a file this branch changes. Only User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871's planned deletion meets one.

SEND BACK

[Japabu]

The orchestrator, on the BLOCKER (the TSC-deadline stage), applying the owner's standing ruling (#885: a design its manufacturers or the published state of the art back is followed, and its figure is reported; a design nothing published covers is reviewed on merits, and speed decides only when it is the whole purpose). The SDM documents the TSC-deadline mode without recommending it, AMD documents none, and the issue names no purpose but speed. So this stage is the owner's exception: its speed reading decides it. Keep a reading that decides the stage, as the review's second option says, and record why in the issue. Take the NOTEs as the review names them, with "back" for "document" first among them. For the busy-wake 8-thread arm (NOTE 3), say the 100 µs bound decides it, because nothing published covers it and latency is its whole purpose.

[Japabu]

Triage of an external automated review (ChatGPT, supplied by the owner)

I read the review against #887 at f1ee8dd94 (origin/main c0cdddf4e), the body at that head, round 1 (#887 (comment)) and the orchestrator's ruling on it (#887 (comment)). It makes two claims about this PR:

• its Finding 8, that FSGSBASE needs an explicit decision before its performance criterion goes: holds, and nobody has raised it;
• its verdict row's "integrate after A design follows what its hardware's manufacturers or the published state of the art back, and a bench verdict never blocks it #885": the body already rests on that ruling, and the claim names no defect.

BLOCKER

1. issues/fsgsbase-is-taken.md:7,13-16,18-25 — the new slug, title and exit treat FSGSBASE as a backed stage whose figure decides nothing, but the source cited recommends only caution — this is the same shape as round 1's TSC-deadline BLOCKER, which the orchestrator ruled the owner's exception (6126459301).
   • What the branch did. It deletes "a loss becoming a rejected issue with both figures" and renames fsgsbase-is-measured-then-taken-or-rejected to fsgsbase-is-taken. The body's reason is that "Intel publishes what FSGSBASE gives and how an OS takes it".
   • What Intel's guidance recommends. sources.md:205-208 at evidence de7e8151 quotes it. Its one recommendation is a condition: "Intel recommends that it be used with caution and never in production environments unless accompanied by a complete OS implementation." It does not recommend FSGSBASE over today's design, where GS holds the kernel's per-CPU base and the kernel runs no swapgs.
   • Every purpose Intel names is speed. The text says "fast switching to different threads", system calls "much slower than direct access", "improving performance" and "more efficient context switching" (:206-207). The issue names no other purpose (:13-14).
   • AMD's position is not on record. sources.md holds no AMD text on FSGSBASE, yet the AMD bench is a proving machine (toyos-uses-what-modern-hardware-offers-for-speed.md:15-17).
   • Nobody has answered the question. The body's Unsure asks it ("If the owner reads FSGSBASE as something nothing published covers, with speed its only purpose, his exception lets a measured loss decide, and the old exit stands"). Neither round 1 nor 6126459301 answers it. So the issue settles in one direction a question the owner's ruling leaves open, which states his ruling more broadly than he gave it.
   • Fix. Put FSGSBASE to the orchestrator, as the TSC-deadline stage was put.
     • If it is the owner's exception: restore the old exit's deciding reading and its slug, and record the reason in the issue.
     • If it is backed: name the source that recommends it, write the ruling in, and record AMD's position as read or as unread.

NOTE

None.

[Japabu]

The orchestrator, on the triage's FSGSBASE BLOCKER (#887 (comment)).

Unlike the TSC-deadline mode, FSGSBASE has published backing: Linux enables it by default on every CPU that has it since 5.9, with the complete OS implementation Intel's guidance asks for (the kernel saves and restores the bases itself and trusts no user-written GS on entry).

So the stage is a design the published state of the art backs. Its figure is reported, never gated, and the rename to fsgsbase-is-taken stands. The issue cites Linux's implementation and Intel's condition, and states that ToyOS's implementation must meet that condition. AMD's position is recorded as unread unless its documents are read.

[Japabu]

The orchestrator, on the two stages left open (the MWAIT idle loop and per-CPU false sharing, on the AMD bench), applying #885's rule:

• Per-CPU lines. Keeping a CPU's hot state off lines other CPUs write is the published state of the art on every cache-coherent machine: Linux's ____cacheline_aligned_in_smp and Intel's optimization manual. AMD documents the 64-byte line it rests on and says nothing against it. The stage is backed on both benches, and its figure is reported.
• The MWAIT idle loop. Intel backs it. AMD documents MWAIT but recommends no MWAIT idle loop. So the stage is backed on Intel hardware only. On AMD hardware ToyOS follows AMD's guidance and the firmware's _CST (Design: idle CPUs enter the deep idle states the firmware declares #870's ground), and the MWAIT arm applies there only if AMD or the published record backs it. The issue says so per vendor.

The agent's proposed rule (documented-but-not-recommended falls under the speed-only exception) is how #885's "back" already reads, so no new sentence is placed.

[Japabu]

Round 2, head 533acff9b5e54950752e85e54325a8c5c31bc67f, against origin/main ecd6d1cc5 (git merge-tree --write-tree exits 0).

Net lines (git diff --shortstat origin/main...533acff9b): 9 files, +134 −114, all under issues/. Production 0, tests 0.

Evidence: ToyOSOrg/evidence pr-887 at 8edc96cc4. ci-host.log is 8839 lines. Its first stamp, 15:16:37, comes 15 s after the head's commit at 15:16:22Z. It ends [ci] Host: 76 step(s), all green and then EXIT=0. Every FAILED in it sits under a [ci] control … step that reports its verdict reached. No guest test reaches a change to issues/ alone. Every new quote in sources.md covers the claim the issue makes from it: APM §E.3.2 bit 24, APM Vol. 2 §2.5.12 and CR4.FSGSBASE, APM Vol. 3 MONITOR/MWAIT/RDFSBASE/WRFSBASE, 56305, Lozi §3.3 and its fix, NVMe 2.1 §5.1.25.1.6/§8.1.17/§8.1.17.2, and Linux v5.9 common.c/process_64.c/entry_64.S.

Earlier findings

• Round 1 BLOCKER, TSC deadline: CLOSED as 6126459301 ruled. main's twin, kill line and deciding exit are back (the-timer-is-…:58-76), the reason is written at :29-33, and the AMD bench's CPUID.01H:ECX[24] is answered by APM §E.3.2 (sources.md:250-282). The ruling's premise does not hold, though: see BLOCKER 1.
• Triage BLOCKER, FSGSBASE: CLOSED as 6126603857 ruled. fsgsbase-is-taken.md:13-28 cites Intel's condition and Linux v5.9's implementation, records AMD as read, and states ToyOS's implementation must meet the condition. The exit adds the switch half (:33-34). git grep fsgsbase-is-measured 533acff9b exits 1.
• Round 1 NOTEs 1–9: CLOSED.
  • 1: "back" (toyos-uses-…:21-22).
  • 2: §3.3 cited (a-wake-…:43-49).
  • 3: written as ruled, but see BLOCKER 2.
  • 4: AMD's documents read (APM Vol. 2 and Vol. 3, 56305).
  • 5: APST rests on NVMe 2.1, and the C-states issue is left to Design: idle CPUs enter the deep idle states the firmware declares #870.
  • 6–9: the body is corrected, and 6125405603 carries both quotes.

BLOCKER

1. issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md:29-33, :58-70; issues/toyos-uses-what-modern-hardware-offers-for-speed.md:50-54 — "nothing published covers the choice" is false of the published record. On that premise, a twin's kill line can make a design the published state of the art backs rejected on a bench reading, which the owner's A design follows what its hardware's manufacturers or the published state of the art back, and a bench verdict never blocks it #885 answer forbids.
   • Linux since v3.8. Linux has armed its one-shot through IA32_TSC_DEADLINE on every CPU that enumerates it since v3.8. The commit is 279f1461432c, by Intel's Suresh Siddha: "This enables us to skip the APIC calibration during boot. Also, in xapic mode, this enables us to skip the uncached apic access to re-arm the APIC timer". Today calibrate_APIC_clock returns at once and setup_APIC_timer registers lapic-deadline wherever the bit is set. The T14's model 140 is in no deadline_match errata row.
   • Linux v7.1. f246ec3478cf ("x86/apic: Enable TSC coupled programming mode") hands the deadline over in TSC cycles "without reading the TSC at all". That is the design :50-56 describes.
   • The FSGSBASE standard. This is the evidence 6126603857 took as backing for FSGSBASE ("Linux enables it by default on every CPU that has it since 5.9"). The owner's question in 6125405603 was "when a change follows vendor or published practice". Round 1 and 6126459301 read the SDM and the APM only, not Linux.
   • Fix. Put both commits to the orchestrator.
     • If backed: the paragraph at :29-33, the kill line and the rejected outcome go, the stage cites them, and the twin's reading is reported.
     • If he rules it speed-only with them in hand: write his reason in the issue.
2. issues/a-wake-to-a-busy-cpu-waits-for-its-next-pass-and-no-idle-cpu-can-take-it.md:49-51 — "With 8 spinners … nothing published covers it; … the 100 µs bound below decides its design" is false of the record, and so lets a figure decide a design that published practice covers.
   • What covers it. A wake onto a CPU running a task while no CPU idles is what wakeup preemption decides. Linux's fair class has done it since CFS, and since v6.6 by virtual deadline: 147f3efaa241, "Implement an EEVDF-like scheduling policy", says "wakeup preemption is driven by the deadline". ToyOS's fair band is the same vruntime/lag family (kernel/pure/sched/fair.rs:1-3).
   • Round 1 erred. Round 1's NOTE 3 read only what the issue cites, and 6126459301 took that as "nothing published".
   • Fix. Put it to the orchestrator. If backed, the 8-spinner arm follows and cites wakeup preemption, and the 100 µs bound stays the exit's test rather than its design's judge.

NOTE

1. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:19-24, :52-54 — the issue does not yet say per vendor what 6127284991 rules, and its AMD record is incomplete.
   • AMD's commit. aebef63cf7ff (Linux v6.0) is by AMD's Wyes Karny: "AMD Family 17h onwards supports MWAIT as well as MWAIT C1. And it is preferable to use MWAIT as the default idle state on these systems, as it has lower exit latencies". prefer_mwait_c1_over_halt has carried no vendor check since.
   • The ruling's condition. That meets the ruling's own condition for the AMD arm ("only if AMD or the published record backs it"), and the AMD bench is family 17h.
   • Change. Write the per-vendor sentence: Intel by §11.10.4 and §11.10.6.4, AMD family 17h onward by aebef63cf7ff. Scope "recommends it for no idle loop" to the APM, or drop it. Have the orchestrator confirm the AMD arm with the commit in hand.
2. issues/per-cpu-scheduler-and-pmm-state-shares-lines-every-cpu-writes.md:43-48 — 6127284991 rules the stage backed on both benches, by Linux's ____cacheline_aligned_in_smp and Intel's manual. The issue cites Intel alone and records AMD's silence, so on the AMD bench it cites nothing that backs the stage. Cite what the ruling names.
3. issues/every-syscall-saves-the-fp-state-and-every-preemption-disable-is-locked.md:22-28 — the lock half is backed by published practice, and the issue does not cite it.
   • Linux. Linux's x86 preempt count is a plain per-CPU add, with no lock: __preempt_count_add/_sub go through raw_cpu_add_4 (arch/x86/include/asm/preempt.h:96-104).
   • Change. Cite it. The body's "The lock half is backed by no document" is false of the record.
4. PR body — two lines no longer hold. The "Unsure" question on AMD's MWAIT and false sharing is ruled (6127284991). In "Collisions", User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871 no longer only "plans" to delete every-syscall-saves-…: at cdd090baa it deletes it.

SEND BACK

[Japabu]

The orchestrator, correcting two earlier rulings in light of round 2's evidence (#887 (comment)). Those rulings read the vendors' manuals and not Linux, and #885's rule counts the published state of the art too.

• TSC deadline: backed, not speed-only. Linux has armed its one-shot through IA32_TSC_DEADLINE wherever the CPU enumerates it since v3.8 (279f1461432c, by Intel's Suresh Siddha), with TSC-coupled programming in v7.1 (f246ec3478cf). The kill line and the rejected outcome go. The stage cites both commits, and the twin's reading is reported.
• The busy-wake 8-spinner arm: backed. A wake onto a busy CPU with no CPU idle is decided by wakeup preemption, which Linux's fair class has done since CFS, and since v6.6 by virtual deadline (147f3efaa241, EEVDF). The arm follows and cites it. The 100 µs bound stays the exit's test that the stage works, not the judge of its design.
• MWAIT idle on AMD: backed. AMD's own Linux commit aebef63cf7ff (v6.0) prefers MWAIT as the default idle state from family 17h onward. The stage is backed on both benches: Intel by SDM §11.10.4/§11.10.6.4, AMD family 17h onward by aebef63cf7ff.
• Round 2's NOTEs 2–4, taken:
  • the per-CPU-lines issue cites Linux's ____cacheline_aligned_in_smp beside Intel's manual;
  • the lock half cites Linux's unlocked per-CPU preempt count (asm/preempt.h);
  • the body's stale lines go.

[Japabu]

Round 3, head 2d7b881b026821b8798b6d6ae9ecd2725f5fcb4d, against origin/main ab655a115, which is also the merge base. git merge-tree --write-tree origin/main 2d7b881b0 exits 0.

Net lines (git diff --shortstat origin/main...2d7b881b0): 8 files, +153 −117, all under issues/. Production 0, tests 0.

Evidence: ToyOSOrg/evidence pr-887 at 243c4ba2, whose message names 2d7b881b0.

• ci-host.log is 9059 lines. Its first stamp, 17:58:27, comes 18 s after the head's commit at 17:58:09Z. It ends with [ci] Host: 76 step(s), all green and then EXIT=0.
• Every FAILED or panicked line in it falls under a [ci] control … step.
• No guest test reaches a change that touches only issues/.

Earlier findings

• Round 2 BLOCKER 1, the TSC deadline: CLOSED.
  • the-timer-is-…:29-40 cites 279f1461432c and f246ec3478cf. sources.md:575-794 quotes both, with the release that first carries each.
  • The kill line and the rejected outcome are gone. git grep -n -i 'kill\|rejected\|nothing published' over the seven changed files hits only the track's rule sentence (toyos-uses-…:24).
  • The exit beside them is new BLOCKER 1.
• Round 2 BLOCKER 2, the 8-spinner arm: CLOSED.
  • a-wake-to-a-busy-cpu-…:49-56 cites check_preempt_curr_fair at v2.6.23 and 147f3efaa241 (sources.md:796-913).
  • It names the 100 µs bound the exit's test. See NOTE 1.
• Round 2 NOTEs:
  • NOTE 1: CLOSED (idle-is-hlt-…:19-30).
  • NOTE 2: CLOSED (per-cpu-…:43-55).
  • NOTE 3: CLOSED, moot. cdd090baa deleted its file, and the quote is in sources.md:1150-1170.
  • NOTE 4: CLOSED.

The merge of main (ce43d7bd2) and #871's deletion

• The conflict. git merge-tree --write-tree 533acff9b ab655a115 conflicts on one path only: every-syscall-saves-…, a modify/delete. The merge takes the deletion, and git grep every-syscall-saves 2d7b881b0 exits 1.
• The four hunks. The branch's diff of that file (36aff86fc..533acff9b) has four hunks. The merge message and the body account for each:
  • The §16.4 and §2.5.12 citations backed a save at the switch, which User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871 built.
  • The §6.6 to §7.6 correction stands on main at kernel/src/arch/x86_64/percpu.rs:101-102.
  • The kill line and the exit's refusal clause belonged to an exit that cdd090baa closes item by item.
• The track. User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871 left main's track citing the deleted file at :40 and :109. The merge drops both citations and the "Unexplained" lock bullet, whose "(its issue)" pointed at that file. It adds the two issues User FP/vector state is saved only at a switch, the preempt count drops lock, and the build refuses stray vector instructions #871 filed with the track as their owner.
• Nothing else moved. git diff --stat ab655a115 2d7b881b0 lists only the eight issue files, so every other line of main survives the merge.

BLOCKER

1. issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md:74-78 — the exit holds the T14's 1 ms timer lateness "no worse than the count's", which lets a bench number block a stage ruled backed.
   • What changed. This round makes that condition unconditional, on a stage the issue calls backed.
   • What it contradicts.
     • The issue's own :39-40: "its figure is reported and decides nothing".
     • The track's :17-24, which says that program's figure is "reported and never blocks it". The lateness is one of that program's figures (no-program-measures-…:12-13).
   • Why it matters. A bench number now blocks the close of a design the published state of the art backs. That states the owner's A design follows what its hardware's manufacturers or the published state of the art back, and a bench verdict never blocks it #885 answer more narrowly than he gave it.
   • The body. It says "Its exit reads its figure and reports it", and that is false of this file. Its own list of main's faults includes "one held a figure to the count it replaced", which is this exit. Round 1's head (f1ee8dd94) had the lateness "read with the count and with the deadline".
   • Fix, one of:
     • report the lateness, as round 1's head did;
     • or have the orchestrator rule it the deadline's correctness test, as 6127473561 rules the busy wake's 100 µs, and write that in the issue with a bound that noise cannot cross. One times the count's median is not such a bound.

NOTE

1. issues/a-wake-to-a-busy-cpu-…:49-56 — "That arm follows it" leaves out the curb on wakeup preemption that the cited release ships.
   • The curb. v6.6 also carries 63304558ba5d, "sched/eevdf: Curb wakeup-preemption". v6.6's pick_eevdf, which the quoted check_preempt_wakeup calls, returns curr under it (fair.c:890 at v6.6).
   • At v7.2. It is RUN_TO_PARITY, on by default: "Inhibit (wakeup) preemption until the current task has either matched the 0-lag point or until is has exhausted it's slice" (kernel/sched/features.h:16-20). wakeup_preempt_fair applies it through pick_eevdf's protect_slice (fair.c:1163).
   • Against the exit. The base slice is 0.7 ms before CPU-count scaling (fair.c:79), seven times the exit's bound.
   • Change. Say which part the arm follows. If it follows the curb, the 100 µs bound decides against it wherever the woken task leaves the spinner eligible, and 6127473561 says the bound does not decide.
2. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:14-15, :58-60 — "woken by the store alone and takes no interrupt" carries no erratum.
   • Intel's commit. c9a4b55431e5 (v6.13), by Intel's Len Brown: "MONITOR wakeups on Lunar Lake processors can be lost … so that wake_up_idle_cpu() always sends an IPI".
   • Linux at v7.2.
     • X86_BUG_MONITOR covers Goldmont and Lunar Lake (arch/x86/kernel/cpu/intel.c:560-563).
     • On those CPUs mwait_idle_with_hints never sets the polling flag (asm/mwait.h:116).
     • The prefer_mwait_c1_over_halt this issue cites falls back to HALT there (process.c:891, quoted in this branch's own sources.md:1067).
   • Why it matters. Lunar Lake is 2020+ hardware ToyOS targets, and the track takes a feature "on every CPU that enumerates it" (:9-10).
   • Change. Record that the kick stays on a CPU whose MONITOR loses wakes, as Linux keeps it.
   • The body's Unsure. Linux's TSC errata table, deadline_match, names only Haswell to Kaby Lake, all before 2020. That question is answered.
3. issues/the-timer-is-…:65-72 — the twin's reading now decides nothing, and its clock control has both arms' readings "taken again" with no bound.
   • The risk. If an arm itself moves APERF/MPERF by more than 1 %, the reading the exit's first item asks for never comes.
   • The alternative. The MWAIT stage's form, its split read again after the change, does the same job without a second build.
   • Whose call. The orchestrator's ruling names the twin, so dropping it or bounding the retake is his.
4. issues/diskserver-drives-nvme-apst.md:9-19 — the stage dropped "honours NVME_QUIRK_NO_APST and NVME_QUIRK_NO_DEEPEST_PS" along with Linux's latency policy.
   • What they are. These quirks are not policy. They record drives whose APST failed: a recorded real failure, which root CLAUDE.md names as an oracle.
   • The ruling. The owner's answer removed bench verdicts, not records of hardware failure.
   • Change. The body's Unsure sees this and the issue does not. Keep those drives refused, or record whether the T14's drive is among them.
5. issues/fsgsbase-is-taken.md:9, :34-36 — this new file's exit names things the tree does not have.
   • The kernel and the test. The exit deletes "the user-writable-gsbase kernel (build/build.rs:1370) and the test gsbase_locked". Neither is in the tree: 29e1006 cut both, and the-guest-suite-runs-only-what-no-cheaper-tier-reaches.md:87-89 brings them back. build.rs:1370 is SCHED_CHECK_KERNEL.
   • The line citation. control_regs.rs:62-75 is mod cr4. CR4_FORBIDDEN is at :149-153.
   • Change. Name the kernel and the test as that stage's, or drop the line numbers.

SEND BACK

[Japabu]

The orchestrator, on round 3 (#887 (comment)), under #885's rule:

• BLOCKER, the timer exit's lateness: the 1 ms lateness is reported, as round 1's head had it, beside the count's. The metal timings ceiling (2× the machine's record) stays the bug guard.
• NOTE 1, EEVDF's curb: ToyOS follows Linux whole, including RUN_TO_PARITY. So the 8-spinner arm's exit test is that a woken task runs within one protected slice (A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's PROTECTED_RUN_NS, 1 ms), not within 100 µs. The 100 µs figure is reported.
• NOTE 2: record that the kick stays on CPUs whose MONITOR loses wakes (X86_BUG_MONITOR: Goldmont, Lunar Lake), as Linux keeps it, citing c9a4b55431e5.
• NOTE 3: drop the twin. The timer stage reads its split again after the change, in the MWAIT stage's form.
• NOTE 4: keep the APST quirks (NO_APST, NO_DEEPEST_PS) as recorded hardware failures, and record whether the T14's drive is among them.
• NOTE 5: fix fsgsbase-is-taken.md's stale names and line numbers.

[Japabu]

Round 4, head eded3b73a6d2a3994b95e8143855c4397c700089, against origin/main 97f07c381, which is also the merge base. git merge-tree --write-tree origin/main eded3b73a exits 0.

Net lines (git diff --shortstat origin/main...eded3b73a): 8 files, +179 −129, all under issues/. Production 0, tests 0. Since round 3's head:

• e371215b4 merges The orchestrator may ask the owner whether ChatGPT reviews a design pull request, and a reviewer triages what he returns #888. git diff --stat 97f07c381 eded3b73a lists only the eight issue paths, so the merge carries main's orchestrator.md unchanged.
• eded3b73a changes 6 files, +49 −35.

Evidence: ToyOSOrg/evidence pr-887 at 8800065, whose message names eded3b73a.

• ci-host.log is 8861 lines. Its first stamp, 18:59:36, comes 5 s after the head's commit at 18:59:31Z. It ends [ci] Host: 76 step(s), all green, then EXIT=0.
• It has 197 FAILED or panicked lines, and every one falls under a [ci] control … step.
• No guest test reaches a change that touches only issues/.
• None of the other 23 open pull requests changes a file this branch changes.

Earlier findings

• Round 3 BLOCKER 1, the timer's lateness: CLOSED as 6130566783 rules.
  • the-timer-is-…:65-69 reads the lateness "with the count and with the deadline, each reported", as round 1's head f1ee8dd94 did.
  • "No worse than the count's" is gone.
  • BLOCKER 1 below reopens this exit on other grounds.
• Round 3 NOTE 1, EEVDF's curb: CLOSED as ruled (a-wake-…:55-67).
  • 63304558ba5d is Peter Zijlstra's "sched/eevdf: Curb wakeup-preemption" (2023-08-16). It adds SCHED_FEAT(RUN_TO_PARITY, true).
  • features.h has no RUN_TO_PARITY at v6.5, has it on line 9 at v6.6, and carries the quoted comment word for word at v7.2 :16-20. The SHA-256 of each matches sources.md.
  • At A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's head a5e247249, PROTECTED_RUN_NS is QUANTUM_NS / 10 (kernel/pure/sched/cpu.rs:1331). With QUANTUM_NS at 10 ms (fair.rs:16), that is 1 ms.
  • BLOCKER 2 below replaces this note's citations.
• Round 3 NOTE 2, the MONITOR erratum: CLOSED as ruled (idle-is-hlt-…:30-37, :65-67).
  • c9a4b55431e5 is by Len Brown len.brown@intel.com.
  • intel.c names Goldmont alone at v6.12 :589. It adds INTEL_LUNARLAKE_M at v6.13 :558-561, and keeps it at v7.2 :560-563.
  • At v7.2:
    • mwait.h:116 skips current_set_polling_and_test() under X86_BUG_MONITOR;
    • wake_up_idle_cpu (core.c:1324) therefore sends the IPI;
    • process.c:890-892 falls back to HALT.
  • Every SHA-256 matches sources.md. BLOCKER 4 below replaces this note's citations.
• Round 3 NOTE 3, the twin: CLOSED.
  • The timer file no longer names a twin, APERF or MPERF.
  • The track's bullet (:47-49) no longer names a twin either.
• Round 3 NOTE 4, the APST quirks: CLOSED as ruled (diskserver-…:19-28, :30). BLOCKER 7 below takes up the record and the "unread".
• Round 3 NOTE 5, fsgsbase-is-taken's names: CLOSED.
  • control_regs.rs:149-153 is CR4_FORBIDDEN's doc comment and the constant itself (:153).
  • Stage C names gsbase_locked and user-writable-gsbase (the-guest-suite-…:87-89).
  • The Linux v5.9 citations hold at that tag: common.c:1515-1519, process_64.c:248-262 and entry_64.S:823-848.

The owner's direction

The coordinator relayed it during this review: ToyOS does not follow Linux and references it nowhere in the tree; the authority is the vendor's documentation and the published literature. It is not yet on this pull request's record. The orchestrator posts it, then rules again on every stage below whose backing was Linux alone. Each BLOCKER is one place where a ruling of this pull request, or a record this branch writes, rests on Linux. Each says what could replace it, or that nothing does.

BLOCKER

1. issues/the-timer-is-a-lapic-count-re-armed-every-pass-never-a-tsc-deadline.md:29-40, :65-69 — the stage is backed only by Linux: 279f1461432c, calibrate_APIC_clock, setup_APIC_timer and deadline_match at v7.2, and f246ec3478cf. Ruling 6127473561 rests on the same commits, and so do the report-only exit and the deleted twin. — Nothing replaces the backing.
   • What Intel says. Every TSC-deadline passage in SDM 325462-093 (SHA-256 a4a62e6a…, which matches sources.md) defines the mode or its MSR, gives usage guidelines (§13.5.4.1), or virtualizes the mode for guests. None recommends it. The optimization manual 248966-051 (284783f5…) never uses the word "deadline".
   • What AMD says. It documents no such mode (APM §E.3.2).
   • What can replace the Linux lines.
     • deadline_match: Intel's 11th Gen Core specification update 631123-034 (April 2026, 9eaacfd6…, cdrdv2.intel.com/v1/dl/getContent/631123). It lists no TSC, TSC-deadline or APIC-timer erratum for the T14's Tiger Lake.
     • f246ec3478cf's absolute write: §13.5.4.1's own definition, an MSR that "specifies the time at which a timer interrupt should occur".
   • What follows. Without Linux, the stage is where 6126459301 put it: documented, not recommended, and its only purpose is speed. So its reading decides. The orchestrator rules again, and the exit and the twin follow that ruling.
2. issues/a-wake-to-a-busy-cpu-waits-for-its-next-pass-and-no-idle-cpu-can-take-it.md:49-62 — the 8-spinner arm and its curb rest on check_preempt_curr_fair at v2.6.23, 147f3efaa241, 63304558ba5d and features.h at v7.2. So do rulings 6127473561 and 6130566783 ("ToyOS follows Linux whole"). — The EEVDF paper replaces all of them.
   • The paper. Stoica and Abdel-Wahab, "Earliest Eligible Virtual Deadline First: A Flexible and Accurate Mechanism for Proportional Share Resource Allocation", Old Dominion University TR-95-22. I read it from citeseerx, doi=805acf7726282721504c8f00575d91ebfd750564, SHA-256 b44b71a7….
   • What it says. It allocates "in time quanta of size at most q. At the beginning of each time quantum a client is selected" (PDF pp. 3–4). "A new quantum is allocated to the client that has the eligible request with the earliest virtual deadline" (p. 7).
   • What follows. A client that joins in the middle of a quantum is picked no sooner than the start of the next one, and then only if its request is eligible and has the earliest deadline, as the row's owed ping-pong task's is. Its lag is bounded by q (abstract). That backs the exit at :64-67 as written, with q as the protected slice. The four Linux citations and the RUN_TO_PARITY quote go, and the outcome does not change.
3. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:24-30, :65-67 — MWAIT idle on AMD rests on aebef63cf7ff, an AMD engineer's Linux commit rather than an AMD document, and on prefer_mwait_c1_over_halt at v7.2. On that commit alone, 6127473561 reversed 6127284991's "backed on Intel hardware only". — No AMD document read so far replaces it.
   • What AMD's documents say. This file's own :19-24 records that the APM's Vol. 2 and Vol. 3 and AMD's 56305 name no idle loop.
   • Where AMD or the platform would say it. Both are unread:
     • AMD's Processor Programming Reference for family 17h model 60h;
     • the AMD bench's own _CST (ACPI 6.5 §8.4.1.1). If its C1 entry is Functional Fixed Hardware, that is the firmware declaring that C1 is entered by MWAIT, and that is Design: idle CPUs enter the deep idle states the firmware declares #870's ground.
   • Until one is read, 6127284991 stands. The exit's "every proving machine that enumerates MONITOR/MWAIT" then reaches the AMD bench with nothing behind it.
4. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:30-37, :65-67 — the kick's carve-out rests on c9a4b55431e5, X86_BUG_MONITOR, mwait.h and prefer_mwait_c1_over_halt. Ruling 6130566783 says "as Linux keeps it". — Intel's errata replace it in part.
   • Goldmont. Intel's specification update 334820-010 (Pentium and Celeron N- and J-Series, August 2022, SHA-256 0138c484…, cdrdv2.intel.com/v1/dl/getContent/334820) has erratum APL30, "A Store Instruction May Not Wake Up MWAIT". Its workaround: "Software needs to use interrupts to wake processors from MWAIT-induced sleep states". But Goldmont is a 2016 part, outside the 2020+ target.
   • Lunar Lake. c9a4b55431e5 cites a kernel bugzilla report (219364), not an Intel erratum. Intel would publish one in its Core Ultra 200V Series specification update. I could not read it: the Internet Archive was offline, and I found no document number to fetch it by.
   • The T14. Its specification update, 631123-034, lists no MONITOR or MWAIT erratum.
   • Fix. Write the rule from the errata: a CPU whose specification update says a store may not wake MWAIT keeps the kick, citing what Intel publishes. If the 200V update has no such erratum, nothing a vendor publishes names Lunar Lake, and whether the carve-out stays is the orchestrator's to rule.
5. issues/fsgsbase-is-taken.md:17-22, :38-39 — the record rests on Linux v5.9's common.c:1515-1519, process_64.c:248-262 and entry_64.S:823-848, and its oracle is "Linux's paranoid_entry". Ruling 6126603857 decided "backed" because "Linux enables it by default … since 5.9". — Intel's guidance replaces the record, but not the ruling or the oracle.
   • The record. Intel's guidance 767615 states the condition by itself: "the kernel needs to manage the FS / GS base entirely separate from its selector. The ring transition code has to be insensitive to the GS base address" (sources.md:376). It also names process-trace system calls as a third element. So :25-27 can stand on 767615 alone.
   • The ruling. 767615 recommends FSGSBASE only on a condition ("never in production environments unless accompanied by a complete OS implementation"), and the only purpose it names is speed. Whether that counts as backing is the triage's question, which 6126603857 answered with Linux. It goes back to the orchestrator.
   • The oracle. Neither a vendor nor the literature replaces it, because prose is not a differential implementation. What remains is real hardware: the vector-2 arm on both benches.
6. issues/per-cpu-scheduler-and-pmm-state-shares-lines-every-cpu-writes.md:46-51 — DEFINE_PER_CPU_SHARED_ALIGNED, ____cacheline_aligned_in_smp and SMP_CACHE_BYTES at v7.2 are half of what backs ruling 6127284991. — Intel replaces them on the T14. On the AMD bench, only a paper nobody has read yet could.
   • The T14. Intel's 248966-051 §11.4.5 Rule 17, already cited at :43-46, backs the stage without Linux.
   • The AMD bench. AMD documents only the line size (:51-53). Backing there has to come from the literature, for example Torrellas, Lam and Hennessy, "False Sharing and Spatial Locality in Multiprocessor Caches", IEEE Transactions on Computers 43(6), 1994. I have not read it. Read and quote it; otherwise the AMD half is unbacked.
7. issues/diskserver-drives-nvme-apst.md:19-28, :30 — the quirk record is Linux's tables at v7.2, which ruling 6130566783 kept: core_quirks, nvme_id_table and check_vendor_combination_bug. — Nothing replaces them, and the question the file calls unread can already be answered.
   • No vendor or paper. The rows cite bug trackers, for example Launchpad bug 1678184 for the Toshiba THNSF5256GPUK in core.c. No drive maker publishes these errata. The NVMe Base Specification 2.1 (:11-18) is left standing alone.
   • The T14's drive. The file says whether it is quirked is unread, but it can be read now:
     • The kernel prints every PCI function's vendor and device (kernel/src/drivers/pci.rs:600-607).
     • The T14's boot log in the evidence repository carries the drive's line: branch pr-874, metal/judgement/t14/base/scout-wake/kernel.log:78.
     • At v7.2, no row of nvme_id_table names that vendor and device, and no row of core_quirks names that vendor. check_vendor_combination_bug's one unconditional row names a Lenovo N60z board.
   • What follows. The T14's drive is in none of the three. The quirk sentence and "a quirked drive's among them" go with the Linux record, unless the orchestrator keeps them on some other ground.

NOTE

1. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:65-67 — "a CPU whose MONITOR loses wakes still kicked" names no check, and no proving machine is a Goldmont (family 6, model 0x5C) or a Lunar Lake (model 0xBD). So a carve-out dropped in the build lands unseen. — A host test reaches it, the cheapest tier.
   • Why a host test is enough. The verdict is a pure function of CPUID's vendor, family and model. toyos-cpuvuln already holds that shape beside erratum_1386; its manifest calls itself "Verdicts from a CPU's CPUID and MSR facts, pure".
   • Change. Name the host test in the exit.
   • The body. Its Unsure says "Reading the code is its only check", which is false for the same reason.
2. issues/toyos-uses-what-modern-hardware-offers-for-speed.md:21-24 — "a gap to that program's Linux figure" names Linux as a measurement, not as an authority, and the program it names (no-program-measures-toyos-against-linux-on-one-machine.md) is main's. — Read literally, the direction's "nowhere in the tree" reaches that program, and main's toyos-cpuvuln ("Linux's on each speculative-execution vulnerability") as well. Scoping it is the owner's call, outside this branch's fence.

SEND BACK

[Japabu]

The owner's direction, and the re-rulings it forces (after #887 (comment)).

The owner: "Were not reimplementing linux and if we look at the code we use clean room procedure because i think linux has a bad license. We dont want to reference linux anywhere in our code." He confirmed the same procedure covers permissively licensed code. The authority for a design, a value or a test oracle is the vendor's documentation and the published literature. Another implementation's source is read only clean-room. Linux is cited nowhere in the tree as an authority. Round 3's rulings that rested on Linux alone are re-ruled here:

1. TSC deadline: Intel's SDM documents the mode and recommends nothing, so the earlier ruling returns: the T14's speed reading decides. The stage measures the timer's lateness under the count and under the deadline on the T14, and keeps the one that measures better. The twin comes back, as a measurement arm deleted once it has answered. Intel's Tiger Lake specification update (631123) is cited for the absence of a timer erratum.
2. The 8-spinner arm cites the EEVDF paper (Stoica and Abdel-Wahab, TR-95-22) instead of the Linux commit. The exit stands.
3. MWAIT idle on AMD: the earlier "Intel only" ruling stands until AMD's own documentation for the family (its PPR, and the bench's _CST) is read. The owner has been asked for the PPR.
4. The MONITOR carve-out is sourced from Intel's specification updates alone. Read the Core Ultra 200V specification update. If Intel publishes the erratum there, cite it. If not, the Lunar Lake entry goes, and the rule stays general: a CPU a vendor erratum names as losing MONITOR wakes keeps the kick. NOTE 1 is taken: a host test holds the verdict by vendor, family and model.
5. FSGSBASE rests on Intel's guidance (767615) and its stated conditions, which the kernel meets or the stage says how. The oracle is the vector-2 arm on the T14.
6. Per-CPU cache lines cite Intel's optimization manual for the T14, and AMD's Software Optimization Guide for the family for the AMD bench. The owner has been asked for that guide too.
7. APST follows the NVMe specification, with no quirk table. The T14's drive is in no list anyway (pr-874's boot log names it). A drive that misbehaves is a defect measured on the bench and filed. This reverses round 3's "the quirks stay".

NOTE 2: a figure measured from another OS on our bench is a comparison, not an authority. The tree states ToyOS's own targets, and a comparison lives in the evidence.

[Japabu]

Ruling on ruling 6’s AMD half. AMD’s guide (55723 rev 3.00) documents the 64-byte line. Placing per-CPU data on lines of its own is ToyOS’s rule, resting on that documented size, and it needs no false-sharing text from AMD. The AMD half stands.

[Japabu]

Round 5, head 11be3ba557c25e67b5c8e32c7b0828ad16863834, against origin/main b680a973b, which is also the merge base. git merge-tree --write-tree origin/main 11be3ba55 exits 0, and no other open pull request changes a file this branch changes.

Net lines (git diff --shortstat origin/main...11be3ba55): 8 files, +175 −128, all under issues/. Production 0, tests 0. Since round 4's head eded3b73a:

• 9b41c8e06 and 10dd91393 merge main. git diff --stat 10dd91393 11be3ba55 lists only the seven issue paths.
• 11be3ba55 is the round's change.

Evidence: ToyOSOrg/evidence at 742acf4d, whose message names 11be3ba55.

• ci-host.log is 9145 lines. Its first stamp, 00:09:48 UTC, comes 3 s after the head's commit at 00:09:45Z. It ends [ci] Host: 76 step(s), all green, then EXIT=0.
• No guest test reaches a change that touches only issues/.

I checked the two vendor documents the brief supplied against their own text. Both SHA-256s match sources.md: PPR 55922 is b48d3cb4… and 55723 is 05ccc2b1…. I extracted the text with PDFKit, separately from the branch's PyMuPDF.

• PPR 55922 rev. 3.06 holds what the branch cites.
  • CPUID_Fn00000001_EBX[15:8] CLFlush is "Fixed,08h … in quadwords".
  • CPUID_Fn00000001_ECX bit 24 is Reserved. Bit 3, Monitor, resets to !HWCR[MonMwaitDis].
  • CPUID_Fn00000005 gives MonLineSizeMin and MonLineSizeMax of 40h, and MWaitC1SubStates of 1h.
  • The document has no _CST, no FFH and no idle loop. Its only C-state text points at the ACPI specification ("See docACPI").
• 55723 rev. 3.00 holds what the branch cites, with one exception, below.
  • §2.6.1 gives the 64-byte line, in the L1 instruction cache's paragraph.
  • §2.6.4 says that a miss whose shadow tags show the line in another L2 starts "a cache-to-cache transfer … within the complex".
  • The exception: it gives no cost for that transfer. Its only latency is the L3's average of 35 cycles.
  • It has nothing on false sharing.
• The sources.md quotes match their documents. That covers 631123-034, 334820-010 APL30, 767615, RTSS 1996, Lozi §3.3 and NVMe 2.1. sources.md quotes no Linux.

Earlier findings

• Round 4 BLOCKER 1, the timer: CLOSED as ruling 1 of 6131154873 has it (the-timer-is-…:31-36, :61-74).
  • The T14's reading decides, and the twin is back as a measurement arm, deleted once it has answered.
  • 631123-034 is cited for the UP3 line's 000806C1h. Its errata TGL001–TGL075 are quoted as naming no TSC, deadline or APIC-timer erratum.
  • The Linux commits are gone.
• Round 4 BLOCKER 2, the 8-spinner arm: CLOSED (a-wake-…:43-63).
  • The two quoted sentences are RTSS 1996's, word for word against sources.md:619-633.
  • The four Linux citations and RUN_TO_PARITY are gone.
• Round 4 BLOCKER 3, MWAIT on AMD: OPEN. BLOCKER 1 below.
  • The PPR has been read, and it says what the file says.
  • The exit settles the AMD bench before its _CST is read, on a reading of FFH that no cited document gives.
• Round 4 BLOCKER 4, the carve-out: OPEN. BLOCKER 2 below.
  • APL30 is quoted correctly.
  • Lunar Lake went out without the reading that ruling 4 makes the condition of its going.
• Round 4 BLOCKER 5, FSGSBASE: CLOSED (fsgsbase-is-taken.md:14-32, :43).
  • 767615 is quoted alone, and its three elements are answered.
  • sdk/abi/src/syscall.rs at the head has no call that reads or writes another thread's registers. SYS_DEBUG (92) only panics or faults the kernel.
  • The oracle is the vector-2 arm on the T14.
  • The old slug is cited nowhere in the tree (git grep fsgsbase-is-measured-then-taken-or-rejected 11be3ba55 is empty).
• Round 4 BLOCKER 6, per-CPU lines: the Intel half is CLOSED. The AMD half is OPEN under 6135132762, which was posted after this head. BLOCKER 3 below.
• Round 4 BLOCKER 7, APST: CLOSED (diskserver-drives-nvme-apst.md:10-27).
  • The NVMe 2.1 §5.1.25.1.6 Figure 393, §8.1.17 and §8.1.17.2 quotes say what the file says.
  • The quirk table and "a quirked drive's among them" are gone.
• Round 4 NOTE 1: CLOSED. The exit names the host-tested verdict and both of its red cases (idle-is-hlt-…:66-69).
• Round 4 NOTE 2: CLOSED for the rule line (toyos-uses-…:21-25). NOTE 3 below takes up what remains.

BLOCKER

1. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:28-31, :69-71: the exit already takes the doorbell on the AMD bench "where its C1 is FFH MWAIT", on the claim that an FFH C1 in _CST "is the firmware declaring C1 entered by MWAIT". Ruling 3 keeps the stage Intel-only until the PPR and the bench's _CST are read, and the _CST is unread.
   • No cited document supports the claim. ACPI makes Functional Fixed Hardware processor-specific. The PPR has no _CST, FFH or MWAIT-for-C-state text. No AMD document is cited for what an FFH C-state entry means on AMD.
   • The ground it cites rests on Linux. That ground is issues/idle-cpus-enter-the-c-states-cst-names.md, which takes its states "as Linux takes the T14's" with "Oracle: Linux's figures".
   • Fix. Leave the AMD bench's half as ruling 3 put it: Intel only, with the AMD half the orchestrator's to decide once the _CST is read. Otherwise, cite the vendor document that defines an FFH C-state entry on AMD.
2. issues/idle-is-hlt-so-every-wake-of-an-idle-cpu-is-an-ipi.md:31-36, :66-69: ruling 4 makes reading the Core Ultra 200V specification update the condition for dropping Lunar Lake. sources.md:608-610 records that document as not read, yet Lunar Lake is dropped anyway.
   • The issue no longer records the open question. No line says the 200V update is unread. The exit's verdict names Goldmont and the T14 alone, so whoever builds it builds a table that never asks.
   • Fix. Read the 200V update and apply ruling 4's two branches. Otherwise, the issue says the 200V update is unread, and the exit reads it and puts any MONITOR erratum it names into the verdict's table.
3. issues/per-cpu-scheduler-and-pmm-state-shares-lines-every-cpu-writes.md:46-54: the AMD half ends with "AMD documents the cost and recommends nothing". Read with the track's rule (toyos-uses-…:21-25), that makes the AMD bench a stage nothing published covers, so its speed reading would decide. Ruling 6135132762 says the opposite: the AMD half stands, on ToyOS's rule that per-CPU data goes on lines of its own, resting on AMD's documented 64-byte line, and needs no false-sharing text.
   • The claim is also false of 55723. §2.6.4 names a cache-to-cache transfer, and only "within the complex". It gives no cost.
   • Fix. State the AMD half as the ruling gives it. Cite PPR CPUID_Fn00000001_EBX[15:8] and 55723 §2.6.1 for the line, and drop "documents the cost".

NOTE

1. issues/idle-is-hlt-…:36-37 and issues/the-timer-is-…:24-25: the T14's MONITOR/MWAIT and TSC-deadline support rest on kernel/cpuvuln/fixtures/t14/cpuinfo.txt:20, a Linux /proc/cpuinfo reading in Linux's flag names. It is a measurement under Linux standing as the authority for a hardware fact. issues/the-tree-names-linux-as-an-authority.md also lists that fixture directory for removal, so the citation will point at nothing.
   • The raw leaf in the same capture, cpuid.txt:2, already reads ECX 7ffafbbf, with bits 3 and 24 set. It is still a Linux capture.
   • A ToyOS boot print of CPUID.01H:ECX would be ToyOS's own read. The T14's boot log at pr-874 has none.
2. issues/the-timer-is-…:66, :70-72: "measures better" fixes neither the statistic nor what happens when two spreads overlap, and the twin has no clock control (the body's Unsure). As written, a reader of the posted reading cannot tell whether the exit was met. Name the comparison before the twin runs.
3. issues/toyos-uses-what-modern-hardware-offers-for-speed.md:30-31, :55-74: the track still carries Ubuntu comparisons as its "Unexplained" items, with their "Next" measurements framed against "both systems". NOTE 2 of 6131154873 says "a comparison lives in the evidence" and the tree states ToyOS's own targets.
4. issues/a-wake-to-a-busy-cpu-…:43-52, :64-67: Lozi et al. apply their fix "only … if the system's power management policy does not allow cores to enter low-power states at all". The issue quotes that condition, but it does not say whether the 7-spinner arm follows it once issues/idle-cpus-enter-the-c-states-cst-names.md lets cores sleep deeper. If the arm follows it, that changes what the 100 µs row holds.
5. issues/a-wake-to-a-busy-cpu-…:58-63: the 8-spinner exit is stated in PROTECTED_RUN_NS. That is A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's value, which is not on main, and the issue does not say it is blocked on A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874.
6. issues/idle-is-hlt-…:66-69: with Lunar Lake gone, the only CPU the host-tested verdict names is Goldmont, a 2016 part outside the 2020+ target. Whether that table earns its place beyond holding "the T14 is not kicked" is the orchestrator's to rule.
7. The pull request body's per-CPU paragraph says 55723 gives "the cache-to-cache transfer a line in another core's L2 costs". 55723 gives no such cost.

SEND BACK

[Japabu]

Rulings on the round-4 re-review (#887 (comment)).

1. MWAIT on AMD (BLOCKER 1): ruling 3 stands as written. The stage is Intel-only, and the AMD half is mine to decide once the bench's _CST is read. The exit takes no doorbell on AMD.
2. MONITOR carve-out (BLOCKER 2, NOTE 6): a table that names only Goldmont, outside the 2020+ target, does not earn its place, so it is deleted. The issue says the Core Ultra 200V specification update is unread, and its exit reads it: if a 2020+ Intel update names a MONITOR erratum, the verdict and its host test come back with that row.
3. Per-CPU lines on AMD (BLOCKER 3, NOTE 7): state it as 6135132762 gives it. Cite PPR CPUID_Fn00000001_EBX[15:8] and 55723 §2.6.1, and drop "documents the cost" from the issue and the body.
4. The T14's CPU facts (NOTE 1): they come from ToyOS's own read. The timer and idle exits gain a boot line printing CPUID.01H:ECX, and cite it once a T14 boot carries it. No Linux capture is cited.
5. "Measures better" (NOTE 2) is named before the twin runs: the statistic, the run count, and that overlapping spreads decide for the simpler path (the count).
6. The Ubuntu comparisons (NOTE 3) leave the track for the evidence. The track states ToyOS's own targets.
7. NOTEs 4 and 5: say whether the 7-spinner arm follows Lozi's power-management condition once deeper C-states land, and that the 8-spinner exit is blocked on A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874's PROTECTED_RUN_NS.

[Japabu]

Ruling on the Unsure items at b1c292c76. The 7-spinner arm not adopting Lozi's power-policy condition stands as ToyOS's own rule: the bound holds whatever state an idle core is in, and the row measures it. The stale blockd in the APST issue becomes diskserver in the next round that touches that file.

[Japabu]

Round 6, head b1c292c7679caafdae1be2544162712541eeff38, against origin/main b805e6154, which is also the merge base. git merge-tree --write-tree origin/main b1c292c76 exits 0.

Net lines (git diff --shortstat origin/main...b1c292c76): 8 files, +192 −148, all under issues/. Production 0, tests 0.

Since round 5's head 11be3ba55:

• d1fb0ff6e merges The small-kernel track says what is done, what is left, and in which order #900. git diff --stat origin/main b1c292c76 lists only the branch's eight issue paths.
• b1c292c76 is the round's change: 5 files, +67 −70.

Evidence: ToyOSOrg/evidence at 606ae8c6, whose message names b1c292c7679c….

• ci-host.log is 8831 lines. Its first stamp, 00:48:24 UTC, comes 4 s after the head's commit at 00:48:20Z. It ends [ci] Host: 76 step(s), all green, then EXIT=0.
• No guest test reaches a change that touches only issues/.

Linux. Two names remain in the changed files, and neither is a citation of Linux as an authority:

• the issue path no-program-measures-toyos-against-linux-on-one-machine.md, which the round did not change and which is a comparison program's issue;
• the title of Lozi et al.'s EuroSys 2016 paper, which is cited as published literature.

Nothing cites kernel/cpuvuln/fixtures/, cpuinfo, a Linux commit, turbostat or Ubuntu. Goldmont, APL30 and 334820 are gone from issues/.

Earlier findings

• Round 5 BLOCKER 1, MWAIT on AMD: CLOSED as ruling 1 of 6135434292 has it (idle-is-hlt-…:28-30, :67-68).
  • The FFH reading and the _CST ground are gone. The stage is "Intel's alone".
  • The AMD bench keeps hlt and the kick. Its half is the orchestrator's once its _CST is read.
  • The exit takes no doorbell on AMD.
• Round 5 BLOCKER 2, the carve-out: CLOSED as ruling 2 has it (idle-is-hlt-…:30-33, :64-68).
  • The Goldmont table is deleted.
  • The issue records the Core Ultra 200V update as unread.
  • The exit reads it. Where any 2020+ Intel update names a MONITOR or MWAIT erratum, the exit brings back the vendor/family/model verdict and its host test with that row.
• Round 5 BLOCKER 3, per-CPU lines on AMD: CLOSED as ruling 3 and 6135132762 have it (per-cpu-…:46-50).
  • The AMD half stands on ToyOS's rule and AMD's documented line: PPR CPUID_Fn00000001_EBX[15:8] and 55723 §2.6.1. I checked both against the documents in round 5.
  • "documents the cost" is gone from the issue and from the body.
• Round 5 NOTE 1: CLOSED (ruling 4). Both exits gain the CPUID.01H:ECX boot line and cite a T14 boot for bit 3 (idle-is-hlt-…:61-62) and bit 24 (the-timer-is-…:73-74). The fixture citations are gone, and both bodies say the read is not yet made.
• Round 5 NOTE 2: CLOSED (ruling 5, the-timer-is-…:66-71). It names:
  • the statistic: a run's median lateness, and an arm's median of 11 with its min–max spread;
  • the count: 11 runs per arm;
  • overlapping spreads keeping the count.
• Round 5 NOTE 3: OPEN in part. NOTE 1 below.
  • The Ubuntu comparisons are out of the tree and in evidence@606ae8c6:ubuntu-comparisons.md, verbatim against 11be3ba55.
  • Ruling 6's second sentence, "The track states ToyOS's own targets", is not applied.
• Round 5 NOTE 4: CLOSED (a-wake-…:49-54). The arm says it does not take Lozi's power-policy condition and what that puts in the 100 µs row. That is the ruling of 6135636589 on the Unsure item, word for word in substance.
• Round 5 NOTE 5: CLOSED (a-wake-…:63-64, :72-73). The arm and its exit are blocked on A wake to another CPU that is busy is drained at its next preemption point and runs within a bound #874, which is OPEN, and PROTECTED_RUN_NS is not on main (git grep PROTECTED_RUN_NS origin/main -- kernel is empty).
• Round 5 NOTE 6: CLOSED with BLOCKER 2.
• Round 5 NOTE 7: CLOSED. The body's per-CPU paragraph no longer gives 55723 a cost.
• 6135636589's blockd → diskserver: not owed this round. The round does not touch diskserver-drives-nvme-apst.md, and the ruling ties the fix to the next round that does.

BLOCKER

None.

NOTE

1. issues/toyos-uses-what-modern-hardware-offers-for-speed.md:54-67: ruling 6 says "The track states ToyOS's own targets". The two rewritten "Unexplained" items state readings with no target. "The T14's clock under load … reads 2.67 GHz … and what holds it there is unread", and "6.09 ms of C0 time and 16.20 Mcyc per MB … at an IPC of 0.94".
   • Nothing in the tree says why either reading is unexplained. With the comparison gone, "holds it there" implies a ceiling below something, and the item never says what.
   • The body's Unsure item says no target is stated. That records the gap but does not apply the ruling.
   • Fix. Either state the target each reading falls short of, from a published figure such as Intel's rated clocks for the T14's processor, or have the orchestrator rule that these items carry none. Without a target, the two items leave "Unexplained" as readings.

LAND AFTER NAMED CHANGES