vms-9d4f: machine-relative drive budget for test_syssvc_mmk_build mark1 (kill the slow-TCG flake, no wall bump) - #636
Merged
Conversation
…k1 (kill the slow-TCG flake, no wall bump) test_syssvc_mmk_build mark1 (drive #1 = compile+archive) gave each drive a FIXED 60s host-wall budget (300x poll(200ms)). Drive #1 has MMK.EXE spawn DCL which forks TCC.EXE to compile the real vms_string.c IN-GUEST; under GitHub's ~10x-slow TCG runner that compile's host-wall can exceed 60s -> OVMXD1B:COMPILED marker arrives late -> mark1 FAILs intermittently. This is a pre-existing, emulation-speed-dependent flake (bisect found NO first-red commit: pristine is green at the pre-ACP baseline AND current tip; the "#630 first-red" was a nightly-cadence artifact). Not a regression in the alpha or ACP work. Fix (Rule 8 root cause, NOT a wall bump): budget the drives in MEASURED guest compile time instead of host wall. calibrate_tcc_ms() times a direct fork+exec TCC compile of vms_string.c right before the drives; drive_budget_ms() = DRIVE_COMPILE_MARGIN(3) * t_cal + DRIVE_FIXED_OVERHEAD_MS(8s) + (link ? 20s : 0). On a fast host this reproduces the historical ~60s neighborhood (no behavior change); on a 10x-slow host the budget scales with the SAME multiplier the guest's own compiler runs under, so it can't be outrun by TCG speed. The old 60s constant survives ONLY as CAL_FALLBACK_MS -- a floor when calibration can't measure -- never as the ceiling a slow run is held to. Calibration is bounded by CAL_TIMEOUT_MS(180s) so a wedged TCC is a named failure, not a hang. The SEMANTIC assertion is unchanged: MMK.EXE must still drive the real spawn + mailbox + write-attention AST + $HIBER + IO$M_NOW + $STATUS path and the test still requires the real OVMXD1B:COMPILED marker. facility_defects negctl anchor intact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4 tasks
baron-3dl
added a commit
that referenced
this pull request
Aug 17, 2026
…t add-on (#638) Fast-follow to #636 (vms-9d4f). #636 fixed drive #1's (compile+archive) budget to scale with the measured in-guest compile speed, but left drive #2 (do_link=1: compile+archive+LINK+activate) with a flat +20000ms add-on atop the calibrated compile term instead of scaling that extra work too. Robustness testing (docker run --cpus=<throttle>, simulating slow TCG) found the gap: at ~8.5x throttle (t_cal 897ms vs ~106ms baseline), drive #2's LINK+activate stage missed its budget under the OLD fully-fixed 60000ms constant -- a real instance of the fixed-host-wall failure mode #636 targets. But #636's shipped design (flat +20000) did not close this either: since the flat add-on is capped and doesn't grow with slowdown, it degrades to the same floor-dominated behavior as the old constant at any throttle level that doesn't already clear the compile-margin term alone. This file's own history already says the LINK+activate cost is TCG-speed-dependent (the 40000->60000 raise was explicitly "under slow/contended TCG the whole chain can exceed the old bound") -- so it should scale with t_cal like the compile term does, not sit behind a flat constant. Fix: replace DRIVE_LINK_OVERHEAD_MS (flat +20000) with DRIVE_COMPILE_MARGIN_LINK (6, vs drive #1's margin of 3), applied to the SAME calibrated t_cal. Both drives now scale proportionally with measured guest speed; only DRIVE_FIXED_OVERHEAD_MS (spawn/mailbox/dispatch/marker, 8000ms) stays flat. On a fast host this is unchanged (both drives still floor at the historical 60000ms neighborhood -- verified 16/16 green under the faithful gate, docker build -f tests/qemu/Dockerfile + docker run, 1533/1533 assertions passing). On a slow host both drives' budgets now grow with the SAME multiplier the guest is actually running under. SEMANTIC assertion unchanged: MMK.EXE still drives the real spawn + mailbox + write-attention AST + $HIBER + IO$M_NOW + $STATUS path to the real OVMXD1B:COMPILED marker; facility_defects negctl anchor (mmk-build-image-not- activated) untouched. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The flake (rd vms-9d4f)
test_syssvc_mmk_buildmark1 (drive #1 = compile+archive) gave each drive a fixed 60s host-wall budget. Drive #1 has MMK.EXE spawn DCL → fork TCC.EXE → compile the realvms_string.cin-guest; under GitHub's ~10× slow TCG runner that compile can exceed 60s →OVMXD1B:COMPILEDmarker late → intermittent FAIL.Not a regression. Bisect found no first-red commit (pristine green at pre-ACP baseline and current tip); the "#630 first-red" was a nightly-cadence artifact. Both the alpha lane and the ACP lane were cleared with evidence (#628 imgact is off drive-#1's path; ACP changes additive; #630 RTL fn has no callers).
Fix — machine-relative budget (Rule 8 root cause, NOT a wall bump)
calibrate_tcc_ms()times a direct fork+exec TCC compile ofvms_string.cright before the drives;drive_budget_ms()=DRIVE_COMPILE_MARGIN(3)·t_cal + DRIVE_FIXED_OVERHEAD_MS(8s) + (link?20s:0). Fast host → ~60s neighborhood (no behavior change); 10× slow host → budget scales with the same multiplier the guest compiler runs under. The old 60s constant survives only asCAL_FALLBACK_MS(a floor when calibration can't measure), never as the ceiling. Calibration bounded byCAL_TIMEOUT_MS(180s).Preserved
Semantic assertion unchanged — MMK still drives the real spawn + mailbox + write-attention AST + $HIBER + IO$M_NOW + $STATUS path and still requires the real
OVMXD1B:COMPILEDmarker. facility_defects negctl anchor intact.Refs vms-9d4f.
🤖 Generated with Claude Code