Description
Topograph currently models accelerator topology as a single locality level. Add support for two nested levels so schedulers can make placement decisions within both a base domain and its parent domain.
Slurm requirements
- Generate "BlockSizes=N,R*N" where N is the number of nodes in a rack and R is the number of racks in parent domain.
- Emit exactly R consecutive base blocks for each parent domain.
- Never interleave blocks from different parent domains.
- Reserve all R positions when a parent domain is first discovered.
- Represent unavailable or undiscovered base domains with empty entries so later blocks do not shift.
- Use deterministic names that identify the parent domain and base-block position.
- Apply this behavior to every Slurm topology/block output, including Slinky where applicable.
Example:
BlockName=domain_d1_b04 Nodes=node[028-036]
BlockName=domain_d1_b05
BlockName=domain_d1_b06 Nodes=node[046-054]
Slurm derives each aggregate from consecutive base blocks, making stable ordering and placeholders necessary.
Before implementation, confirm that base domains have persistent identifiers or positions. Otherwise, stable ordering cannot be guaranteed.
Kubernetes requirements
Expose both hierarchy levels as configurable topology labels. Label values must remain stable and be shared by all nodes in the corresponding domain.
Design consideration
The canonical graph currently supports only one accelerator locality dimension through AcceleratorID and Graph.Domains. Supporting nested domains may require a coordinated canonical-model change that should be designed and discussed before implementation.
Description
Topograph currently models accelerator topology as a single locality level. Add support for two nested levels so schedulers can make placement decisions within both a base domain and its parent domain.
Slurm requirements
Example:
Slurm derives each aggregate from consecutive base blocks, making stable ordering and placeholders necessary.
Before implementation, confirm that base domains have persistent identifiers or positions. Otherwise, stable ordering cannot be guaranteed.
Kubernetes requirements
Expose both hierarchy levels as configurable topology labels. Label values must remain stable and be shared by all nodes in the corresponding domain.
Design consideration
The canonical graph currently supports only one accelerator locality dimension through
AcceleratorIDandGraph.Domains. Supporting nested domains may require a coordinated canonical-model change that should be designed and discussed before implementation.