Stall reversal threshold can be unreachable at short monitor intervals #43
Breadway
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during RAM-30 live bounded-workload benchmarks. Confidence: high for interval mismatch; medium for whether every non-reversal run violates policy. StallWatch uses a fixed 500,000 microsecond rise between successive tick deltas, while daemon monitor interval is settle_ms.max(250). With a 500ms tick, even a fully stalled scope cannot generally rise by more than the whole interval, making the threshold effectively unreachable; at 250ms it is unreachable. The watcher also judges only limits confirmed on the immediately preceding pass, discarding pending observations on subsequent passes. Live 96MiB worker under a 16MiB daemon limit accumulated 6,075,722 stall microseconds over 24s with one confirmed action and duplicate skips but no rollback. Do not claim every cumulative rise mandates reversal: the policy compares interval deltas, not totals. Reproduce with scripts/bench/bench-daemon.sh in feature/ram-30-benchmarks, varying settle_ms between 500 and 2000. Expected: a time-normalized rate/window policy, with a defined observation duration and tests for short ticks, rather than a fixed absolute delta tied implicitly to the default tick.
Review of PR 44 at
db36af2: changes requested, not merged. CI green and local test/clippy/fmt pass, but: (1) docs/PRIORITIES.md, judge/StallWatch/const docs and daemon comments still describe the old 500,000 us per-tick rule, and stall_delta_verdict/StallVerdict/STALL_SCOPE_DELTA_RISE_US are now dead in production; (2) soft limits are deferred silently, can be starved forever when no memory.pressure reading exists, lose journalled refusals for non-controllable scopes, and a fully deferred plan reports 'the plan proposed no action'; (3) no test covers the run_execution changes (deferral, ownership filter, disarm, pending retention); (4) minor: 99/100 bp boundary test, duplicate stall_pending entry on re-arm, timestamp jitter at 250 ms, mixed-pass summary hides the reversal. Full checklist is on the PR: #44Review of
0c03949: changes requested. One blocker left: docs/PRIORITIES.md lines 107-110 still describe the removed half CPU-second rule and a 'Reverse' verdict. Deferral, settle_stall_observations tests (mutation checked), boundary/cap tests and CI are all fine. Full review on PR 44. Follow-up filed as RAM-78 (now_ms jitter).