mirror of
https://github.com/agent-substrate/substrate.git
synced 2026-11-12 10:35:06 +08:00
Lucky Abolorunke
811fac3e7b
#### What pr does Makes resume measurements require the actor's memory to actually work: adds `ReadRAM` — a glutton request that walks the working set (reads one byte per 4KiB page across the requested size) before responding, plus a `--mem-read` knob so the benchmark cycle performs that walk right after every resume. Today's cycle proves an actor is *reachable* after resume, not that its memory is *usable*: the ping answers without touching the working set. A real application must read its memory to serve requests. This matters for where restore optimization is headed — a lazy/on-demand restore would look great on a benchmark that never reads memory (resume returns fast, ping returns fast) while real first-requests would stall faulting pages back in. With the walk in the cycle, "resume + first response" includes the cost of making memory usable, however the restore path schedules that work: eager restore pays it during resume, lazy restore would pay it during the walk — either way the total is in the tracked numbers. Also upgrades churn with `WRITE_MODE_OVERWRITE_ROTATE`: overwrite at a per-key cursor that advances past each write and wraps, so repeated churn walks the whole array over time instead of re-dirtying the same prefix every cycle. #### How it works - `ReadRAM(key, size)` walks the first `size` bytes (suffixed string, e.g. `"1Gi"`; empty walks the whole array) of a `WriteRAM` allocation, one byte per 4KiB page — the cheapest touch that forces every page resident. The response returns bytes walked plus an XOR checksum of the sampled bytes so the reads are observable and can't be elided. - Cycle order: resume → fill (once) → **walk** → churn → ping → suspend. The walk runs *before* churn deliberately: it must read the memory as restored, not pages churn just rewrote; churn then re-dirties after, so the next snapshot still carries fresh pages. - The walk reports as its own `GluttonReadRAM` stats row — it never pollutes ping or resume latencies. Today (eager restore) it reads warm memory in milliseconds; a jump in this row is the signal that restore work got deferred onto the request path. - Config travels the established channel: `--mem-read` in the suite's locust `flags:` → `/boomer-config` → the Go worker, passed verbatim to the wire; glutton is the only parser. Empty = disabled; the tracked large-memory suites set it to the full target (walk everything — strongest signal, simplest story). Existing suites unchanged. #### Testing - `go test -race` across `cmd/benchmarking/glutton` and `internal/benchmarking/boomer/...`: PASS. New tests cover the walk's byte count and checksum, missing-key/bad-size errors, cycle call order (fill → read → churn with the right sizes and modes), rotate-mode cursor wrap, disabled-by-default, and walk-before-fill as a no-op. - Cluster verification (microvm, 1Gi target, full walk):