This is not a notice of intended change, but rather a solicitation for comment.

We currently default the number of slots on a host provided via hostfile or 
-host to 1. This is a historical "feature" driven by the fact that our initial 
launch system spawned daemons on the remote nodes after we had already mapped 
the processes to them - so we had no way of guessing a reasonable value for the 
number of slots on any node.

However, the "vm" launch method starts daemons on every node prior to  doing 
the mapping, precisely so we can use the topology in the mapping algorithm. 
This creates the possibility of setting the number of slots on a node to the 
number of cpus (either cores or hardware threads, depending on how that flag is 
set) IF it wasn't provided in the hostfile.

This would have an impact on the default "byslot" mapping algorithm. With only 
one slot/node, byslot essentially equates to bynode mapping. So a user-provided 
hostfile that doesn't give any info on the number of slots on a node 
effectively changes the default mapping algorithm to "bynode". This change 
would alter that behavior and retain a "byslot" algorithm, with the number of 
slots being the number of cpus.

I have a use-case that would benefit from making the change, but can handle it 
outside of the main code path. However, if others would also find it of use, I 
can add it to the main code path, either as the default or via MCA param.

Any thoughts?
Ralph


Reply via email to