lei.chen/myxce
1
0
Fork 1
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: log bug-1931/1932, init parjob-capacity-partitioning spec

Browse source 
- bug-1931: the parjob allocator ignores minTasks (a tasks 2..5 job pends
  although 2 slots are free).
- bug-1932: the unsatisfiable-request cache drops pend reasons on a hit
  and is unused in the simulator.
- .kiro/specs/parjob-capacity-partitioning: initialized spec with the
  candidate heuristics for capacity-driven plan generation.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Rongsong Shen 2026-10-09 08:02:00 +00:00
parent a64d0846c7
commit cff3304f5d
Signed by untrusted user: rshen
GPG key ID: 80533536B0EB651C
5 changed files with 270 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

67
.wolf/bugs/bug-1931.md Normal file
View file

@ -0,0 +1,67 @@
---
id: "bug-1931"
status: "open"
status_updated: "2026-10-09"
status_note: "newly logged"
component: "scheduler"
severity: "wrong-result"
timestamp: "2026-10-09T07:23:49Z"
last_seen: "2026-10-09T07:23:49Z"
occurrences: 1
files: ["src/scheduler/src/plugins/parjob_allocator.c", "src/scheduler/src/alloc_runner.c"]
tags: ["scheduler", "parjob", "allocation", "mintasks"]
related: []
---
# bug-1931: xce_scheduler parjob allocator ignores minTasks: a tasks 2..5 job pends though 2 slots are free
## Description
**Observed:** in a `xce_scheduler --sim` session, element `[5]` of an array job requesting `tasks 2..5` pends although its only candidate host, pc13v, has 2 free slots (22 total, 20 in use by elements [1]-[4], 5 tasks each). The decision trace shows that only 5-task partitions are tried:
```
[trace] job 0-5-1791529946-0[5] session 23 position 5 level full
requirement single tasks 2..5 requests mem=409600.000000 (400.00 KB)
plan 1 hosts 1 tasks per position [5]
host pc13v rejected (per-host check): resource shortfall
slots total 22 in-use 20 reserved 0 requested 5
plan 2 hosts 2 tasks per position [3, 2]
host pc13v rejected (per-host check): resource shortfall
slots total 22 in-use 20 reserved 0 requested 3
plan 3 hosts 3 tasks per position [2, 2, 1]
host pc13v accepted
...
plans: 5 generated, 5 tried, 0 discarded, 0 not tried; no plan could be placed
outcome: PEND
host pc13v: resource slots: NO_RESOURCE
```
**Expected:** a job with `minTasks=2, maxTasks=5` is placed with any task count in 2..5 that fits, preferring the largest; here 2 tasks on pc13v (plan `[2]`). If even `minTasks` tasks cannot be placed, the job pends.
**Impact:** every parallel job submitted with a task range (`minTasks < maxTasks`) is scheduled as if `minTasks == maxTasks`: it pends until `maxTasks` tasks fit, wasting free capacity and delaying the job indefinitely on a busy cluster. Wrong scheduling result, no crash.
**Found by:** user review of the sim decision trace (2026-10-09).
## Environment
- OS: no /etc/os-release; Docker container; NixOS kernel; kernel Linux 6.18.33 x86_64
- libc: not recorded: the failing `xce_scheduler` binary is not in this checkout (no build dir); host ldd reports glibc 2.40. The defect is in allocator logic and does not depend on libc
- Toolchain: gcc (GCC) 15.2.0, meson 1.9.1
- Build: profile not recorded (asan, debug or release unknown; user's sim session); the defect is profile-independent allocator logic
- Code: scheduler-framework @ a64d0846-dirty
- Deployment: `xce_scheduler --sim` (sim session 23), one simulated worker pc13v (22 slots), queue xce, policy builtin_fcfs
## Reproduction
1. In `xce_scheduler --sim`, set up one worker with 22 slots and submit an array job of at least 5 elements, each with `minTasks=2, maxTasks=5` (any small mem request, e.g. 400 KB).
2. `trace on all`, then run a scheduling session: elements [1]-[4] start with 5 tasks each (20 slots used).
3. Element [5] pends; its trace lists only partitions of 5 tasks, never `[2]`, `[3]` or `[4]`.
4. Code-level check: `parjob_plan_iter_init()`/`parjob_plan_iter_next()` (`src/scheduler/src/plugins/parjob_allocator.c:202-288`) read only `resreq->maxTasks`; no allocator reads `minTasks` (`grep -rn minTasks src/scheduler/src` shows only the trace and cache-fingerprint fields).
- Frequency: deterministic
- Evidence: decision trace quoted above (from the user's sim session); session not saved
## Root cause
TODO: required for fixed/partial
## Fix
TODO: required for fixed/partial
## Verification
- Test: TODO: name + file; RED before the fix, GREEN after
- Suites: TODO: suite results and build profile
- Live: TODO: soak/deploy run, or n/a and why
## References
- Related: bug-1770 (wired real minTasks/maxTasks into the primary resreq; the allocator never consumed minTasks), bug-1932 (same trace; unsatisfiable cache not used in sim)
- Docs: .kiro/specs/scheduler-allocation/requirements.md (Req 4 AC 1), .kiro/specs/resreq-maxtasks-wiring/, .kiro/specs/parjob-capacity-partitioning/