Bennet,
my guess is mapping/binding to sockets was deemed the best compromise
from an
"out of the box" performance point of view.
iirc, we did fix some bugs that occured when running under asymmetric
cpusets/cgroups.
if you still have some issues with the latest Open MPI version (2.0.1)
and the default policy,
could you please describe them ?
Cheers,
Gilles
On 9/30/2016 10:55 AM, Bennet Fauber wrote:
Pardon my naivete, but why is bind-to-none not the default, and if the
user wants to specify something, they can then get into trouble
knowingly? We have had all manner of problems with binding when using
cpusets/cgroups.
-- bennet
On Thu, Sep 29, 2016 at 9:52 PM, Gilles Gouaillardet <gil...@rist.or.jp> wrote:
David,
i guess you would have expected the default mapping/binding scheme is core
instead of sockets
iirc, we decided *not* to bind to cores by default because it is "safer"
if you simply
OMP_NUM_THREADS=8 mpirun -np 2 a.out
then, a default mapping/binding scheme by core means the OpenMP threads end
up doing time sharing.
this is an honest mistake (8 cores per task were not requested), so having a
default mapping/binding scheme by socket means
OpenMP threads are spread on the socket and will likely not do time sharing.
/* if you run on a single socket, or if you run 4 tasks on a dual socket
nodes, then (some) tasks do share the socket,
and depending on how the OpenMP runtime is implemented, two threads of two
distinct tasks could end up bound/running on the same core */
Cheers,
Gilles
On 9/30/2016 3:04 AM, David Shrader wrote:
Hello All,
Would anyone know why the default mapping scheme is socket for jobs with
more than 2 ranks? Would they be able to please take some time and explain
the reasoning? Please note I am not railing against the decision, but rather
trying to gather as much information about it as I can so as to be able to
better work with my users who are just now starting to ask questions about
it. The FAQ pretty much pushes folks to the man pages, and the mpirun man
page doesn't go in to the reasoning.
Thank you for your time,
David
_______________________________________________
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
_______________________________________________
users mailing list
users@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/users
