(via Bnjoroge1): Halve memory-derived warm pool size to prevent OOM during successor prov

[macroscopeapp]

Summary

Halves the memory-derived warm pool size to prevent out-of-memory (OOM) conditions during successor provisioning.

Problem

When using a warm pool, each slot may temporarily keep both the current job VM and a provisioning successor VM alive simultaneously. The previous calculation only accounted for the memory needed by the current VMs, not the additional memory required during the provisioning window when two VMs can coexist per slot.

Solution

Modified the warm pool size calculation in RunnerPool::run to divide the memory-derived limit by 2, properly accounting for the worst-case memory usage where each warm slot has both a running VM and a successor being provisioned.

The .max(1) ensures that at least one warm slot remains available even on memory-constrained systems.

Note

Macroscope: Fix It For Me

• This PR originated from this comment in fix: pool recovery and tolerate stale snapshots on boot, re-arm spent fingerprint goldens #167.
• Since auto-merge is on, Macroscope will merge this PR after waiting for checks to pass.
• If you'd rather not wait, you can always merge this yourself but no further action from you is currently needed.
• You can also @mention Macroscope in this PR to request further changes.

Activity

Currently: Merged by Bnjoroge1

Previously

• Not merged: unknown mergeable state
• Waiting on checks
• Pushed 3a26f43

---

Note

Halve memory-derived warm pool size in RunnerPool.run supervisor

When host memory is detectable, the warm pool size is now min(config.size, max(1, on_demand_memory_cap(total, memory_mib) / 2)) instead of using the raw cap. This provisions fewer warm slots to avoid OOM during successor provisioning. Risk: saturating_div(2) in lib.rs reduces the warm pool by up to half for hosts with known memory; the max(1) floor ensures at least one slot is always provisioned.

^{Macroscope summarized 3a26f43.}

---

Summary by cubic

Prevent OOM during successor provisioning by halving the memory-derived warm pool size. Previously we sized for one VM per warm slot; now we account for a transient second VM and guarantee at least one warm slot.

• Implemented in RunnerPool::run: apply saturating_div(2).max(1) to on_demand_memory_cap(...).
• Effect: memory-capped pools may start fewer warm slots; explicit PRELOOP_RUNNER_POOL_SIZE still overrides.
• Rollout: expect fewer OOMs while provisioning successors; if warm capacity drops too much, set PRELOOP_RUNNER_POOL_SIZE to an explicit value.

^{Written for commit 3a26f43. Summary will update on new commits.}

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.