fix(scheduler): global limits on per-host resources now read the correct want (bug-1789)
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
This commit is contained in:
parent
22cfe61642
commit
924ac32c1d
28 changed files with 332 additions and 84 deletions
File diff suppressed because one or more lines are too long
Loading…
Add table
Add a link
Reference in a new issue