claim: WMP card 3: serve a wake by pulling the comparator forward, not by waiting for the 1 Hz tick

[drawmeanelephant]

Claim

• Owner: buffy (agent/buffy/wmp3-nudge-recovered)
• Scope: WMP card 1 (WMP (WM frame pacing) card 1: measured present cadence + input->present latency on VZ #1247) measured the desktop's input->present latency at 786-1216 ms typical, 3004 ms worst, while a present's own transfer+flush is ~0.3 ms. Card 2 (claim: WMP card 2: present on input, not only on the decimated tick #1250) fixed the WM half (present on input) and left the whole remaining term in the scheduler: round-robin preempted ONLY at the 1 Hz tick (scheduler.zig 'every tick preempts the current task'), so a woken task waited a uniformly distributed 0-1 s to EXECUTE. Fix: the wake funnel (push_home_locked) raises a coalesced reschedule request; scheduler.request_resched pulls core 0's comparator forward ~2 ms via timer.nudge, so the SAME IRQ rotation a period tick uses serves the owed preemption. A nudge delivery must NOT advance the wall clock: timer.handle now returns whether the PPI was the 1 Hz period boundary, and scheduler.tick(period_tick) gates on_tick (tick_count, sleepers, app timers, WM pacing, CPU accounting) on it — so sys_sleep(1), heartbeat_every, SB6's one-tick-per-frame determinism and CPU-limit accounting all keep their 1 Hz meaning. Bound live-wm-pacing to the latency the fix earned (815/1005 ms -> ~2.5/2.7 ms) with a non-vacuity assertion that every measured sample had a nudge behind it.
• Touches: — (the only landed artifact, the live-sched-ring regex repair, moved to its own claim claim: Gate repair: live-sched-ring's procs assertion has been unmatchable since eb37fbe #1253)
• Depends on: —
• Blocker: [Corrected 2026-09-14 — the previous text here said the boot "starves the shell" and that "no scheduler/timer change is on a branch". Both were wrong. starvation was a misdiagnosis: instrumented boots show a failing run printing 451,721 smp: secondary runs= lines with the shell printing EVERY one and then proceeding into script2, and a guest that survives 120 s inside a 489,187-line staging storm with the nudge armed before dying the instant the first dui command arrives. The fatal event is the WM dui path, not the staging backlog. And the change IS on a branch.] The mechanism works and is measured (815 ms -> 2.5 ms), but it kills the SMP NOTEPAD boot (live-wnd5-gate2-policy, PASS 3/3 on main -> FAIL 0/4) with a silent VM-level death: the host reports VM ended before the expected transcript appeared (state=3) (VZVirtualMachine.State.error), the runner has no didStopWithError delegate so VZ gives no reason, and there is NO [EXC] block even though the kernel routes sync exceptions through report_writer. The change is preserved as the reproduction on draft PR DRAFT / BLOCKED (#1261): WMP card 3 reschedule nudge — 815 ms -> 2.5 ms, blocked by a silent VM death on the WM dui path #1255 (branch agent/buffy/wmp3-nudge-recovered @ bc89e9c, all checks green, merges cleanly), and the defect now has its own card: SMP boot dies silently under WM traffic: the extra core-0 switch is survivable, the death is not guest-side #1261. Nothing lands until SMP boot dies silently under WM traffic: the extra core-0 switch is survivable, the death is not guest-side #1261 is fixed.
• Verification: live-wm-pacing shows the latency collapse AND tick_avg_ms still 1000; live-timer/live-sleep/live-timers/live-sched-ring + the WM/SB family stay green on VZ
• Status: ⛔

Notes

WMP = WM frame pacing (card 1 = #1247, card 2 = #1250). Not M53: M53 is the Go-app arc (#1244). ALSO IN SCOPE, and unrelated to the scheduler: tools/gate/specs/live-sched-ring.spec has a regex that cannot match the 'procs:' row since eb37fbe (M50 TS1) inserted uid=/caps= between name= and state= — that gate has been failing on main independently of this work, and it is corrected here so the regression sweep is honest.

---

Progress lives in COMMENTS on this issue (append a new comment; never
rewrite earlier comments). Close the issue with a final evidence comment when
the work lands or is abandoned. Filed by tools/status/new-claim.sh — the
coordination gate treats this open claim issue as ACTIVE. The landing PR
MUST say Closes #<this issue> so merge closes it.

[drawmeanelephant]

Attempted, measured, and NOT shipped: the mechanism works (815 ms -> 2.5 ms) and reproducibly breaks an SMP boot. Status: blocked on an unidentified defect in the core-0 switch path.

Recorded as a negative result so the next attempt starts from evidence. Nothing from the scheduler/timer work is on a branch — the tree is back at origin/main for every kernel file. One unrelated fix did come out of this and is described at the end.

What was built

A reschedule nudge. push_home_locked (the single blocked->ready funnel) raises a coalesced request; scheduler.request_resched_for(id) pulls core 0's comparator forward ~2 ms via timer.nudge(), so the SAME IRQ rotation a period tick uses serves the owed preemption. Crucially the nudge is not a second: timer.handle() returns whether the PPI was the 1 Hz period boundary, and scheduler.tick(period_tick) gates on_tick (tick_count, sleepers, app timers, WM pacing, CPU-limit accounting) on it. sys_sleep(1), heartbeat_every, CPU accounting and SB6's one-tick-per-frame determinism all keep their 1 Hz meaning — live-sb6-perf-payoff passed 2/2 throughout.

It works, and the number is large

live-wm-pacing, same spec, same boot shape, card-2 tip vs this work:

	card 2 (shipped)	with the nudge
input -> present avg	815 ms	2.5 ms
input -> present max	1005 ms	3.9 ms
present interval	1274 ms	1319 ms
tick interval	1000 ms	1034 ms
handoff attempts / done / stale	—	31 / 30 / 1

wm: rate ... lat_n=7 lat_avg_us=2478 lat_max_us=3925 ... tick_avg_ms=1034
     resched_requests=32 nudge_armed=32 nudge_served=31
     handoff_attempts=31 handoff_done=30 handoff_stale=1

So the remaining term really was wake-to-run, and it is removable. The wall clock is untouched, which was the whole point of separating "this PPI marks a second" from "this PPI owes a rotation".

What blocks it: an extra core-0 context switch starves a boot

live-wnd5-gate2-policy (SMP, WND + NOTEPAD, dui orientation chords) fails reproducibly. The guest does not fault — no [EXC] parking:, no tombstone, timer heartbeat ticks=N irq=N exact throughout. The WM keeps presenting on ticks while the shell stops completing dui commands, and the boot ends in VZVirtualMachine.State.error (state=3). That is starvation, not a crash.

Bisection (each row = the probe, then the gate result):

probe	result
baseline origin/main	PASS 3/3
timer.nudge() disabled entirely (flag bookkeeping + tick(period) signature kept)	PASS 2/2
comparator pulled forward, but tick returns before the rotation	PASS 1/1
full rotation on a nudge	FAIL 0/4
rotation skipped when the successor is the WFE-parked idle fallback	FAIL 0/2
targeted handoff (claim exactly the woken slot, nobody else)	FAIL 3/3
handoff suppressed when the wake is raised inside on_tick	PASS 2/3 (and the win is gone — 827 ms)

Read together: the comparator move is harmless; the extra switch is what harms; and the win and the harm come from the same place. The last row is the proof of entanglement — suppressing the wakes that arrive inside the tick's own beat (wm_server.on_tick, the WM's kind-18 delivery) restores the boot and takes resched_requests from 32 down to 1, i.e. it removes exactly the handoffs that produced the 2.5 ms. There is no subset I found that keeps one and drops the other.

Two intermediate results are worth flagging as traps for the next attempt, because both look like progress and are not:

• "Rotate only if the woken task is the round-robin successor" passed 6/7 — but only because discharge_resched was clearing the target before delivery, so it was effectively nudge with no rotation at all, and it measured 807 ms. A guard that looks principled and silently disables the feature.
• The target's lifetime is subtle. The dominant wake in the paced boot (the WM's kind-18) is raised from inside the period tick's on_tick, so a rotation-based discharge cleared the handoff the very same beat had just armed. Observed as handoff_attempts=1 out of nudge_served=16. Fixing it (discharge only when !timer.nudge_pending()) took it to 31/31 and produced the 2.5 ms — and that is precisely the version that starves the SMP boot.

Mechanism: partially understood, stated as such

My best reading, and it is a hypothesis, not a measurement: a handoff switches away from the interrupted task mid-quantum, and when the woken task blocks, the round-robin resumes from its slot. The always-ready idle fallback sits at the highest slot, so it is reached before the wrap back to slot 0 (the shell), and the idle task then parks in WFE until the next period tick. The interrupted task therefore waits ~1 s for what used to be its own quantum. That is consistent with the starvation symptom, with why the WM is unaffected, and with why it needs more than one handoff to become fatal — but I did not confirm it, and the probe that should have discriminated it (skip the rotation when the successor is the idle fallback) failed, which argues the story is incomplete. Whoever picks this up should instrument the ring contents and current[0] across a failing boot before writing a fix.

Why it is not shipped

It breaks a live SMP gate. A 330x latency win does not buy a boot that stops completing commands, and this repo's rule is that the gates are the evidence. The card stays open and blocked: this is a real capability, blocked by a real defect, and the defect is worth finding on its own merits — see the follow-up note below.

Incidental find: live-sched-ring has been unable to pass on main

Unrelated to the scheduler work, but it is why my regression sweep could not be green, and it needs naming precisely.

live-sched-ring.spec's procs assertion has been unmatchable since eb37fbe ("M50 TS1: process principals + sys_principal/whoami/id", #1135) inserted uid= and caps= between name= and state= in the procs: row:

procs: id=1 name=SCHEDRING.BIN uid=1000 caps=0 state=running task=2 stack=0x... exit=-
                    ^^^^^^^^^^^^^^^^^^^^ the regex expected state= here

The regex was last touched by the vgate port (e0ac74e), i.e. before that commit, and origin/main's copy is identical. The gate that asserts SMP task stealing has been failing for every run since, and could never have passed. Verified: 3/3 baseline boots FAIL with the same python [01], and the two steal assertions in the same block PASS (secondary runs=N task=SCHEDRING.BIN and steal runs=N task=SCHEDRING.BIN from=1 both present). Fix is .*? in place of nothing — included in the landing PR for this claim, with the history in the spec comment.

Second, separate, finding while I was there: with the regex fixed, the same spec is flaky — 5 PASS / 1 FAIL in 6 runs, and the failure is steal runs=N task=SCHEDRING.BIN from=1 never appearing in that boot (a 0 count, where successful runs show 3-6). The -c1-pinned task oscillates between rings (from=0 and from=1 alternate), so whether core 0 is ever forced to steal it is a timing race, not an invariant. That assertion needs a deterministic scenario, and it belongs to whoever owns M28 SMP card 10 — I did not weaken it.

Follow-ups this enables

1. Find the switch-path defect directly. A boot that dies from extra core-0 context switches is a hazard well beyond this card: it is the same wall issue Stale idle-loop comment: 'no GIC programming this milestone' contradicts claim 9187 (real PPI delivery) #122's WFE experiment and any change to the tick period or quantum would hit. Reproduce with the probes above; the smallest failing shape is "an extra tick()-driven rotation on core 0 during a NOTEPAD boot".
2. Then re-apply this change — it is written up above in enough detail to be rebuilt, and the instrument (nudge_armed/nudge_served/handoff_attempts/handoff_done/handoff_stale on the wm row, plus the nudge_* fields on the timer row) should come with it.
3. Consider whether the idle fallback should be selectable only when nothing else is ready on core 0 — worth checking on its own evidence, not as a guess attached to this card.

[drawmeanelephant]

The work is recovered and parked as a draft PR: #1255 — #1255

It is not committed history, it is the recovered stash tree on agent/buffy/wmp3-nudge-recovered (base 831f59b, +487/−37 across the 9 files listed above). Recording how it was recovered, because the near-miss is itself worth a line: when I concluded it could not ship I reverted the uncommitted working tree, which was the right call on shipping and the wrong instrument for preserving — the only copies left were the two stashes I had created purely to run clean baselines. Those were dropped, not destroyed, and came back out of the object store.

The draft PR body carries the measured result, the bisection table, the defects specific to that revision (it is the PRE-fix one, so it still has the shared period_deadline bug), and the two traps. This card stays OPEN with Status: ⛔: the draft does not close it and is not for merge as-is.

[drawmeanelephant]

Follow-up 1 from this card's write-up is now a card of its own: #1261 — SMP boot starvation from an extra core-0 context switch.

It took the finding, the seven-row bisection, the two traps, the hypothesis (labelled as a hypothesis, with the failed probe that argues against it), and the reproduction — which points at #1255's branch as the ready-made artifact. So this card stays ⛔ blocked on that one, and whoever picks up #1261 should not have to re-derive any of it.

Two things I re-verified while writing it, since the card asserts them:

• The baseline is current, not this morning's. Re-ran live-wnd5-gate2-policy on today's kernel: PASS 2/2 runs, with the new VZ preflight in front of it reporting hv_vm_create -> 0x00000000 (HV_SUCCESS). The earlier "PASS 3/3" was a different run count on an older tree; the card quotes today's 2/2.
• Stale idle-loop comment: 'no GIC programming this milestone' contradicts claim 9187 (real PPI delivery) #122 is closed, and its WFE item was optional. I had been citing it loosely as "issue Stale idle-loop comment: 'no GIC programming this milestone' contradicts claim 9187 (real PPI delivery) #122's WFE experiment". The accurate form, now in the card: Stale idle-loop comment: 'no GIC programming this milestone' contradicts claim 9187 (real PPI delivery) #122 scoped an optional measure/record of a wfe in the idle loop, and kernel/src/shell.zig:4028 still points at it as "the recorded option". Worth the correction — the card would otherwise have overstated a closed issue as a pending experiment.

I did not claim #1261, and did not touch docs/status.md: that table's rows are milestones, and this is a defect card under an existing one. Claim it before editing.