docs(resource-accounting): explain why admission control doesn't query live

Resource information for candidate hosts is injected into the
scheduler once per session (worker push, cached in w->resvals/
w->resInUse); a single session then evaluates many jobs against many
candidate hosts off that one cached snapshot without re-querying
between decisions. Made the reason explicit: a live query per
candidate-host check, at the volume a session performs, would be far
too costly. This is a documentation clarification only -- no
behavior change.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019QxaSzHRB7pmYFp4cVnwkA
This commit is contained in:
Rongsong Shen 2026-08-31 07:28:00 +00:00
parent a30ce7ddc6
commit a6a0bdf7cd
No known key found for this signature in database
GPG key ID: 5BCDAAE0123E9FE2

View file

@ -42,8 +42,16 @@ about what's free *right now*, not the host's total capacity.
## How admission control actually reads "available" (read this before the formula)
The scheduler's admission check does **not** query the OS live at
decision time. `sched_check_host_satisfy_()` (`resource.c`) reads two
already-in-memory arrays and hands them to `unsatisfy_()`:
decision time — deliberately, not as an oversight. All candidate-host
resource information is injected into the scheduler once per session
(pushed by the worker, cached in `w->resvals`/`w->resInUse`); a single
scheduling session then evaluates many pending jobs against many
candidate hosts using that one cached snapshot, without re-querying
between decisions. Querying live on every candidate-host check a session
performs would multiply that already-high decision volume by a live I/O
round-trip each time — the cost this design avoids. `sched_check_host_
satisfy_()` (`resource.c`) reads two already-in-memory arrays and hands
them to `unsatisfy_()`:
```c
total = get_resvals(&(w->resvals), ...); // the worker's last-reported "mem" value