It’s a difficult call to make as to which is the correct behavior. In Example 1, you are executing a single app_context that has two procs in it. In Example 2, you are executing two app_contexts, each with a single proc in it.
Now some people say that the two should be treated the same, with the second app_context in Example 2 being mapped starting from the end of the first app_context. In this model, a comm_spawn would also start from the end of the earlier app_context, and thus the new proc would not be on the same node (or socket, in this case) as its parent. Other people argue for the opposite behavior - that each app_context should start from the first available slot in the allocation. In that model, a comm_spawn would result in the first child occupying the same node (or socket) as its parent, assuming an available slot. We’ve bounced around a bit on the behavior over the years as different groups voiced their opinions. OMPI 1.4.3 is _very_ old and fell in the prior camp, while 2.1.1 is just released and is in the second camp. I honestly don’t recall where the change occurred, or even how consistent we have necessarily been over the years. It isn’t something that people raise very often. I’ve pretty much resolved to leave the default behavior as it currently sits, but plan to add an option to support the alternative behavior as there seems no clear cut consensus in the user community for this behavior. Not sure when I’ll get to it - definitely not for the 2.x series, and maybe not for 3.x since that is about to be released. > On Jun 29, 2017, at 11:24 AM, Ted Sussman <ted.suss...@adina.com> wrote: > > Hello all, > > Today I have a problem with the --map-to socket feature of Open MPI 2.1.1 > when used with application context files. > > In the examples below, I am testing on a 2 socket computer, each socket with > 4 cores. > > --- > > Example 1: > > .../openmpi-2.1.1/bin/mpirun --report-bindings \ > -map-by socket \ > -np 2 \ > afftest01.exe > > returns > > ...MCW rank 0 bound to socket 0 ... : [B/B/B/B][./././.] > ...MCW rank 1 bound to socket 1 ... : [./././.][B/B/B/B] > > which is what I would expect. > > --- > > Example 2: > > Create appfile as: > > -np 1 afftest01.exe > -np 1 afftest01.exe > > Then > > .../openmpi-2.1.1/bin/mpirun --report-bindings \ > -map-by socket \ > -app appfile > > returns > > ...MCW rank 0 bound to socket 0 ... : [B/B/B/B][./././.] > ...MCW rank 1 bound to socket 0 ... : [B/B/B/B][./././.] > > which is not what I expect. I expect the same bindings as in Example 1. > > --- > > Example 3: > > Using the same appfile as in Example 2, > > .../openmpi-1.4.3/bin/mpirun --report-bindings \ > -bysocket --bind-to-core \ > -app appfile > > returns > > ... odls:default:fork binding child ... to socket 0 cpus 0002 > ... odls:default:fork binding child ... to socket 1 cpus 0001 > > which is what I would expect. Here I use --bind-to-core just to get the > bindings printed. > > --- > > The examples show that the --map-by socket feature does not work as expected > when application context files are used. However the older -bysocket feature > worked as expected in OpenMPI 1.4.3 when application context files are used. > > If I am using the wrong syntax in Example 2, please let me know. > > Sincerely, > > Ted Sussman > > > _______________________________________________ > users mailing list > users@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/users
_______________________________________________ users mailing list users@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/users
