Hi devels,
In fact the communicator's group was already retained in the window
structure. So everything was already in place. I pushed the last
modifications, and everything seems ready to be merged in PR#4527.
Jeff, the fixup commits are squashed :)
Clément
On 11/30/2017 12:00 AM, Barrett, Brian via devel wrote:
The group is the easiest way to do the mapping from rank in window to
ompi_proc_t, so it’s safe to say every window will have one (also, as
a way of holding a reference to the ompi_proc_t). So I think it’s
safe to say that every OSC module has a group handle somewhere
(directly or through the communicator).
Remember that in some implementations of the MTL, a communicator ID is
a precious resource. I don’t know where Portals 4 falls right now,
but in various of the 64 bit tag matching implementations, it’s been
as low as 4k communicators. There’s no need for a cid if all you hold
is a group reference. Plus, a communicator has a bunch of other state
(collective modules handles, etc.) that aren’t necessarily needed by a
window.
Brian
On Nov 29, 2017, at 5:57 AM, Clement FOYER <clement.fo...@gmail.com
<mailto:clement.fo...@gmail.com>> wrote:
Hi Brian,
Even if I see your point, I don't think a user request de free the
communicator should necesserily lead to the communicator being
deleted, only released from one hold, and available to be disposed by
the library. I don't see objection to have the library keep a grab on
these communicators, as the user give a handle to the actual object.
I do agree the point of asking if we want to keep only information
relevant to all OSC components. Nevertheless, what would the
difference be between holding the complete communicator and holding
the group only? Is group the smallest part common to every component?
Clément
On 11/28/2017 07:46 PM, Barrett, Brian via devel wrote:
The following is perfectly legal:
MPI_Comm_dup(some_comm, &tmp_comm);
MPI_Win_create(…., tmp_comm, &window);
MPI_Comm_free(tmp_comm);
<use window>
So I don’t think stashing away a communicator is the solution. Is a
group sufficient? I think any rational reading of the standard
would lead to windows needing to hold a group reference for the life
of the window. I’d be ok putting a group pointer in the base
window, if that would work?
Brian
On Nov 28, 2017, at 10:19 AM, George Bosilca <bosi...@icl.utk.edu
<mailto:bosi...@icl.utk.edu>> wrote:
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 <mailto: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 <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
<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
<https://lists.open-mpi.org/mailman/listinfo/devel>
_______________________________________________
devel mailing list
devel@lists.open-mpi.org <mailto:devel@lists.open-mpi.org>
https://lists.open-mpi.org/mailman/listinfo/devel
<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 <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
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/devel
