Hi Brian, Let me first start with explaining why we need the communicator. We need to translate local to global rank (aka. rank in your MPI_COMM_WORLD), so that the communication map we provide make sense. The only way today is to go back to a communicator and then basically translate a rank between this communicator and MPI_COMM_WORLD. We could use the gid, but then we have a hash table lookup for every operation.
While a communicator is not needed internally by an OSC, in MPI world all windows start with a communicator. This is the reason why I was proposing the change, not to force a window to create or hold a communicator, but simply because the existence of a communicator linked to the window is more of less enforced by the MPI standard. George. On Tue, Nov 28, 2017 at 1:02 PM, Barrett, Brian via devel < devel@lists.open-mpi.org> wrote: > 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> 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 > https://lists.open-mpi.org/mailman/listinfo/devel > > > > _______________________________________________ > devel mailing list > 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
