mstar.conductor.workers#
The workers a deployment config starts, and the device each runs on.
The conductor starts its workers from this list, and the API server places its
result threads from it before the conductor exists, so the two can’t disagree
about which CPUs the workers take (mstar.utils.cpus).
Functions
The device type workers run on: the accelerator's, else |
|
|
Every rank |
|
The device string a worker rank runs on: its own number unless the deployment's |
Classes
|
One entry per worker, in rank order. |
- class mstar.conductor.workers.DeploymentWorkers(ranks, devices)[source]#
Bases:
NamedTupleOne entry per worker, in rank order.
- mstar.conductor.workers.accelerator_type()[source]#
The device type workers run on: the accelerator’s, else
cpu.- Return type:
- mstar.conductor.workers.deployment_workers(config, device_type)[source]#
Every rank
node_groupsnames gets a worker (check_placementrefuses a rank no walk runs on), on the deviceworker_devicegives it.The optional
rank_devices: {rank: device_index}places a worker rank on a device other than the one its number implies, e.g. two workers sharing one GPU so a light node’s steps stop interleaving with a heavy node’s on the same worker loop.The API server reads this before the conductor’s
validate_deploymenthas seen the config, so a malformed entry is skipped here and reported there.- Parameters:
- Return type: