Tracked from #30, especially the refill timing analysis in #30 (comment).
Problem
ClaimWarm removes a VM from p.warm but does not trigger refill. The first refill attempt therefore waits for startup, SetPools, or the two-second ticker.
The measured warm 0 -> 6 recovery was 1638 ms. The underlying recovery is:
- 0–2000 ms waiting for ticker phase;
- approximately 200–400 ms of actual refill work.
refillOne already self-chains once refill starts, so the missing lever is the initial kick, not a larger semaphore at this pool depth. This does not reduce the current warm claim's latency; it improves the warm-hit ratio for traffic arriving shortly after a drain.
Relevant code:
Proposed scope
- Send a non-blocking, coalesced refill signal immediately after a warm VM is removed.
- Let the manager
Run loop consume the signal and call refillOnce.
- Keep the two-second ticker as a safety net.
- Do not spawn one goroutine per claim and do not block the claim response.
- Do not change
maxConcurrentRefills in this issue.
A capacity-one channel or equivalent atomic pending bit is sufficient.
Acceptance criteria
- A warm pop starts refill without waiting for the next ticker.
- Concurrent warm claims coalesce rather than creating refill storms.
- Existing draining checks and the refill concurrency cap remain effective.
- A randomized-ticker-phase 0 -> 6 benchmark, sampled at 10–20 ms resolution, reports recovery near the actual refill work term rather than the ticker interval.
- Warm claim latency does not regress measurably.
Tracked from #30, especially the refill timing analysis in #30 (comment).
Problem
ClaimWarmremoves a VM fromp.warmbut does not trigger refill. The first refill attempt therefore waits for startup,SetPools, or the two-second ticker.The measured warm 0 -> 6 recovery was 1638 ms. The underlying recovery is:
refillOnealready self-chains once refill starts, so the missing lever is the initial kick, not a larger semaphore at this pool depth. This does not reduce the current warm claim's latency; it improves the warm-hit ratio for traffic arriving shortly after a drain.Relevant code:
ClaimWarmProposed scope
Runloop consume the signal and callrefillOnce.maxConcurrentRefillsin this issue.A capacity-one channel or equivalent atomic pending bit is sufficient.
Acceptance criteria