Rongsong Shen
924ac32c1d
sched_fill_limit_requests() used to read a limit's underlying resource's want from the same vector its own virtual-resource entry gets written to. That's wrong whenever the two differ in scope -- e.g. a GLOBAL limit built on top of a per-host resource like "slots" (limits.yaml's ug1_normal_slots): the limit's own vres entry belongs in alloc_req->shared, but "slots"'s want is only ever staged into alloc_req->host by seqjob/parjob_prepare_allocation(), so the old code always read a zero and silently never enforced the cap. Now both the read source and write destination are derived independently from each resource's own XCE_RESF_GLOBAL flag (vres->res for the source, vres->vres for the destination) -- the same flag calc_wanted_global_resvals()/calc_wanted_host_resvals() (resreq.c) already dispatch on, so this is the existing rule applied consistently rather than a new one. Also drops sched_fill_limit_requests()'s unused xce_scheduler_t* parameter. Full scheduler suite: 76/77 (the one failure, test_job_rusage_reconciles_ mem_reservation_against_usage, is bug-1762, pre-existing and unrelated). Live-verified against a fresh single-node deploy. Filed bug-1790 to track a known, deliberately out-of-scope residual gap: a future global limit on a per-host resource other than "slots" would need calc_wanted_host_resvals() to also run during the global phase for that resource, which nothing currently does. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GLfB5uWRdmx2WiZSFC7Fm7 |
||
|---|---|---|
| .. | ||
| autoscaler | ||
| configs | ||
| controller | ||
| docs | ||
| frontend | ||
| include | ||
| lib | ||
| nixSupport | ||
| scheduler | ||
| schema | ||
| tools | ||
| worker | ||
| xceadmin | ||
| flake.lock | ||
| flake.nix | ||
| meson.build | ||
| meson.options | ||