What is missing or unclear:
Project-HAMi/HAMi#2469 introduces optional per-Pod device-scoring weights, but the public website does not yet explain how users configure or reason about this behavior. This documentation was requested in Maintainer @FouoF review feedback before the feature is merged.
The documentation should cover:
- the annotation format:
metadata:
annotations:
hami.io/device-scoring-weights: "slot=1,core=1,memory=3"
- the default
slot=1,core=1,memory=1 behavior when the annotation is absent
- validation rules: all three keys are required, weights must be non-negative integers, and at least one weight must be positive
- the weighted score formula for predicted slot, core, and memory utilization
- how the score is consumed by existing GPU scheduling policies:
binpack prefers a higher utilization score, spread prefers a lower score, and topology can use utilization ordering as a tie-breaker
- scope boundaries: the annotation changes scoring preference only; device fit/capacity, mutex, NUMA, topology constraints, and vendor-specific
Fit behavior remain unchanged
- a small Pod manifest and an example explaining when memory-heavy weighting can change device selection
- invalid annotations leave the Pod unschedulable until corrected
Implementation references:
Where it should go (existing page, or a new page):
Extend docs/developers/scheduling.md, which already documents GPU scheduler policies and their scoring formulas. The published wording and annotation contract should be finalized against Project-HAMi/HAMi#2469 before the documentation PR is marked ready.
Why this would help:
This is a user-facing, per-workload scheduling control. Users need a canonical website example and clear interaction rules so they can tune placement without assuming the annotation changes capacity checks or overrides topology and exclusivity constraints.
What is missing or unclear:
Project-HAMi/HAMi#2469 introduces optional per-Pod device-scoring weights, but the public website does not yet explain how users configure or reason about this behavior. This documentation was requested in Maintainer @FouoF review feedback before the feature is merged.
The documentation should cover:
slot=1,core=1,memory=1behavior when the annotation is absentbinpackprefers a higher utilization score,spreadprefers a lower score, and topology can use utilization ordering as a tie-breakerFitbehavior remain unchangedImplementation references:
Where it should go (existing page, or a new page):
Extend
docs/developers/scheduling.md, which already documents GPU scheduler policies and their scoring formulas. The published wording and annotation contract should be finalized against Project-HAMi/HAMi#2469 before the documentation PR is marked ready.Why this would help:
This is a user-facing, per-workload scheduling control. Users need a canonical website example and clear interaction rules so they can tune placement without assuming the annotation changes capacity checks or overrides topology and exclusivity constraints.