The objection I have to this is that it forces an implementation where every one-sided component is backed by a communicator. While that’s the case today, it’s certainly not required. If you look at Portal 4, for example, there’s one collective call outside of initialization, and that’s a barrier in MPI_FENCE. The SM component is the same way and given some of the use cases for shared memory allocation using the SM component, it’s very possible that we’ll be faced with a situation where creating a communicator per SM region is too expensive in terms of overall communicator count.
I guess a different question would be what you need the communicator for. It shouldn’t have any useful semantic meaning, so why isn’t a silent implementation detail for the monitoring component? Brian On Nov 28, 2017, at 8:45 AM, George Bosilca <bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote: Devels, We would like to change the definition of the OSC module to move the communicator one level up from the different module structures into the base OSC module. The reason for this, as well as a lengthy discussion on other possible solutions can be found in https://github.com/open-mpi/ompi/pull/4527. We need to take a decision on this asap, to prepare the PR for the 3.1. Please comment asap. George. _______________________________________________ devel mailing list devel@lists.open-mpi.org<mailto:devel@lists.open-mpi.org> https://lists.open-mpi.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://lists.open-mpi.org/mailman/listinfo/devel
